3 ms·

It requires discipline beyond the capabilities of many organizations to structure CSS so that it's maintainable. The ubiquity of `!important` is not so much "a

It requires discipline beyond the capabilities of many organizations to structure CSS so that it's maintainable. The ubiquity of `!important` is not so much "a sign you may not understand the cascade properly" as a sign that the cascade is a flawed design that falls apart in practice.

nawgz 5y ago
Step 1: Write component-based UIs Step 2: Give each component a unique name Step 3: Repeat this principle even for building routes Step 4: your CSS will struggle to clash, no matter how hard you try The cascading is pretty nice actually. Think about using CSS vars... you can dynamically theme apps because of the cascade, by changing just 1 class. there's other nice attributes, and it's true it requires discipline. Just not nearly as much as you imply
- rectang 5y ago
  When hunting down a function you want to deprecate/remove in your private imperative language codebase, you can probably find all call sites just by grepping — and even if you miss some, in most cases you'll get a hard error of some kind (either compile time or runtime) after removal. But with the cascade, call sites are implicit — and removal, for better and worse, doesn't cause a hard error. All it takes is a single rogue engineer or product manager to mess things up. And then cleaning things up later is difficult because of all the places that have to be inspected.
- shadowgovt 5y ago
  Step 2 demands there be a way for one developer to control the global namespace. That's completely impractical[0] given inclusion of 3rd-party code and no enforceable standard for imposing step 2 on other developers. (Web components now exist to facilitate this, but of course, web components are relatively recent; most of CSS's history did not support this 4-step process). [0] To be fair, maybe completely is too strong an assertion. I've seen something like it done... A compiler rewrites the CSS selectors and the CSS classes to create a sort of top-level namespace by prepending some garbage per module so that no component can accidentally reference another component. It's not great for debuggability (about as much fun as having to deal with the actual entrypoint names in the binary for constructors and overloads when debugging C++), but it gets the job done.
  - nawgz 5y ago
    > Step 2 demands there be a way for one developer to control the global namespace I mean, I just prepend all my component class names with my library name or a shorthand acronym, so 100% of my styles are like `.NawgzInput {}` or `.NawgzGraphNode {}` I have never seen the limitation to this approach (i.e. the ends of its ability to scale), so long as you don't pick a super generic prefix. So to hear you assert this approach is "completely impractical" to someone who has used it to build their own component library that every application they build is entirely comprised of.. rings hollow
    - shadowgovt 5y ago
      You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. That's the best I think we have now. It's not good (i.e. decreases readability), and it's not universal (there are definitely component frameworks out there where the classes are just named "table" and "button").
      - nawgz 5y ago
        > You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. Except it's incredibly easy to debug and avoids most of your complaints about the solution. Anyways, fair enough, I can confess that there is probably another ideal world that has better viewport styling. But CSS is giving us incredible flexibility, and just like JS, its warts can be worked around very easily and deliver you a powerful, useful, simple set of capabilities.
- Pxtl 5y ago
  If component-based UIs are such a good idea, maybe the w3c shouldn't have designed literally every piece of the HTML/CSS/JS infrastructure around global namespaces, particularly ones where every declaration is global by default in the case of CSS and HTML IDs. "Global all the things" seems to clash with "component".

nawgz 5y ago

Step 1: Write component-based UIs Step 2: Give each component a unique name Step 3: Repeat this principle even for building routes Step 4: your CSS will struggle to clash, no matter how hard you try The cascading is pretty nice actually. Think about using CSS vars... you can dynamically theme apps because of the cascade, by changing just 1 class. there's other nice attributes, and it's true it requires discipline. Just not nearly as much as you imply

rectang 5y ago
When hunting down a function you want to deprecate/remove in your private imperative language codebase, you can probably find all call sites just by grepping — and even if you miss some, in most cases you'll get a hard error of some kind (either compile time or runtime) after removal. But with the cascade, call sites are implicit — and removal, for better and worse, doesn't cause a hard error. All it takes is a single rogue engineer or product manager to mess things up. And then cleaning things up later is difficult because of all the places that have to be inspected.
shadowgovt 5y ago
Step 2 demands there be a way for one developer to control the global namespace. That's completely impractical[0] given inclusion of 3rd-party code and no enforceable standard for imposing step 2 on other developers. (Web components now exist to facilitate this, but of course, web components are relatively recent; most of CSS's history did not support this 4-step process). [0] To be fair, maybe completely is too strong an assertion. I've seen something like it done... A compiler rewrites the CSS selectors and the CSS classes to create a sort of top-level namespace by prepending some garbage per module so that no component can accidentally reference another component. It's not great for debuggability (about as much fun as having to deal with the actual entrypoint names in the binary for constructors and overloads when debugging C++), but it gets the job done.
- nawgz 5y ago
  > Step 2 demands there be a way for one developer to control the global namespace I mean, I just prepend all my component class names with my library name or a shorthand acronym, so 100% of my styles are like `.NawgzInput {}` or `.NawgzGraphNode {}` I have never seen the limitation to this approach (i.e. the ends of its ability to scale), so long as you don't pick a super generic prefix. So to hear you assert this approach is "completely impractical" to someone who has used it to build their own component library that every application they build is entirely comprised of.. rings hollow
  - shadowgovt 5y ago
    You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. That's the best I think we have now. It's not good (i.e. decreases readability), and it's not universal (there are definitely component frameworks out there where the classes are just named "table" and "button").
    - nawgz 5y ago
      > You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. Except it's incredibly easy to debug and avoids most of your complaints about the solution. Anyways, fair enough, I can confess that there is probably another ideal world that has better viewport styling. But CSS is giving us incredible flexibility, and just like JS, its warts can be worked around very easily and deliver you a powerful, useful, simple set of capabilities.
Pxtl 5y ago
If component-based UIs are such a good idea, maybe the w3c shouldn't have designed literally every piece of the HTML/CSS/JS infrastructure around global namespaces, particularly ones where every declaration is global by default in the case of CSS and HTML IDs. "Global all the things" seems to clash with "component".