CSS: Our best practices are killing us

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.

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

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)

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

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

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

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