
CSS: Our best practices are killing us - mokkos
http://www.slideshare.net/stubbornella/our-best-practices-are-killing-us
======
callahad
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?

~~~
utunga
Probably this one: [http://www.webstock.org.nz/talks/speakers/nicole-
sullivan/cs...](http://www.webstock.org.nz/talks/speakers/nicole-sullivan/css-
tools-massive-websites/)

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.

------
hasenj
The solution is not to codify best practices; the solution is to use a better
language! (This coincides with PG's argument for lisp/macros)

Although the slides do mention sass an lesscss at the last side, I think
'stylus' is a much better css language.

<http://learnboost.github.com/stylus>

IT has powerful abstraction facilities in the form of functions and mixins.

Here's an example of how powerful it can be:

    
    
      vendor(prop, args)
        -webkit-{prop} args
        -moz-{prop} args
        {prop} args
    
      border-radius()
        vendor('border-radius', arguments)
    

Having this abstraction, we can:

    
    
      button
        border-radius 1px 2px / 3px 4px
    

And the output will be:

    
    
      button {
        -webkit-border-radius: 1px 2px / 3px 4px;
        -moz-border-radius: 1px 2px / 3px 4px;
        border-radius: 1px 2px / 3px 4px;
      }

~~~
wvenable
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.

------
T-R
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.

~~~
jerf
"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.)

[1]: <http://en.wikipedia.org/wiki/Turing_tarpit>

~~~
robin_reala
CSS3+HTML apparently is Turing complete: <http://lambda-the-
ultimate.org/node/4222>

~~~
jerf
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.

------
DanielBMarkham
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?

~~~
scott_s
<http://news.ycombinator.com/item?id=2439818>

Posted about ten minutes before you.

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

    
    
        <div class="unit size1of3">
        <b class="top"><b class="tl"></b><b class="tr"></b></b>
    

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.

~~~
rimantas

      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.

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

~~~
ahlatimer
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.

~~~
rimantas
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.

------
bretthopper
So the prime example of what not to do is the sidebar/h3 example. Then the
example for what to do is a simple example from Facebook.

How about showing us how to actually solve the first problem?

For anyone wanting to know more about this presentation, check out her Object
Oriented CSS: <https://github.com/stubbornella/oocss>

~~~
scott_s
Perhaps a better staring place, with more context: <http://oocss.org/>

------
torme
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?

~~~
ideamonk
Some slides towards the end, i.e. 5 1 8 unique numbers one match with
<http://www.youtube.com/watch?v=j6sAm7CLoCQ>

------
catshirt
per the slideshow, 3 "best practice myths":

 _\- don't add any extra elements

\- don't add classes

\- use descendent selectors exclusively_

the second two i've never heard in my life, and i'm quite sure the first is
not a myth.

~~~
mokkos
she's referring to "classitis":
<http://www.sitekin.com/blogdetail/avoid_CSS_Classitis>

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.

------
zachrose
My god, people! Sass! Use it!

~~~
andybak
Doesn't she specifically say in the presentation that Sass is not a solution?

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

~~~
waterside81
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.

~~~
joahua
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).

To visualize it, <http://hicksdesign.co.uk/boxmodel/> is probably the most
oft-cited example - certainly the one I find most helpful.

~~~
Facens
Ok, I was talking about transparent elements, where in fact you have complete
choice (at least if you have no borders too).

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

------
filiwickers
Here is a video presentation on a similar subject from last year.

[http://www.stubbornella.org/content/2010/07/01/top-5-mistake...](http://www.stubbornella.org/content/2010/07/01/top-5-mistakes-
of-massive-css/)

------
lovamova
The best practice for CSS is to continuously rewrite it. Don't be lazy, just
do it.

~~~
tjarratt
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.

------
contextfree
I wish she'd write a book.

~~~
chriseppstein
I've heard rumors of just that.

