[mangeletti]

I might be a majority shareholder of the following opinion, but I feel like it needs to be said.

CSS was an art, and a science. Websites like csszengarden.com showed us the promise of style sheets, and the galleries of "CSS sites" during the mid to late 2000s demonstrated what amazing works could be taken from photoshop (and Fireworks!) and made into beautiful, pixel-perfect layouts. 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. The (C)ascading part of CSS was still considered a feature, and deeply understanding its implications was an acceptable challenge.

Then came The Age of Great Coupling & Frameworks (made that name up) wherein CSS began to be regarded as a hindrance. Frameworks like Bootstrap became the status quo, because it meant you could go from 0% to 60% in half the time. But, no longer did anybody decide to go to 100%. The coupling I speak of isn't just a coupling of backend to frontend technologies, but a coupling of backend to frontend workflows. In a subconscious effort to become more efficient, we, as software engineers, began to find ways to incorporate automatic solutions for every problem (e.g., LESS). This is partly due to the very slow nature of completing and proliferating new CSS specifications, but in the long run all of these tools and frameworks have grown the barriers of entry, and have bifurcated the community in many ways (e.g., LESS vs SASS, responsive framework vs pure CSS, non-standard with polyfill vs standard, etc.).

These differences are not the kinds of differences that cause anger (usually), but they make it hard to hire and train, and they make it hard for frontend engineers to work together easily. At the end of the day we're all building CSS and HTML with JavaScript, but if I strike up a conversation with 3 different frontend engineers, each will be as different as if I had chosen to talk to an astronaut, a vet tech, and a professional swimmer. That's almost no exaggeration. Diversity of skills and tasks within an occupation is a good thing, but at some extreme it decreases mobility. When I felt like I had learned CSS, well years ago, the thought never crossed my mind that someday choosing a CSS-related tool would be as much a career decision as choosing a primary programming language to focus on.

FTR, I don't have solutions for the problems I pointed out, nor do I think we should somehow reset and go back to the past, but I feel strongly that we've made things more complicated than they need to be.

[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.

[acjohnson55]

We probably shouldn't forget that a lot of the old-school CSS stuff were hacks meant to get around limitations in the standards. In isolation, they were pretty cool, but in terms of composability, maintainability, and compatibility, they were a nightmare. Life pre-SASS sucked, and even pre-BEM it was pretty horrible once an app started to sprawl. There's still a place for all of the great little CSS techniques, but just factored into mixins, where the implementation can be encapsulated, and represented by something much smaller that represents the effect.

You're right that there's a bewildering number of technologies and approaches out there, but I think we're actually converging towards something sane. Certain waypoints are basically being agreed upon. Sure, we have SASS/LESS/Stylus/PostCSS, but ultimately people use them 95% identically, and that commonality was a huge win. BEM has similarly been a huge win, wand widely adopted. Reading the OP, I was nodding my head along as I read, and I think they're on to something really good. We're getting close to a point where we'll have easy to write, easy to employ, semantically meaningful styles with a more or less transparent build process.

[err4nt]

I agree with you! Most people miss or don't understand the _cascading_ part of CSS. If you have well written markup, you can write beautiful CSS that removes much of the need for precompilers like SASS and Less and the hundreds of lines of code they output.

I'm still in the business of full-custom HTML+CSS+JS craftsmanship.

[untog]

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

And that's all it was - promise. There is a reason why CSS Zen Garden was just an example using a single page as a template.

In reality, people now make webapps of incredible size. A lot of what CSS Modules seems to be trying to fix is exactly that - how to maintain a lot of styles without namespace clashing, one giant CSS file, etc. etc.

I spent a lot of time dealing with all that, so I don't look back at the past in a positive way. I'm not saying CSS Modules is the answer, but it's interesting at least.