5 ms·

IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global nam

IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global namespace. My preferred solution are CSS Modules[1], Vue's scoped styling[2] or something similar. [1] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules [2] https://github.com/vuejs/vue-loader/blob/master/docs/en/features/scoped-css.md https://github.com/vuejs/vue-loader/blob/master/docs/en/feat...

davidkpiano 10y ago
CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.
- vinceguidry 10y ago
  Auto-generation is a good solution because names are the brain's interface to the code. If the names are auto-generated, and the brain doesn't have to look at the auto-generated names, and the abstraction doesn't leak, then you can consider the problem solved.
  - Jasper_ 10y ago
    My devtools still doesn't show me the unmangled name. The abstraction leaks. As a practicality, I prefer the naming conventions to the CSS processing pipeline, because it gives me a much better ability to debug and iterate.
    - Klathmon 10y ago
      With sourcemaps you can get close, but it still shows the "mangled" class name in the HTML. But with a dev/prod environment, you can have your cake and eat it too (for the most part). In dev we have our classnames be in the format of `[classname]---[file-path]---[filename]---[partial-hash]` So one of my classnames from a current project is `.container` in the file, but shows up as `.container---src-components-scanner----styles---1446d`. And in production shows up as `._1533JgnvGu096C2bCAkrxT`.
- MatekCopatek 10y ago
  I agree with vinceguidry's comment. Perhaps I wasn't clear - of course you should be careful about naming things well (one of the hardest problems in CS, right? :P), but using consistent terms, case and the like is one thing. A large part of CSS naming conventions is doing more convoluted stuff such as business-page__contact-form__submit--disabled, just because there are other submit buttons on your website and you don't want some styles to clash. This is the part that is abstracted away by automatic solutions. If your favorite programming language scoped all variables globally, no matter where you defined them, sure you could prefix them with the name of the current function to solve your problem, but it'd be painful and error prone.
- philh 10y ago
  It looks like CSS modules is meaningfully different from being just a naming convention. With a naming convention, if you want to use work from two different packages and they happen to use the same names, you need to edit one of them. People come up with conventions to try to avoid this, like prefixing everything with the package name, but that doesn't fundamentally fix the problem. If two packages have the same name, they clash again. You have a fundamental tradeoff between short prefixes which are easy to work with, and long ones which are less likely to clash. In other systems, when you use a package, you choose the prefix. If two packages use the same names, you just give them different prefixes. Short prefixes are fine, because they don't need to be globally unique. It looks like CSS Modules works the second way, and that's an improvement over just being a naming convention.
- lisper 10y ago
  > CSS Modules is still a "naming convention," just one that is auto-generated for you. Yes, that's true, but your use of the word "just" implies that auto-generation is a detail. It's not. It's the the big win. At root, everything is machine code, which also has a flat namespace. Having that flat-namespace code auto-generated is a huge lever.
  - Klathmon 10y ago
    And it fixes a few other unexpected problems as well. We use SHA1 hashes of the CSS classes' contents as it's name when using CSS modules. This has the cool side effect of making any 2 classes that do the same thing to have the same name, and get de-duped in the final output, regardless of where they originated in the application. When I saw it happen the first time, it really kind of cemented in the idea that this combined with a way to "punch through" the modularity to combine and extend "base" classes and include global colors (for us it's SASS imports) has pretty much "solved" CSS for me.
    - breatheoften 10y ago
      That's a nice trick -- thanks for sharing! Am I write in understanding that implementing this within webpack is simply using only [hash] as the localIdent configuration property for css-loader?
      - Klathmon 10y ago
        yeah, specifically [hash:base64] because [hash] will print the hex of the hash which is a bit more verbose. I think it's actually the default for css-loader if you don't set localIdentName During development we have it set to `[local]---[path]---[name]---[hash:base64:5]` which gives massive verbose class names but lets me pinpoint exactly where they came from. There's also one step that I left out that helps, which is to have something like csscomb[0] to order the properties of each class into a set order. It really lets this optimization shine by ensuring that different property-order won't cause different hashes. [0] https://github.com/csscomb/csscomb.js https://github.com/csscomb/csscomb.js
    - 10y ago
PaulHoule 10y ago
What amazes me is how violently the run-of-the-mill programmer hates namespaces. Despite the fact that managing namespace collision is important for composability (either deliberate or accidental) and code generation. This problem has, for instance, dogged RDF. All the time I hear about programmers who "don't want to learn SPARQL" and I think the heavy use of namespaces is one of the impediments. For most other programming languages it seems the opposite: (i) half of the software managers in the world are driven nuts because their team is screwing around with Vagrant instead of working (ii) it seems no programming task is too boring if you do it in rust or go.
- sjclemmy 10y ago
  That reminds me of a colleague complaining about a recent cohort of about 60 webdev graduates. Not a single one wanted to learn perl, but were quite happy to get stuck into anything Javascript preferably react! EDIT: why the downvotes?
  - rfrey 10y ago
    They're quite rationally looking for assignments that increase their own market value.
    - eonw 10y ago
      learning backwards can be good too.... i know a guy making $200k+ managing some old AS400s, part time, and he is too young to have grown up working on them. old school skills are worth money, and the unwillingness of new entrants to learn them just makes them that much more valuable.
    - PaulHoule 10y ago
      I haven't done anything in Perl since 2005 or so. I think it got eaten pretty much by Python, PHP and Ruby.
  - wvenable 10y ago
    I've worked in enough Perl at one point to actually like it but I would never recommend anyone learn it unless they absolute have to. At this point it's effectively a dead ended language. It's also a terribly difficult language to learn. I don't particularly like the Javascriptification of every technology but these webdev graduates have the right idea.
cel1ne 10y ago
My preferred solution is http://tachyons.io http://tachyons.io because it has a font relative scale for spaces. No more guessing of pixel values.

davidkpiano 10y ago

CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.

vinceguidry 10y ago
Auto-generation is a good solution because names are the brain's interface to the code. If the names are auto-generated, and the brain doesn't have to look at the auto-generated names, and the abstraction doesn't leak, then you can consider the problem solved.
- Jasper_ 10y ago
  My devtools still doesn't show me the unmangled name. The abstraction leaks. As a practicality, I prefer the naming conventions to the CSS processing pipeline, because it gives me a much better ability to debug and iterate.
  - Klathmon 10y ago
    With sourcemaps you can get close, but it still shows the "mangled" class name in the HTML. But with a dev/prod environment, you can have your cake and eat it too (for the most part). In dev we have our classnames be in the format of `[classname]---[file-path]---[filename]---[partial-hash]` So one of my classnames from a current project is `.container` in the file, but shows up as `.container---src-components-scanner----styles---1446d`. And in production shows up as `._1533JgnvGu096C2bCAkrxT`.
MatekCopatek 10y ago
I agree with vinceguidry's comment. Perhaps I wasn't clear - of course you should be careful about naming things well (one of the hardest problems in CS, right? :P), but using consistent terms, case and the like is one thing. A large part of CSS naming conventions is doing more convoluted stuff such as business-page__contact-form__submit--disabled, just because there are other submit buttons on your website and you don't want some styles to clash. This is the part that is abstracted away by automatic solutions. If your favorite programming language scoped all variables globally, no matter where you defined them, sure you could prefix them with the name of the current function to solve your problem, but it'd be painful and error prone.
philh 10y ago
It looks like CSS modules is meaningfully different from being just a naming convention. With a naming convention, if you want to use work from two different packages and they happen to use the same names, you need to edit one of them. People come up with conventions to try to avoid this, like prefixing everything with the package name, but that doesn't fundamentally fix the problem. If two packages have the same name, they clash again. You have a fundamental tradeoff between short prefixes which are easy to work with, and long ones which are less likely to clash. In other systems, when you use a package, you choose the prefix. If two packages use the same names, you just give them different prefixes. Short prefixes are fine, because they don't need to be globally unique. It looks like CSS Modules works the second way, and that's an improvement over just being a naming convention.
lisper 10y ago
> CSS Modules is still a "naming convention," just one that is auto-generated for you. Yes, that's true, but your use of the word "just" implies that auto-generation is a detail. It's not. It's the the big win. At root, everything is machine code, which also has a flat namespace. Having that flat-namespace code auto-generated is a huge lever.
- Klathmon 10y ago
  And it fixes a few other unexpected problems as well. We use SHA1 hashes of the CSS classes' contents as it's name when using CSS modules. This has the cool side effect of making any 2 classes that do the same thing to have the same name, and get de-duped in the final output, regardless of where they originated in the application. When I saw it happen the first time, it really kind of cemented in the idea that this combined with a way to "punch through" the modularity to combine and extend "base" classes and include global colors (for us it's SASS imports) has pretty much "solved" CSS for me.
  - breatheoften 10y ago
    That's a nice trick -- thanks for sharing! Am I write in understanding that implementing this within webpack is simply using only [hash] as the localIdent configuration property for css-loader?
    - Klathmon 10y ago
      yeah, specifically [hash:base64] because [hash] will print the hex of the hash which is a bit more verbose. I think it's actually the default for css-loader if you don't set localIdentName During development we have it set to `[local]---[path]---[name]---[hash:base64:5]` which gives massive verbose class names but lets me pinpoint exactly where they came from. There's also one step that I left out that helps, which is to have something like csscomb[0] to order the properties of each class into a set order. It really lets this optimization shine by ensuring that different property-order won't cause different hashes. [0] https://github.com/csscomb/csscomb.js https://github.com/csscomb/csscomb.js
  - 10y ago

PaulHoule 10y ago

What amazes me is how violently the run-of-the-mill programmer hates namespaces. Despite the fact that managing namespace collision is important for composability (either deliberate or accidental) and code generation. This problem has, for instance, dogged RDF. All the time I hear about programmers who "don't want to learn SPARQL" and I think the heavy use of namespaces is one of the impediments. For most other programming languages it seems the opposite: (i) half of the software managers in the world are driven nuts because their team is screwing around with Vagrant instead of working (ii) it seems no programming task is too boring if you do it in rust or go.

sjclemmy 10y ago
That reminds me of a colleague complaining about a recent cohort of about 60 webdev graduates. Not a single one wanted to learn perl, but were quite happy to get stuck into anything Javascript preferably react! EDIT: why the downvotes?
- rfrey 10y ago
  They're quite rationally looking for assignments that increase their own market value.
  - eonw 10y ago
    learning backwards can be good too.... i know a guy making $200k+ managing some old AS400s, part time, and he is too young to have grown up working on them. old school skills are worth money, and the unwillingness of new entrants to learn them just makes them that much more valuable.
  - PaulHoule 10y ago
    I haven't done anything in Perl since 2005 or so. I think it got eaten pretty much by Python, PHP and Ruby.
- wvenable 10y ago
  I've worked in enough Perl at one point to actually like it but I would never recommend anyone learn it unless they absolute have to. At this point it's effectively a dead ended language. It's also a terribly difficult language to learn. I don't particularly like the Javascriptification of every technology but these webdev graduates have the right idea.

cel1ne 10y ago

My preferred solution is http://tachyons.io http://tachyons.io because it has a font relative scale for spaces. No more guessing of pixel values.