3 ms·

Almost all of this could be handled with a keyword replacing text macro. To me, that says nothing about the design of CSS, rather than nitpicking minor implemen

Almost all of this could be handled with a keyword replacing text macro. To me, that says nothing about the design of CSS, rather than nitpicking minor implementation details. My biggest gripe with the design of CSS is the lack of rules nesting. Having to repeat a selector slug to make a rule for children of something I've already defined gets very verbose. I also find the whole situation with animations nigh inscrutable, but that could be my lack of experience with them. All I know is that it's nearly impossible to guess at the right values for animation rules, even with intellisense hints.

vehemenz 6y ago
Lack of rules nesting is more about CSS's incompatibility with the predominant paradigm of stylesheet design (mapping high abstraction class names to specific elements). And honestly, you can easily solve this problem with preprocessors if you like that way of doing things. Can you give an example of repeating the selector slug to make a rule for children?
- lessthanseventy 6y ago
  I guess something like: foo bar { ...styles } foo bar baz { ...more styles } foo bar baz > bim { ...even more } foo bar baz > bim:not(bop) { ...stuff } instead of a more SCSS like syntax: foo bar { ...styles & baz { ...more styles & > bim { ...even more &:not(bop) ...stuff } } } } SCSS seems like it gets out of control after a while though without rigor from the developers. The last app I worked on had a half-assed SCSS approach that started off with a decent base, and then got tacked onto with a ton of ad-hoc styles that weren't nested where they "belonged." Inconsistent usage of paddings/margins everywhere. It was a mess.
  - vehemenz 6y ago
    Ah, I see. At some level, this is unavoidable and just something to get used to. But those longer selectors can be mitigated somewhat with a sane CSS methodology. One of the benefits of CSS is that there are 100 different ways to achieve the same result—and I personally wouldn't trade that for a more opinionated CSS spec.

vehemenz 6y ago

Lack of rules nesting is more about CSS's incompatibility with the predominant paradigm of stylesheet design (mapping high abstraction class names to specific elements). And honestly, you can easily solve this problem with preprocessors if you like that way of doing things. Can you give an example of repeating the selector slug to make a rule for children?

lessthanseventy 6y ago
I guess something like: foo bar { ...styles } foo bar baz { ...more styles } foo bar baz > bim { ...even more } foo bar baz > bim:not(bop) { ...stuff } instead of a more SCSS like syntax: foo bar { ...styles & baz { ...more styles & > bim { ...even more &:not(bop) ...stuff } } } } SCSS seems like it gets out of control after a while though without rigor from the developers. The last app I worked on had a half-assed SCSS approach that started off with a decent base, and then got tacked onto with a ton of ad-hoc styles that weren't nested where they "belonged." Inconsistent usage of paddings/margins everywhere. It was a mess.
- vehemenz 6y ago
  Ah, I see. At some level, this is unavoidable and just something to get used to. But those longer selectors can be mitigated somewhat with a sane CSS methodology. One of the benefits of CSS is that there are 100 different ways to achieve the same result—and I personally wouldn't trade that for a more opinionated CSS spec.