CSS: Our best practices are killing us

I liked the presentation, she clearly knows CSS well, but do count me amongst those that did not buy in to her theory. I've seen plenty of horrific stylesheets and seen some that over time turn into incomprehensible messes, but I didn't see in this presentation any real connection from follow best practices, result in unmaintainable CSS. It just doesn't follow. That some coder come-lately can get in there and instead of adapting a stylesheet intelligently just starts throwing random hooks here and there and bam! suddenly we have another mess...? it happens, too often. Can that in any way be ameliorated by not following best practices to begin with? by not doing semantic markup? how? makes no sense.

A better language (that compiles to CSS) won't solve the problems presented in the slide. I have to admit, my CSS tends to get ugly over time simply because the cascading and specificity rules in CSS so are complicated. And sass and less don't change that, they just make it easier to repeat yourself when it is required.

In my experience, that is almost never the case, except when you're faking margin by using padding.

In that case, use margin.

I think it comes down to a workflow thing - the reason the coder-come-lately comes in and messes with css in such an annoying way is because its just scary as heck to 'refactor' css in a way that you can be confident about (ie the exact opposite of working with good application level code, with good test coverage)..

So, let's say you (or your team) is tasked with 'add a new calendar widget to the right column'. What you build, obviously spans across quite a few different places you're going to need a bunch of code and db access in the back end, some sort of template for layout of your html, some js, probably, and some css changes to make it all happen. You can do the code layer by refactoring some of the existing methods and keeping things 'elegant' per the original design.

For the HTML, its almost certainly going to be an additive process, but that's OK because its a good way to know you are not messing with existing functionality, and hey, this is a new thing we're displaying here, so that's OK.

For the css, the 'elegant' way to do it, is to refactor the existing classes. For instance maybe you realise the calendar is kinda a mix of the style for that upcoming events widget, and the new calendar look, maybe you refactor out what is common into a '.narrow_widget' class and just define the bit that is particular to the calendar in the '.calendar_widget' class. But unfortunately, in practice, one little change to CSS can affect things just about anywhere in the site, and it might all come acropper on any of a large number of browsers in a large number of contexts and pages..

With no automated tests, what is a developer to do? Understand the elegantly designed stylesheet and carefully refactor it, or just go for the additive approach? Almost certainly they add a bunch of css rules at the bottom of 'page_styles.csss' with a bit more specificity than before, as pages get built and features added.. these rules gain ever more and more specificity...

As nicely put by mokkos below, this is basically a recipe for 'developers getting into a firebug-hack mentality leading to overwrites by specificity until it gets too big and messy to maintain'. And I dont think you can really blame them.

So, instead of asking the developers to do the impossible, the solution offered, is, basically 'developers don't write CSS' but put some of the display logic into the HTML. You don't require that every new feature has to involve 'css guru to add some 'special' CSS for this particular widget or ask the developer to do CSS, the developer can do 'layout' control in html and get the job done, by relying on a toolkit of battle tested HTML/CSS patterns that are supported by the included oocss.css file.

This means violating the sacred principle of 'semantic html' - because to achieve this you have to put some of the presentation logic into the HTML.

The 'semantic html' way to do it would be to write the minimal html to represent what the thing you are saying is - ie its a list of dates - so use ul, li with p tags for the events, and then add a class like 'calendar_chooser' around the lot and then carefully tweak the CSS to get it to 'look right'.

The OOCSS way is you have certain basic widgets - not functional level widgets - but really fine grained, low level display widgets (eg 'a box with something on left and some sort of text area on the right') defined in the CSS and as a developer you know that if you add a around each of the date boxes inside your calendar, you can be sure the little label text for each event, showing what the event is (if any) will appear on the right of the date (or something like that).

That sounds terrible, because the html, is going to be a whole lot more wordy - you need to specify in your html essentially how you want things to look - and it violates the principle of semantic html. It would be more 'elegant' to just say that for an within a .calendar_widget the date goes on left and the event text on right. But this is a much more practical solution for the real world.

As a developer you are not writing CSS, just adding divs and giving them classes. You might tweak the layout with margins but there are common css classes to for things like 'medium margin on right' that mean that margins can be made consistent across the site, etc.

Because the OOCSS library is supposedly well designed you can be confident that it will work OK for any browser at any width, and for device or whatever. So its a bit like a return to dreaded tables, in that the developer writes HTML, gets things to look how they want and they are done. (I imagine that correspondingly OOCSS would have to suffer from similar problems of not being able to reflow content for a completely different device or context, but in practice, just how far do we need to go with this - i mean you want to lose a column from right for mobile and move nav to the top or whatever, but I've never heard of a need to, for instance, completely redesign the look of things within an element like a calendar widget to make it look right on a mobile device).

Bottom line you think you'll end up more html, but less CSS. But, in practice it appears that (especially across large sites like facebook) you end up with considerably reduced page size in both HTML and CSS overall.. at least that's what Ms Sullivan's stats appear to say.

Something like that. So kinda like moving back to tables, just not all the way.

  How is coding the layout into the HTML any different from
  the table based layouts we were doing ten years ago?

It is not. Three things irritate me when talking of CSS: reset stylesheets, grid frameworks and oocss.

Luckily SASS solves or alleviates most of the problems they are supposed to solve.