8 ms·

CSS: Our best practices are killing us

168 points by mokkos 15y ago

torme 15y ago
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 15y ago
  Some slides towards the end, i.e. 5 1 8 unique numbers one match with http://www.youtube.com/watch?v=j6sAm7CLoCQ http://www.youtube.com/watch?v=j6sAm7CLoCQ
contextfree 15y ago
I wish she'd write a book.
- chriseppstein 15y ago
  I've heard rumors of just that.
bretthopper 15y ago
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 https://github.com/stubbornella/oocss
- scott_s 15y ago
  Perhaps a better staring place, with more context: http://oocss.org/ http://oocss.org/
callahad 15y ago
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 15y ago
  Probably this one: http://www.webstock.org.nz/talks/speakers/nicole-sullivan/css-tools-massive-websites/ 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)
  - scott_s 15y ago
    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.
  - mokkos 15y ago
    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.
lovamova 15y ago
The best practice for CSS is to continuously rewrite it. Don't be lazy, just do it.
- tjarratt 15y ago
  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.
T-R 15y ago
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 15y ago
  "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 http://en.wikipedia.org/wiki/Turing_tarpit
Facens 15y ago
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 15y ago
  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 15y ago
    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/ http://hicksdesign.co.uk/boxmodel/ is probably the most oft-cited example - certainly the one I find most helpful.
    - Facens 15y ago
      Ok, I was talking about transparent elements, where in fact you have complete choice (at least if you have no borders too).
  - meeker 15y ago
    Except that adjacent vertical margins collapse on each other, so the space is the larger of the 2 margin values not the sum. more info: http://reference.sitepoint.com/css/collapsingmargins http://reference.sitepoint.com/css/collapsingmargins This is not true of padding (unless you count a bug in IE8 where percentage-based padding-bottom collapses on the margin-bottom)
  - mikeklaas 15y ago
    In my experience, that is almost never the case, except when you're faking margin by using padding. In that case, use margin.
DanielBMarkham 15y ago
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 15y ago
  http://news.ycombinator.com/item?id=2439818 http://news.ycombinator.com/item?id=2439818 Posted about ten minutes before you.
- pkteison 15y ago
  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.
wotsrovert 15y ago
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 15y ago
  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 15y ago
    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.
filiwickers 15y ago
Here is a video presentation on a similar subject from last year. http://www.stubbornella.org/content/2010/07/01/top-5-mistakes-of-massive-css/ http://www.stubbornella.org/content/2010/07/01/top-5-mistake...
catshirt 15y ago
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 15y ago
  she's referring to "classitis": http://www.sitekin.com/blogdetail/avoid_CSS_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.
- T-R 15y ago
  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).
zachrose 15y ago
My god, people! Sass! Use it!
- andybak 15y ago
  Doesn't she specifically say in the presentation that Sass is not a solution?
hasenj 15y ago
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 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 15y ago
  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.
underwater 15y ago
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"> 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 15y ago
 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.
mhd 15y ago
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.

168 points by mokkos 15y ago

torme 15y ago

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 15y ago
Some slides towards the end, i.e. 5 1 8 unique numbers one match with http://www.youtube.com/watch?v=j6sAm7CLoCQ http://www.youtube.com/watch?v=j6sAm7CLoCQ

contextfree 15y ago

I wish she'd write a book.

chriseppstein 15y ago
I've heard rumors of just that.

bretthopper 15y ago

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 https://github.com/stubbornella/oocss

scott_s 15y ago
Perhaps a better staring place, with more context: http://oocss.org/ http://oocss.org/

callahad 15y ago

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 15y ago
Probably this one: http://www.webstock.org.nz/talks/speakers/nicole-sullivan/css-tools-massive-websites/ 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)
- scott_s 15y ago
  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.
- mokkos 15y ago
  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.

lovamova 15y ago

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

tjarratt 15y ago
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.

T-R 15y ago

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 15y ago
"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 http://en.wikipedia.org/wiki/Turing_tarpit

Facens 15y ago

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 15y ago
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 15y ago
  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/ http://hicksdesign.co.uk/boxmodel/ is probably the most oft-cited example - certainly the one I find most helpful.
  - Facens 15y ago
    Ok, I was talking about transparent elements, where in fact you have complete choice (at least if you have no borders too).
- meeker 15y ago
  Except that adjacent vertical margins collapse on each other, so the space is the larger of the 2 margin values not the sum. more info: http://reference.sitepoint.com/css/collapsingmargins http://reference.sitepoint.com/css/collapsingmargins This is not true of padding (unless you count a bug in IE8 where percentage-based padding-bottom collapses on the margin-bottom)
- mikeklaas 15y ago
  In my experience, that is almost never the case, except when you're faking margin by using padding. In that case, use margin.

DanielBMarkham 15y ago

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 15y ago
http://news.ycombinator.com/item?id=2439818 http://news.ycombinator.com/item?id=2439818 Posted about ten minutes before you.
pkteison 15y ago
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.

wotsrovert 15y ago

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 15y ago
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 15y ago
  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.

filiwickers 15y ago

Here is a video presentation on a similar subject from last year. http://www.stubbornella.org/content/2010/07/01/top-5-mistakes-of-massive-css/ http://www.stubbornella.org/content/2010/07/01/top-5-mistake...

catshirt 15y ago

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 15y ago
she's referring to "classitis": http://www.sitekin.com/blogdetail/avoid_CSS_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.
T-R 15y ago
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).

zachrose 15y ago

My god, people! Sass! Use it!

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

hasenj 15y ago

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 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 15y ago
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.

underwater 15y ago

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"> 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 15y ago
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.

mhd 15y ago

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.