[utunga]

Probably this one: http://www.webstock.org.nz/talks/speakers/nicole-sullivan/cs...

I attended the talk and the workshop. What is interesting is that it genuinely challenges. Some CSS designers who I really respect did not 'buy in' to her theory even after spending a day with her. However, as a programmer, who has since used the OOCSS in a context 'for real' I found that it does live up to its promise in practice (unlike the CSS 'semantic html/best practice' story, which sounds great in theory but so often becomes spaghetti in practice)

[tremendo]

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.

[utunga]

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 <div class="media_box"> 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 <li> 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.

[robin_reala]

I agree with you for the most part, with one exception. Your workflow is modelled on a hypothetical developer who does markup and backend code, and a CSS guru who does the styling. This approach doesn’t work for the reasons you give, but everything becomes a lot easier if you rejig the responsibilities into:

a) back-end developer who provides the controller, model and a shell view (this could be anything from a basic HTML structure through to raw JSON)

b) front-end developer who has responsibility for building sane markup and clean CSS. It’s in their best interests to keep the styles maintainable: a little extra time writing markup that integrates into the existing styles and refactoring existing CSS to cope with the new modules is worth it in the long run.

[sandGorgon]

Are you, basically, referring to CSS grid frameworks ?

Even if you are not - dont they accomplish the same thing ?

[mokkos]

Yep, it's this one.

I apologize to others for the lack of context that the slide by itself gives. I got the summary of this talk from a co-worker who actually went, so I had the context in back of my mind. The slidedeck naming is still too sensationalist though for what it's actually about: over time, css gets degraded because developers get into a firebug-hack mentality leading to overwrites by specificity until it gets too big and messy to maintain. I'm still not too clear what she's proposing as a solution to this though; she does give an example of her success at facebook, but that example is a one-time fix, not necessarily a practice that stands on its own over time.

[scott_s]

Excellent presentation - she knows how to present well. I still have about ten minutes left, but what surprises me is how unsurprising what she has to say sounds to my ears.

So, I'm not a web designer. I've used CSS before, but just in very small amounts to get basic "here I am" pages up. I'm a systems programmer. That means I spend my days in languages like C, C++ and Python for scripting. I sometimes drop down to assembly. It sounds like she's describing basic good programming practices.