I hate asking to be spoon-fed, but I find it exceptionally difficult to glean anything from context-free slide decks posted to SlideShare. This deck was clearly intended to augment a presentation -- where is that archived?
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)
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.
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.
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.
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.
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.
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.
She says we shouldn't blame the language, but how much of this is because CSS eschews Composition for (incomplete) Multiple Inheritance? And how much of the extra code is an effort to avoid bugs because layout properties are non-orthogonal?
At what point do we decide that it's not that "you're doing it wrong", but that there were actually some design choices that, in retrospect, maybe weren't such a good idea? I'd say that when we have other languages that compile into the language just to overcome these issues (CoffeeScript,Less,SASS,etc.), we've about reached that point.
"much of this is because CSS eschews Composition for (incomplete) Multiple Inheritance?"
Pretty much all of it. I remember being a bit surprised when they first released CSS at just how impotent it was. Over a decade later, I now realize my younger self would have gotten himself stuck in a morass of Turing completeness, but CSS goes too far the other direction.
Decoupling styles (which may contain several rules) from matchers, then allowing a match to apply multiple styles, and permitting simple variables (which I would be OK with restricting to simply "either a single variable or a single string" and not permitting concatenation or anything complicated) would have not significantly increased the complexity, avoids the Turing Tarpit [1], and would have been powerful enough that while the other languages would still have inevitably have emerged eventually they wouldn't have been necessary.
HTML had enough pragmatism in it from day one to survive being academicked. CSS is a classic example of how a beautiful theory can back you into a corner and everyone's too busy chanting the beautiful theory's mantra to notice they're doing it in a terrible way.
("You Must Decouple Content From Presentation." "That's a great idea, but don't you think that we should have something like a variable that represents a color?" "You Question The Value Of Decoupling Content From Presentation." "No, it's just that anybody with a couple of years of experience programming knows that you shouldn't hard-code constants into your files, let alone do it fifty times in a single file." "This Is Declaration, Not Code." "There's no difference; spend some time with Lisp." "You Will Burn For Doubting The Decoupling Of Content From Presentation, Heretic. A Thousand Curses On Your Websites." I've had this conversation a few times, though mercifully it has been a long time now.)
(Oh, and if you want to blow someone's mind, ask them why it's so important to decouple content from presentation. I'm sure some people here can at least articulate a reason but in general people can't, it's just a mantra. Then the mantra answer became "Semantic Web", but then try to get a definition of Semantic Web out of them... and if you get that far, ask where the semantics come from. There's been a staggering amount of what is nearly religion surrounding CSS and it shows in the engineering. Oh, and don't suggest that as long as your content is stored cleanly somewhere, it's OK to apply styles in another layer on the server... if it's not CSS, it's not Semantic and it's not Decoupled. Regardless of the actual architecture behind it.)
Yeah, but not in the way I meant. The way I meant is that you have actual coding abilities in the CSS, because "more power is better". I now understand how that is not true, how it is generally better to be parsimonious with the power in your language (just enough to get the job done), and if you can avoid (convenient) Turing Completeness it's usually a good idea in a declarative UI language. But you can still do forward-declaration non-code replacements without opening the door to Turing-chaos.
It might be the language's fault, but that doesn't make the least bit of difference. CSS is here to stay for the foreseeable future, and she's saying we have learn how to use the tools we're stuck with the best we can.
That is the sad, sad truth of it. At least with CSS compilers and libraries like jQuery, it's getting easier to compensate for CSS' deficiencies. I do, though, still hold onto some hope that someday we'll be able to leave it behind.
Guys who are upvoting, could you please explain to the rest of us what we're supposed to be experiencing here?
I click on the link, I get a slide-deck. No text, no audio, just a bunch of slides with various numbers on them.
Am I missing something? Is this something where a bunch of people saw the presentation live and are now upvoting it here? If so, is there a video link to the live presentation?
Yep, just a slide deck. But it's a very good slide deck presenting something interesting and worth thinking about - that the specificity of css has some fundamental issues, and that we currently work around them in a destined-to-break-and-be-broken manner by moving towards inline CSS declarations and !important.
It would be better as a web page, but the content is still worthwhile.
After watching the presentation I agree that CSS has major issues with reusability and code cleanliness. Though I don't think it's as bad as she makes out; I don't know any developer who refuses to use classes.
I think the approach she takes to solve the problem is wrong though. HTML and CSS like her OOCSS approach promotes is just nasty.
How is coding the layout into the HTML any different from the table based layouts we were doing ten years ago? This is going back to tying your styling directly to your HTML.
Bringing mixins into CSS would solve this in a much nicer way. Define your fonts and columns in a couple of reusable mixins, and then define your site-specific content mixing and matching your reusable components.
The points brought up in these slides directly reflect my experiences over the past 3 years of doing my own CSS.
If you're familiar with the CSS precedence rule, these slides might read like blog post; they did for me.
Strangely, I rarely see the precedence rule brought up in CSS documentation or tutorials. Not until I read "The Ultimate CSS Reference", by Tommy Olsson & Paul O'Brien. I highly recommend this book.
"Coding by Firebug" as it's called in the slides, probably refers to what I used to do before reading the above-mentioned book: tweak styles, wonder why they weren't taking effect, then add classes or IDs to the markup until something sticked. This is the "increasing specificity" also noted in the slides.
Once I understood the CSS rule of specificity - inline, id, class, element - I stopped polluting my markup and CSS.
Nowadays, I generate CSS with SASS partials (templates within a Ruby on Rails app), compiled together by Compass. Each partial starts with an ID at the top, with other ids, classes, or elements nested underneath. These are compiled into CSS - and I'm sure at the CSS level there is TONS of duplication - but this doesn't worry me one bit; my source code is DRY.
I suspect this is what Facebook and the other sites mentioned in the first few slides do too, so the rule duplication is probably not such a code smell as one might think.
The problem with having repetition in your compiled CSS files is that they become bigger as a result. Depending on how much you care about page load speed, this can be an issue.
I'm not entirely sure what she's suggesting since I'm reading the slides without any context, but it seems, given the thing about cutting down css file size for Facebook, the method she's suggesting reduces duplication in the actual css file.
This is not that big a problem, because CSS can be downloaded once, and cached forever. If you add gazillion of classes to your markup, then they got send over the wire each time you load the page.
This seems like it's interesting but could really use some audio. This definitely comes off as a slide deck that someone used in a presentation and wasn't meant to just be read. Does anyone have a video version of this by any chance?
in that example, classitis is when you give a class "item" to every li element, the using .item to style it while the alternate way to do it is using the descendent selector (.parentcontainer li). Nicole Sullivan is saying this can lead to specificity war over time.
By "don't add classes", she means "avoid using redundant or non-semantic classes in the HTML", which makes sense, because unless you're generating the HTML on request or compensating with jQuery (and therefore adding another dependency to your layout), the repetition becomes a maintenance issue.
Avoiding non-semantic elements and non-semantic classes, however, restricts you to using descendant selectors (and multiple declarations), which, as she points out, creates another maintenance issue in the form inheritance conflict resolution (specificity).
My main rule is: Never write a class that you can't use again.
I've other rules too, such as "padding is top, margin is bottom".
CSS must be modular, not exception-based.
That's interesting. I've always wondered if some people had conventions on when to use padding and when to use margin, since you can almost always accomplish the desired effect either way.
If you want to be modular, you must have conventions. This is to prevent double spacing when you put two elements one next to another without additional styling. I also use to have ELEMENT > *:first-child {padding-top: 0} on containers, so that I can control the padding of the container and without having to consider what element I place into it.
There's a lot of best practices I made part of my workflow, perhaps I should write a blog post about it.
You can't really. CSS backgrounds are the main reason you need to use padding (instead of margin): margins exist outside an element, while padding expands within the box itself (beyond the content, but permitting the background to remain visible).
Another best practice I have is to place a comment on each closing element, referring to the opening one.
So,I have:
<div class="CLASS">
CONTENTCONTENTCONTENT
</div> <!-- .CLASS -->
When you have complex pages, with several nesting levels, this can save much, much time.
Isnt there a danger that someone else working on your code might not respect that rule (or dare I say it, but maybe you're in a rush one day) and you don't update the comment when you update the class.
Now you've got comments saying in correct things, and you risk all sorts of confusion.
The same rule applies to commenting methods in code really, you don't comment what the code does exactly - just what the intention of the code is.
It's at times like this when I think that we should seriously reconsider the current browser model. We've reached a point where there's a lot of complexity in the system and we're mostly paying lip service to the original idea of presentation-independent content. And the vestiges of that idea are keeping us back.
If you want something accessible with a "modern" JavaScript-based web application, you're almost bound to rewrite most parts of the interface for a pure HTML version, if at all possible and/or desirable. Quite often less effort than jumping through hoops to have something that degrades gracefully.
Now I think this will only get worse. At one point in time, it might be better to regard HTML as the Gopher of its time and consider a next step. Probably won't ever happen, as the sheer ginormous size of the "legacy" web makes any endeavors in this direction almost futile.
Does anybody remember PostScript-based GUIs? We're throwing a lot of barely-connected ideas and syntaxes into a browser to emulate NeWS/DPS -- poorly.
What if you already have a bunch of custom controls that are common to your app? I'm not suggesting not investigating more efficient selectors or better css practices to target multiple browsers easily, but once you have all the knowledge built up in one place, what do you gain by rewriting it?
When I start a project, if I'm working from scratch I usually rewrite a lot of the css every day, just to achieve the look I'm going for. Once I standardize some things like how text flows, some layouts, and forms, it's time to develop a nice list of css classes you use frequently and tinker with them as needed. Endlessly rewriting css gets you nowhere.