[crazygringo]

I feel like you're looking at the past through rose-colored glasses, my friend.

> Websites like csszengarden.com showed us the promise of style sheets

That site was always highly artificial -- huge deficiencies in CSS meant that it always wound up being tightly coupled to the HTML structure for any non-trivial site.

> I always felt proud to make a website with only semantic HTML and CSS, and it always worked well. Even with all the browser issues (namely those of IE6), it was easy to write cross-browser compatible code that was clean and beautiful.

I don't think any language has ever frustrated me more than CSS. It never worked well (float bugs? box models? browser hacks? z-index problems? vertical centering? insane precedence rules?) and was anything but clean and beautiful.

The reason for the proliferation of tools like LESS or frameworks has been exactly to address some of the huge warts and problems of CSS (like no variables, no local namespacing, etc.) -- because these bring some desperately-needed sanity back to the CSS codebase for a large site.

I agree that there are way too many choices and not enough standardization around CSS best practices -- but the original problem here was the gigantic deficiences in CSS in the first place. CSS was never "clean and beautiful", it was and continues to be an eternal headache.

[madeofpalk]

> It never worked well

Don't confused 'it never worked well' with 'i never understood how it worked'.

'Good'[1] front-end/CSS developers have a very good understanding of float quirks, the box model and how to properly vertically centre things.

Just because I don't understand how pointers in C work doesn't mean that C doesn't work well.

But yes - CSS isn't ideal.

[1] Where 'good' is similar to 'stockholm syndrom'

[ssalazar]

> Don't confused 'it never worked well' with 'i never understood how it worked'. 'Good'[1] front-end/CSS developers have a very good understanding of float quirks, the box model and how to properly vertically centre things.

Great. How many "good" CSS developers are there, and what is their hourly rate? If average developers still can't figure it out after its been around for a decade (see [1]), then the language has failed. At the end of the day CSS needs to usable for regular programmers, or its not very useful as a core framework for the Web.

[1] http://howtocenterincss.com/

[untog]

'Good'[1] front-end/CSS developers have a very good understanding of float quirks, the box model and how to properly vertically centre things.

That doesn't mean "it worked well", it means "people had to learn to cope with its deficiencies". I don't see that as a particularly good thing.

[mangeletti]

Re: your comment and the others below

The variables argument is the only one I can truly get on board with. I really wanted variables. Find + replace in your editor for something like #fafaf0 isn't exactly error-prone or hard to do, so it wasn't ever a huge problem, but variables would have been very nice.

Pertaining namespaces, that's what the cascading part was made for. I had 4000+ line CSS files for large ecommerce websites where I had 5 different declarations of some classes (e.g., .item), but using proper selectors and understanding specificity meant never having a problem.

Pertaining large files, @import(...) always worked for me. For the most part, I'd use one large file (hence 4000+ line files mentioned above) because it helped with load speed, which did suggest that there was value in a build tool that would read @import(...) statements and pull those files into one large file after the fact. But this didn't mean we needed a framework with its own syntax, etc.... even today, tools like django-pipeline will pull in and combine CSS files for you, in the order given, so that you can write your files separately and have them combined after.

Pertaining z-index, I never had an issue with this, except with drop-down menus, but even then it was intuitive and consistent that the next element down will be 1 layer above the one directly above it, and it was also intuitive that nested elements' implicit z-indexes would be relative to their parents, etc.