Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming convention + element customization #1220

Open
kedrzu opened this issue Sep 21, 2017 · 2 comments
Open

Naming convention + element customization #1220

kedrzu opened this issue Sep 21, 2017 · 2 comments
Labels

Comments

@kedrzu
Copy link

kedrzu commented Sep 21, 2017

Overview of the problem

This is about the Bulma CSS framework

Description

I love the simplicity of Bulma coming with a great value as well.

However when developing some bigger app with Bulma I find it difficult to get sticked to its naming convention. Short class names are great for the sake of simplicity, however when having some more customized views, bigger components, along with using SPA framework is troubling.

I need to mix Bulma default components with some custom CSS, sometimes struggling with old fashioned CSS problem, that is curse of specificity, not being able to determine which rule is working and which not, when there is 3 levels of nesting.

Also it's quite hard to mix Bulma with some opinionated CSS naming conventions like BEM, SMACSS, made to be easy scallable.

Also there is no easy way to have a new component that is a slightly modified Bulma component, with some custom css, like custom tabs or panels. There is of course a possibility to add some modifier to change how component looks, however this goes with problem of untrackable specificity, and one must hack some nested rules or sprinkle some !important here and there to have this working.

Proposal

Maybe components should be defined as a "recipe", like function or mixin that creates a component with custom naming conventions (like custom prefixes, super-tabs for instance).

Standard components would be just these mixins included with standard names. One would be thereafter able to create as many copies of components as he likes, modifying it to fit his design needs.

@kwynns
Copy link

kwynns commented Dec 29, 2018

just came across this, but I wonder if a generator would work for this?

I actually really like this idea and might give it a shot. Using a cli, it would start off with a menu system asking what path you'd like to save to, then if you want to create a new element or component. Then show a list of what you selected, then you select one and it asks for a name. It generates the file and sticks it in whatever path you designated.

I haven't dived in to their naming conventions much, but I'd see if I can BEMify it in the process.

@jgthms jgthms added the pinned label Jan 21, 2019
@jgthms
Copy link
Owner

jgthms commented May 18, 2019

Been thinking about this a lot. I wish I could provide this in an easy way, kind of like this:

// Flag to determine if we output the CSS of this file
// Defaults to a global $output value set to true
$hero-output: $output !default

=hero
  align-items: stretch
  display: flex
  flex-direction: column
  justify-content: space-between
  // More styles

// If the flag is true, we output the CSS within the .hero selector
@if $hero-output
  .hero
    +hero

It could even accept a classname as parameter:

=hero($className)
  .#{$className}
    align-items: stretch
    // More styles

@if $hero-output
  +hero("hero")

Now this could be fairly easy to implement, although it would require a lot of refactoring.

But the issue is with class combinations like .hero .navbar or .hero .title, which you can see in the source code: https://github.com/jgthms/bulma/blob/master/sass/layout/hero.sass

Each of these classes would already have their own mixin:

=navbar($className)

=title($className)

// etc.

Because within the .hero declaration block, there's mentions of .navbar and .title, their classnames need to be variable as well.

So we would need more parameters:

=hero($className, $navbarName, $titleName…)

That way you could choose the same classname for .title that you used when calling +title somewhere else:

+title("my-title")

+hero("my-hero", "my-navbar", "my-title")

I'm just wondering how it would work with CSS Modules. If you call +hero in a hero.module.sass file, the .title inside would have a different scope than the one in title.module.sass in which you call +title.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants