1. Everyone trying to build a do-all-the-things-junk-ware-drag-and-drop system. Turns out fixed styles are a pain with complex widgets that are supposed to talk to one-another.
2. Turns out that designing something for just desktops was a mistake - media queries sort-of came to the rescue for print/mobile. But opening the door for extensions like this made it all-to-easy to want to simplify/re-use stuff.
3. Semantic HTML was too light-weight. Everyone building single page apps wanted views, html turned into a sort of weird GUI structure language with semantic sprinkled on top, and it was incredibly tempting to see CSS as a main driver of that view (inline styles were awkward but CSS allowed you to sort-of-obviate that).
So we grew weird CSS/HTML extensions that turned into (DSL) languages that got folded back into CSS in a lot of cases.
If we could start over I'd scuttle CSS/HTML separation, styling would just be part of html and html would have first class support for templates. You wouldn't need to cascade anything, because the HTML would just know what it was supposed to look like, and practically auto-cascade. If there were any "style sheets", they would be just default value lists, and again, they would be a part of the html standard, not a separate "standard".
Which I think is practically what CSS used to be, lists of values that applied to various elements. This made it easy e.g. for early web to allow per-user customization by providing access to those lists, or in-browser modification of those values for quick feedback cycles. The mistake was calling it CSS and HTML's shortcomings, not how it functioned.
1. Everyone trying to build a do-all-the-things-junk-ware-drag-and-drop system. Turns out fixed styles are a pain with complex widgets that are supposed to talk to one-another.
2. Turns out that designing something for just desktops was a mistake - media queries sort-of came to the rescue for print/mobile. But opening the door for extensions like this made it all-to-easy to want to simplify/re-use stuff.
3. Semantic HTML was too light-weight. Everyone building single page apps wanted views, html turned into a sort of weird GUI structure language with semantic sprinkled on top, and it was incredibly tempting to see CSS as a main driver of that view (inline styles were awkward but CSS allowed you to sort-of-obviate that).
So we grew weird CSS/HTML extensions that turned into (DSL) languages that got folded back into CSS in a lot of cases.
If we could start over I'd scuttle CSS/HTML separation, styling would just be part of html and html would have first class support for templates. You wouldn't need to cascade anything, because the HTML would just know what it was supposed to look like, and practically auto-cascade. If there were any "style sheets", they would be just default value lists, and again, they would be a part of the html standard, not a separate "standard".
Which I think is practically what CSS used to be, lists of values that applied to various elements. This made it easy e.g. for early web to allow per-user customization by providing access to those lists, or in-browser modification of those values for quick feedback cycles. The mistake was calling it CSS and HTML's shortcomings, not how it functioned.