3 ms·

Beyond the immediate issues of "what rules do I use to make this thing look this way", the cascade can also make large-scale management and code reuse challengi

by mnutt 8y ago

Beyond the immediate issues of "what rules do I use to make this thing look this way", the cascade can also make large-scale management and code reuse challenging. It's sort of like object-oriented inheritance, except the definitions and instantiations live in totally different places, and the top-level object properties are defined by browser manufacturers, or possibly end-users. Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not to know whether changing it will break something somewhere else. People have developed some techniques to mitigate these issues, but many are unintuitive and don't follow naturally from "make this thing look this way".

_bxg1 8y ago
> It's sort of like object-oriented inheritance With the key difference being that there's no rigid structure to it at all, much less a strict-subset hierarchy. It's really more like structural object types, which can be easily composed, than OOP classes. It's set theory, rather than taxonomy. > Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not This can be easily solved with good project organization. At my day job I maintain a codebase with a couple hundred SCSS files, which are on average a couple hundred lines each. We've organized things well enough that the cascade is a non-issue, and "leftover" styles from an element that's been removed are a rare occurrence. All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles. > don't follow naturally from "make this thing look this way" This is precisely the problem; programmers come from a background where they think in terms of "make it do this thing", and they try to translate that to "make this thing look this way". That's how you create supremely fragile CSS which is impossible to safely make changes to. Instead you should be thinking in terms of, "make it behave this way in the general case, relative to what's around it".
- jacobush 8y ago
  "This can be easily solved with good project organization" "All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles." Super simple. It is what it is and powerful etc, but simple? I have given up. I just use the minimum web tech to get by.
  - mnutt 8y ago
    Yeah, "remember to keep these two files in sync by hand" is the opposite of simple. Like c++ header files, without the benefit of a compiler that will complain at you when you get it wrong.

by mnutt 8y ago

_bxg1 8y ago

> It's sort of like object-oriented inheritance With the key difference being that there's no rigid structure to it at all, much less a strict-subset hierarchy. It's really more like structural object types, which can be easily composed, than OOP classes. It's set theory, rather than taxonomy. > Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not This can be easily solved with good project organization. At my day job I maintain a codebase with a couple hundred SCSS files, which are on average a couple hundred lines each. We've organized things well enough that the cascade is a non-issue, and "leftover" styles from an element that's been removed are a rare occurrence. All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles. > don't follow naturally from "make this thing look this way" This is precisely the problem; programmers come from a background where they think in terms of "make it do this thing", and they try to translate that to "make this thing look this way". That's how you create supremely fragile CSS which is impossible to safely make changes to. Instead you should be thinking in terms of, "make it behave this way in the general case, relative to what's around it".

jacobush 8y ago
"This can be easily solved with good project organization" "All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles." Super simple. It is what it is and powerful etc, but simple? I have given up. I just use the minimum web tech to get by.
- mnutt 8y ago
  Yeah, "remember to keep these two files in sync by hand" is the opposite of simple. Like c++ header files, without the benefit of a compiler that will complain at you when you get it wrong.