3 ms·

I didn't find there to be much substance in this article. I would have preferred more examples of ways in which there are "too much CSS", and the ways in which

I didn't find there to be much substance in this article. I would have preferred more examples of ways in which there are "too much CSS", and the ways in which it is a "continuing tradgedy", instead of a retrospective about the wider state of the web. The measurement units section was interesting, the introduction had me primed to expect more of that, but I was left generally wanting.

willio58 3y ago
Fully agree. Seems like the author pointed out one thing - that there are increasing numbers of units usable in CSS, doesn't really talk about why that's bad, and then wraps it up. I think there's a general anxiety some devs have about how much CSS has been developed in the past few years, and I think that partially comes from not being able to keep track of all the changes anymore. Like it wasn't uncommon a few years ago to have a few CSS experts on your team that felt comfortable with every single thing in the CSS spec, but now that's becoming a little less common as the spec and implementation in browsers evolve and grow. But I think that doesn't mean there's a "tragedy" of CSS. I think it means CSS is becoming more complex, but to me it's generally been in the right direction.
rikroots 3y ago
My three examples of "CSS bloat" - by which I mean "interesting but do we really need them?" are: + CSS Colors[1] - very nice to have, but do we need all of them? Given the chance, I mostly stick to oklab() and oklch() nowadays; I don't see myself reaching for color('a98-rgb' ...) anytime in the near future. + CSS Houdini[2] - giving us devs the power to extend the CSS engine in interesting and innovative ways is very exciting ... but a lot of the functionality requires JS help (why-oh-why use JS classes as part of the definition process?) which is going to be problematic for environments that ignore or suppress JS + CSS Animation[3] - I like this functionality (the granularity of control is very welcome!), but we also have CSS transition[4] and I've never understood the need to have two animation systems when a single system could have covered all situations (I expect there's a really good explanation somewhere but I've never gone looking for it). [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value https://developer.mozilla.org/en-US/docs/Web/CSS/color_value [2] - https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini [3] - https://developer.mozilla.org/en-US/docs/Web/CSS/animation https://developer.mozilla.org/en-US/docs/Web/CSS/animation [4] - https://developer.mozilla.org/en-US/docs/Web/CSS/transition https://developer.mozilla.org/en-US/docs/Web/CSS/transition
- tehbeard 3y ago
  regarding 3 and 4. The clue to them is in the names. CSS Animation works well for complex multi-step animations. Things where having to think about keyframes and iteration loops and stop/starts isn't an excessive burden for something that'll be used in a few key areas to create something visually interesting. CSS Transitions meanwhile, is for changes from one state to another (normal <-> hover , checked <-> unchecked). Much more common, simpler visual flourishes that are more about giving hints to the user than visual eye candy.

willio58 3y ago

Fully agree. Seems like the author pointed out one thing - that there are increasing numbers of units usable in CSS, doesn't really talk about why that's bad, and then wraps it up. I think there's a general anxiety some devs have about how much CSS has been developed in the past few years, and I think that partially comes from not being able to keep track of all the changes anymore. Like it wasn't uncommon a few years ago to have a few CSS experts on your team that felt comfortable with every single thing in the CSS spec, but now that's becoming a little less common as the spec and implementation in browsers evolve and grow. But I think that doesn't mean there's a "tragedy" of CSS. I think it means CSS is becoming more complex, but to me it's generally been in the right direction.

rikroots 3y ago

My three examples of "CSS bloat" - by which I mean "interesting but do we really need them?" are: + CSS Colors[1] - very nice to have, but do we need all of them? Given the chance, I mostly stick to oklab() and oklch() nowadays; I don't see myself reaching for color('a98-rgb' ...) anytime in the near future. + CSS Houdini[2] - giving us devs the power to extend the CSS engine in interesting and innovative ways is very exciting ... but a lot of the functionality requires JS help (why-oh-why use JS classes as part of the definition process?) which is going to be problematic for environments that ignore or suppress JS + CSS Animation[3] - I like this functionality (the granularity of control is very welcome!), but we also have CSS transition[4] and I've never understood the need to have two animation systems when a single system could have covered all situations (I expect there's a really good explanation somewhere but I've never gone looking for it). [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value https://developer.mozilla.org/en-US/docs/Web/CSS/color_value [2] - https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini [3] - https://developer.mozilla.org/en-US/docs/Web/CSS/animation https://developer.mozilla.org/en-US/docs/Web/CSS/animation [4] - https://developer.mozilla.org/en-US/docs/Web/CSS/transition https://developer.mozilla.org/en-US/docs/Web/CSS/transition

tehbeard 3y ago
regarding 3 and 4. The clue to them is in the names. CSS Animation works well for complex multi-step animations. Things where having to think about keyframes and iteration loops and stop/starts isn't an excessive burden for something that'll be used in a few key areas to create something visually interesting. CSS Transitions meanwhile, is for changes from one state to another (normal <-> hover , checked <-> unchecked). Much more common, simpler visual flourishes that are more about giving hints to the user than visual eye candy.