|
|
|
|
|
by sbergot
2029 days ago
|
|
Not OP but here is my version: - css is not scoped by default. Predicting the effect of adding a new rule is very hard if you are not using scoping solutions or if you are not constently writing new class names with a strict convention - because of the first point, css is never refactored in most places. It becomes an ever growing monster of a code base - css selectors are build to write css that depends on html. A lot of webapp should be writing html that depends on a small set of css rules in order to get a consistent ui - the initial "semantic html approach" is counter productive for most webapps. This blog post is a very good read about this particular point: https://adamwathan.me/css-utility-classes-and-separation-of-... |
|
Personally, I'm more interested in HTML as a document format in the original sense. Limited as it is, I just can't fathom the blackout moment where, confronted with a very basic HTML document plus a CSS stylesheet about the same size or more written in a completely different yet redundant syntax, somebody would say "yup, that seems like a reasonable document format for exchanging most of the world's text".
Edit: regarding your scoping requirement, isn't just including the id or class of a component in CSS selectors or, when necessary, sass-like nested CSS rules enough of a scoping mechanism?