Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Classes? Where We’re Going, We Don’t Need Classes!

Classes, classes, classes everywhere. What if we don’t need CSS classes at all? What if we stopped worrying about how many classes we’re using and what we should be calling them and just finished with them once and for all? It would be no revelation to you to say that HTML elements can be styled without recourse to the class attribute, but have you considered the multitude of benefits that come from forgoing classes altogether?

In the article, I’ll demonstrate that the class is as antiquated and inappropriate for styling as the table is for layout, and that omitting them can discipline us to create more usable, reusable content. I appreciate that this is a contentious subject; I’ll meet you in the comments.

(For those who aren’t “of a certain age,” the title of this article is a play on a famous line1 from the 1980s film Back to the Future.)

It’s Not About Maintainability Link

In her recent presentation “Our Best Practices Are Killing Us2,” Nicole Sullivan addresses the horrors of maintaining inefficient style sheets. Sullivan offers some helpful ideas and observations, especially for dealing with the convoluted code of major longstanding clients. My approach is more cavalier; if the style sheet schema I’m dealing with is so convoluted that it could affect the website’s performance all by itself, then I’ll do one of three things:

  • Consider a different client,
  • Consider a different career,
  • Stop using Drupal.

Maintainability is a problem, but it’s a problem for coders by coders, and CSS classes, as Sullivan points out, aren’t even the main culprit. The class attribute is implicated in a much graver crime, and usability—not maintainability—is ultimately at stake. Rather than the overuse of classes, I question the efficacy of the class attribute per se.

The Class As Imposter Link

A few years back, a girlfriend of mine gave me the pet name Stinky. I appreciate that this might seem off topic; please bear with me. She assured me that the name was actually not due to any malodor, but rather had some cryptic link with a fond childhood memory. Nonetheless, it was not a moniker that I wished anyone else to know about. Well, until now—but it’s important for my argument.

Name label3
View image4.

CSS classes5 are a lot like pet names. They are coined in private, where they belong and usually remain, and on the rare occasion that they are aired in public, they’re frequently a source of great embarrassment. While I’m embarrassed to have disclosed my own pet name of Stinky (there it is again), I feel equally red-faced about the .nudge-right class that I once used to deal with an awkward div.

Not all classes are ugly hacks. Many frameworks6 employ sensibly named classes, sometimes even in an “object-oriented” fashion. The question is, why have classes at all? We already have the names of elements (<p>, <small>, <address>, <ul>, etc.). Better still, like my legal name of Heydon Pickering, they actually have some currency: they can be interpreted by more than one or two people.

Parity And Disparity Link

The reason we “mark up” Web content is to create parity between the way it is perceived by human readers and the way it is read and archived by machines. This parity has many benefits, some of which are discussed in an excellent post by Dr. Mike7. Perhaps the greatest benefit is that when someone searches for some content, the engine that carries out the search request has a better chance of identifying and finding it. The machine and the human have “an understanding.” Parity is extremely important because, without it, the mechanisms of data storage and retrieval would get out of sync.

Aside from microformats8 (which, like tag names, have been endowed with agreed meanings), no class is able to affect the actual meaning of the marked-up content as read by an indexing bot or screen reader. Classes can only affect the visual appearance of the content. That’s right: all classes are “decorator classes.” You knew that already, but is it a moot point? I think not.

An Example Link

Please consider the following code and corresponding illustration. Think of the tags as pseudo-HTML.

// HTML:

<crustacean class="crab">Shane</crustacean>
<crustacean class="lobster">Martin</crustacean>
// CSS:

sea {

crustacean {
   border:2px solid;

.crab {

.lobster {

(Images: Patrick Tanguay10 and ajmexico11)

  • What the human sees
    An angry-looking crab and a yellow lobster next to each other in a watery blue box, bearing the unlikely names of Martin and Shane, respectively.
  • What the bot sees
    Two adjacent bits of text that both belong to sea and should be treated as crustacean-related.

Both the human and the bot are correct. However, they are both missing some information. The bot is not aware that the two crustaceans are, specifically, a crab and a lobster. The human, meanwhile, has not been told that the crab and the lobster both belong to the crustacea family. Despite a correct use of semantic HTML and a judicious application of CSS classes, there is a disparity between the way the machine and the human interpret the information.

We can’t expect the specification12 to contain a tag for every conceivable concept. It will be no surprise that <slippery>, <disappointing> and <airborne> are not so far being considered for HTML5. Neither could we expect parsers to be able to meaningfully interpret each and every individually authored class name. In this case, what else can we do to supply both the human and the bot with as much of the same information as possible? That is, what tool can accurately explicate the intended “lobsterness” of the second element without alienating either party?

The answer is something called content. So far, our “content” consists of a spurious label (much like your typical class attribute). I think we can do a lot better:

      <h2>The Lobster</h2>
   <p>Shane is a <a href="lobsters.html">lobster</a>, which is a type of <a href="crustacea.html">crustacean</a>. He is <em>big</em> and <em>yellow</em>.</p>
   <img src="images/shane.jpg" alt="Shane sitting on the sea bed">
      <small>Photo by ajmexico</small>

The mistake we made in the first snippet was to make two items that are similar appear different. As a general rule, if two elements are of the same type and appear in the same context, then they are alike—in which case, they should appear alike. The job of styling is to make items presentable, not to define them. Only the content should be definitive, and only the tags should be used to define the content’s taxonomy.

By depriving ourselves of the class attribute, we are forced to rely on content to add meaning to our design. In our example, the background images invoked via the classes have been replaced by image tags—i.e. actual content tags that can be interpreted by both bots and screen readers (via the alt attribute). This makes the machine’s experience of the resulting design much closer to our own.

The Document Outline Link

In the example above, we showed that, even when used sensibly and sparsely, classes can undermine the parity that should be maintained between the essence and appearance of content. However, nothing is to stop us from going completely mad: we could create as many classes as we wanted, place them in whichever elements we wanted as many times as we wanted, and name them whatever we wanted.

The Divya Debacle13
Homogeneous code like the sort referred to in this strip would not be practical if we couldn’t visually differentiate between the same elements via classes. (Strip by Kyle Weems14)

This kind of freedom allows us to break with conventions that make HTML documents apprehensible and, therefore, useful. Heeding Mark Boulton’s advice about icon design would be better:

Leave “creativity” to the bad designers.

Classes enable us to represent differences that don’t really exist, but nothing is wrong with reflecting differences that do exist. In HTML5, the document-outlining algorithm15 more than ever seeks to enforce structure in an HTML document. By harnessing this structure, we can use CSS to reflect legitimate differences between the parts of our page. This requires a basic understanding of semiotics and will be the subject of the next section.

(While not necessary to understand the following section, I highly recommend Derek Johnson’s introduction to the document outline16 as background reading.)

Semiotic Style Link

View image2518 of Ferdinand de Saussure.

It would be difficult to overestimate the impact that Ferdinand de Saussure19 had on the way we understand language—and, for that matter, anything we use to elicit meaning. To Saussure, how we choose to define things is not important. Rather, their relationship to one another is truly what makes them what they are. As Saussure’s translator Roy Harris20 put it, Saussure’s contribution to linguistics was to cease viewing words as “mere vocal labels or communicational adjuncts superimposed upon an already given order of things.” If you’ve been following closely so far, you’ll appreciate why I’m a big fan of Saussure: he sees no value in extraneous classification.

Saussure’s understanding of language as a system is based on two basic relationships; the paradigmatic and the syntagmatic. The illustration below transposes these concepts to an example of some semantic HTML.

Semiotic HTML21

Paradigm Link

A paradigm is a set of words—or, in our case, tags—with functional similarities but subtle or radical differences in meaning. In the sentence, “The crab sat next to the lobster,” the word “sat” belongs to a paradigm of alternative words that include “rested” and “crouched” as well as “stood.” It is a relationship of substitution.

There are certain rules. In English, a verb cannot be substituted with a noun, just as in HTML an inline element22 cannot always be substituted with a block-level23 one. In the diagram above, omitted members of paradigms are shown in light gray.

Syntagm Link

A syntagm is essentially a structure composed of paradigmatic choices. In English, sentences, paragraphs, chapters and books are all syntagms. In HTML, a block of code made from your choice of elements could be considered a syntagm.

Each syntagm is its own semantic system, and smaller syntagms can belong to larger ones. Just as a paragraph can belong to a chapter, so can an <hgroup> belong to an <article> and an <article> belong to a <section>.

What Am I Getting At? Link

This is all pretty straightforward stuff, so what’s the point? The point is this: The Saussurian model of language recognizes that terabytes of poems, novels, essays and plays can all be written (and have all been written) without having to invent new words or redefine old ones. If this model is good enough for natural languages such as English, then it is more than good enough for a simple metalanguage such as HTML. Of course, new words are coined over time, just as new elements are slowly introduced to the HTML specification, but this is done with careful deliberation and consensus. Classes have no such mandate.

If you really need to add a styling hook, choose something that pertains to a function, such as the role attribute. Roles are standardized and machine-readable. (View image2518.)

Meanwhile, the Saussurian model gives us more than enough scope for elegance and invention, as well as prohibits us from making bad choices. By styling the elements that make up our documents according only to what and where they are, then misleading or confusing the user becomes extremely difficult—without conscious effort. All you are doing is using CSS to expose the inherent structure of your page.

Paradigmatic styling is really just about choosing the right element for the job. There are many ways to traverse “syntagms,” so let’s look at a few examples. You’ll already be familiar with most or all of these; just imagine using this kind of styling exclusively:

  • aside h1
    A simple descendant selector that styles top-level headings that belong to asides.
  • body > div
    Styles divs that directly descend from <body> exclusively (helpful for unsemantic layout such as “wrapper” blocks).
  • p + p
    Targets all paragraphs that directly follow other paragraphs.
  • * + h2
    Styles second-level headings that do not appear at the head of their parent section.
  • section ~ article h2
    Targets all second-level headings in articles that are together preceded by a section.
  • li:nth-child(odd)
    Targets every other (i.e. odd) list item in either ol or ul elements.
  • ol li:first-child h3:before
    Styles the pseudo-content that precedes the third-level heading in the first item of an ordered list.

You will realize that any content styled using these methods will change in appearance upon being moved to another part of the page. Never fear: that is supposed to happen. Unfortunately, the employment of classes can all too easily undo this legitimate influence of context.

An Example Link

To provide an example to accompany this article, I took the step of removing all class attributes from my own blog26. The style sheet isn’t as neat as I’d like it to be, but that’s my fault, not Saussure’s. Note that my design is responsive and relies on a single id attribute to enable smartphone users to jump to the main navigation; however, it is not used as a styling hook.

The Importance Of Context Link

Previously, we explored how classes can be used to illustrate differences that don’t exist. By the same token, they can be used to gloss over differences that do exist.

From a semiotic perspective, perhaps the only real difference between two things that are otherwise alike is their context: the circumstances in which they are found. An English native and a French native are genetically similar but culturally different. The context of their nationality makes them, in many noteworthy ways, unalike.

Please consider the following code example:

// HTML:

   <h1 class="main-title">Article Title</h1>
      <h1 class="main-title">Aside Title</h1>
// CSS:

.main-title {

By coining the class .main-title, we have created a cypher to help us easily style all top-level headings similarly. However, the two headings in our example are not similar. Any parser that understands HTML5 will know that the h1 in the aside is, in fact, less important than the one that belongs directly to the article. How does it know this? Well, the specification mandates that asides are for tangentially related27 content, not important stuff like that found in the main body of the article. Also, the parser’s understanding of the document-outlining algorithm means that it will consider the aside’s heading as a mere subheading, belonging to the h1 that precedes it.

Context Definitions28
Google is aware that the word “context” has more than one meaning… depending on the context.View image29.)

If this is all being read and understood by the parser, then shouldn’t it also be disclosed to the user? In truth, the class in this example is redundant anyway: we could just style the h1 element with the property of font-size: 30px. The point is that if we differentiate the two elements according to context (say, by using the descendent selector aside h1), then the CSS will be bound to the HTML’s structure and the appearance of the element will fall in line with its computed meaning. In practice, by moving from an aside into the main article, an h1 would automatically look more important — which would reflect its greater importance. The aside h1.main-title selector would work, too, but the class is absolutely redundant.

Seems obvious, doesn’t it? However, popular frameworks such as OOCSS30 specifically sanction the use of classes in a way that denies the influence of context. To quote OOCSS’ GitHub page31, “An object should look the same no matter where you put it.” In fact, we’re told to avoid the descendent selector altogether, thus largely negating the “cascading” part of the technology.

The innovators of OOCSS are not the only ones who discourage the use of the descendent selector either. An article on CSS Wizardry32 reads, “As soon as an element begins to rely on its parent, and their parent, and their parent’s parent then you are doing it wrong. Your styles should never rely too heavily on where they live as this makes them incredibly unportable.”

In the next section, I’ll make the case that only content, not styles, should be portable.

Modularity And Mobility Link

An element that insists on looking the same wherever it appears is a bit like a Briton who travels from country to country refusing to speak the native language and burping the English national anthem. It’s aggressive and inappropriate.

I don’t see CSS as being object-oriented; I see it as being interface-oriented. The purpose of CSS is not to make individual items look the way we want them, but to make the interfaces that we build by styling HTML documents cogent and readable. For an interface to be optimally apprehensible, all of its components should work together politely and should respect the overall visual structure, no matter where the components come from.

Get your content ready to go anywhere because it’s going to go everywhere.

With the advent of elements such as article34, which are intended to carry content to be dispersed between documents, we should consider an approach to styling that does not permit externally sourced content to spoil the coherence of the context into which it is introduced. Once again, classes get in the way.


Unsemantic pieces of content that are styled with classes depend on the style sheets that give their particular content visual form. The class acts as a key, pairing the HTML with a specific CSS file. This has two undesirable outcomes:

  • The document that hosts the third party’s content has to load an additional resource (i.e. the third party’s style sheet);
  • The third party’s content defies the aesthetic conventions of the page and sticks out like an obnoxious advert.

By agreeing to basic semantic conventions and refusing to superimpose our own styling rules, we can instead manufacture content nodes that travel seamlessly from document to document. This approach to styling creates a scenario that allows our HTML to be interoperable36, like RSS. Website owners will maintain CSS files that style elements according only to the elements’ ownership by and proximity to other elements. Content manufacturers, meanwhile, will produce content that (by virtue of its semantic conventionality) is ready to take on the styling of any context it may enter, integrating itself with a minimum of effort.

In short, we should aim to truly separate style and content, allowing content to travel between interfaces but with the interfaces remaining unmoved. As within any properly formatted document, attribution — not aesthetics — should be what discloses the source of a piece of content.

Conclusion Link

“Roads? Where we’re going, we don’t need roads!” exclaims the inventor, Doc Brown, as his Delorean37-based time machine’s wheels fold under its chasis and the car takes off, headed for 2020. It’s a great line for its defiance: Roads, which have literally paved the way for automobile travel and made it viable, are no longer even needed. At all.

XHTML, which sought to enforce well-formed38 code, did little to enforce or cater to well-formed content. CSS classes, like the roads in Doc Brown’s line, were a costly and substandard necessity. We wouldn’t have gotten very far as UI designers without them. However, classes were only ever a polyfill39. Now that the new technology has arrived, they have become obsolete.

(al) (km)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Heydon is a UX designer and writer interested in web application accessibility and intelligent layout systems. He gesticulates a lot and is terrible at computer games. His acclaimed book on accessibility has been published with Smashing Magazine.

  1. 1

    Matt Andrews

    June 19, 2012 2:40 am

    This is a well-written and well-argued piece, but I have to ask: have you ever built a large site with many templates, components and layouts? This approach is arguably impossible to implement for that context, not to mention inappropriate. Yes, CSS3 has some fairly advanced selectors, but littering your stylesheet with HTML-dependent stuff like “section ~ article h2” is only going to cause you pain when you want to refactor, or simply target headings that don’t follow a section. Either you end up with 20-line-long lists of selectors, or you’re afraid to touch your HTML structure in case everything blows up.

    I really don’t follow your argument about elements looking the same in different places being aggressive/inappropriate. Have you ever designed a user interface? The goal is to produce consistent and reusable components that the user will intuitively recognise and use. If my “post comment” button looks different each time I put it somewhere new, what kind of experience does my user have? Do my comment counts decline as a result? This doesn’t just effect nerdy semantics, it’s real-world usability too.

    Finally, I don’t really buy your argument that we should avoid using classes because some mysterious third party content providers might use our entire HTML structure and it won’t look right. If we designed for that use case we’d all have sites like Jakob Nielsen’s (eg: plain and vanilla). It’s also possible to use semantic markup (blockquote tags for quotes, etc) *and* use classes, they’re not mutually exclusive. Also, if somebody pulls in my HTML which uses my custom classes, who says they have to load my CSS too? The classes won’t impact their site’s design unless there’s a naming overlap.

    In summary: classless HTML might work well on small, mostly trivial sites, but long term, it’s not scalable or modular (as Jonathan Snook’s SMACSS framework explains).

  2. 2

    In the words of Tennis legend John McEnroe, you can not be serious.

  3. 3

    Leon Kessler

    June 19, 2012 3:10 am

    You’ve linked to a tweet from 2009 at the beginning of the article. I stopped reading at that point.

  4. 4

    Luke Scammell

    June 19, 2012 3:13 am

    While I have always liked the idea of not using classes on small/simple sites, like yours in the example, it’s just not practical in larger/more complex CMS-driven sites.

    I think the whole issue of content looking the same everywhere being a problem when you appropriate content from another site is a bit of a non-issue, as you would have to copy their .class CSS in order for it to NOT be styled like your content – sure their may be *some* overlap on classes, but probably not as many as you’d think. Of course, should you *want* the content you’re embedding to look like the source site, using OOCSS classes makes it relatively easy!

    Having said that, I do agree that where possible, the tools we’ve been given by HTML should be used to appropriately structure content and not over relying on CSS to “structurally style” content. Of course, given the context of a “corporate CMS” sometimes you just have to do what you can to make things look like they should in a timely manner.

    Thought provoking for sure, and sensibly achievable for a small/simple site with one/few devs, but I think I’ll be sticking to classes for styling my more complex sites.

  5. 5

    Ricardo Magalhães

    June 19, 2012 3:16 am

    Matt Andrews said it all. The whole idea behind it is very appealing, but nowhere near of being possible in the real word. And by real world, I don’t mean our personal blog or single page portfolio. I mean the world where you have to work with a team, know what to expect in the front-end side, and be ready for design changes on the spot which require markup to be changed.

    For instance, we still need a lot of wrapper elements in divs, sections, whatever. Some overly specific CSS targeting could kill your entire styling just by adding this necessary extra element that the client insisted on having at the very last minute. And that’s just too much work when you’re on the spot. I like the reassurance of knowing that if I need to add an entire block of something else, my styling rules will not break. With your approach, hell would break lose.

    We need to build with a modular and scalable frameset, otherwise we’re just asking for trouble in the long run.
    I agree with you in the sense that we shouldn’t cultivate a ‘classitis’ workflow, and not everything needs to be a reusable element on its own. The trick lies in knowing where the middle ground is.

  6. 6

    Mark Simpson

    June 19, 2012 3:21 am

    Trolling published as link-bait.

    Try building something bigger than a brochure site without using classes and you’ll quickly learn the error of your ways.

  7. 7

    Stephen Melrose

    June 19, 2012 3:25 am

    My problem with your argument is, frankly, that you don’t make it very well. You have some good points, but most of them are completely unrelated to your actual argument and are just waffle in this tirelessly long article.

    I think I can sum up this article in a couple of sentences,

    “Don’t use classes to define content. The *context* of content is what defines content.”

    That about right? The problem with your argument is that the limitation of what is considered valid HTML does not allow you to do this, therefore, we have to use classes to *enhance*, not define, content.

    Also, I would genuinely love to see you code up a big, corporate, CMS managed website without classes. In fact, I extend to you that very challenge. And if you succeed, I will completely rescind my argument and declare you the victor.

  8. 8

    Stop Using Drupal???

    Due to Views module markup??

    Semantic View + Semantic CCK… and fears become small!

    Platform is not a problem… but the way you use it…


  9. 9

    Leon Kessler

    June 19, 2012 3:46 am

    Oh okay, yeah I really do respect people who have enough time to search twitter for out-of-date information. And then use it to misinform everyone else.

  10. 10

    Niels Matthijs

    June 19, 2012 3:46 am

    One of the problems with this article is that it sees classes as mere styling-hooks. While CSS has a big impact (especially today), classes (and ids) are there for all scripts. They divide your site in logical, portable components that could be used wherever on your page/site.

    If tomorrow the Analytics guy passes by and asks you to track all the clicks on “read more” links in news article teasers across your site, you need to be ready. Without the proper use of classes and ids you won’t get anywhere.

    Apart from that, I’d love to see a use case for a 10-template site using this idea. I don’t think you’ll get very far, unless you keep your design very slim (and thus highly dependent on your method of working).

  11. 11

    Luke holder

    June 19, 2012 3:47 am

    People slamming this article as being not attached to the real world only read the title.

    This article was extremely thought provoking, and has caused me to think much more about why and how I do things. It’s these types of articles that push our profession forward.

    Before slamming something, at least try to implement some of the ideas presented an come back in a few weeks with a proper rebuttal with some annecdotal experiences for us.

  12. 12

    Rasmus Kalms

    June 19, 2012 3:50 am

    You declare that one should stop using Drupal, and then proceed to link to a tweet from Boulton that are dated back to ’09? Nice.

    Views is easy to adjust to whatever truth you want.

    Also: It is very easy to style Drupal the wrong way, but it’s also powerful in the way it enables clean, well-targeted CSS. Yes, the standard markup is dreadful, but it’s your job to make it lean. It works out-of-the-box as it should, and can be molded to fit whatever reality you want it to.

  13. 13

    Thomas barber

    June 19, 2012 3:58 am


    I do not believe that you have afforded this topic so much thought and managed to arrive at the conclusion that classes are redundant.

    I would go as far as to say that had you worked on large project that demands a scalable modular css architecture you would have been unable to arrive at these conclusions.

    I normally attempt to implement ideas such as this before offering a response. However as I have been considering this topic throughout my career I feel I am well placed to offer an instant rebuttal on the back of experience.

    Specificity wars, lack of maintainability, just a no.

  14. 14

    Heydon Pickering

    June 19, 2012 4:02 am

    The Sizzle selector engine does not rely on id or class attributes.

  15. 15

    Mike McCabe

    June 19, 2012 4:06 am

    I suspect Heydon is playing devil’s advocate to a certain extent. I can’t imagine he would attempt this on anything larger or more complex than his personal blog (correct me if I’m wrong). However as a concept it is very intriguing.

    Although I wouldn’t go so far as to avoid classes altogether I can see the logic and benefit of keeping them to a minimum. How many times have you seen:

    <article class=”product”>…</article>
    <h1 class=”product-heading”>…</h1>
    <img class=”product-img” />
    <p class=”product-description”>…</p>

    I don’t see why you can’t get rid of all classes except .product and then use descendant selectors for the product module. This way you achieve the best of both worlds.

  16. 16

    Stephen Melrose

    June 19, 2012 4:06 am

    Most, if not all, selector engines don’t *rely* on id or class attributes, they merely support them, like any other selector syntax.

  17. 17

    Heydon Pickering

    June 19, 2012 4:06 am

    I just checked. Drupal is still rubbish.

  18. 18

    The ambition of this article is awesome! Having said that I can’t quite bring myself to agree…

    I think there were two points which I am 100% behind (actually only alluded to in the crustacean example)
    1. Don’t use classes to give your content meaning.
    2. Have meaningful content.

    Which, yeah, sounds good!

    I just don’t see what this means you *shouldn’t* use any classes though. Since all classes are “decorator classes” why can’t we use them for decoration? The idea seems to be that each piece of content should be visually distinct and that doesn’t sit well with me. To me that’s like an interior decorator saying your armchair and sofa shouldn’t look the same. Of course the shape is different, as is the context; but I want both in a luxuriant orange zebra print! Of course the armchair in my study should be a rustic brown leather, just like the bar stools in the kitchen-diner and the sofa in the den.

    Let’s assume all users (human or bot) can understand all these items of furniture. That is: what they are, how they function, etc. All I need to do now is ‘add the fabric’. This is the exact purpose of classes. If I only had one sofa, sure maybe I don’t need a .zebra-print class. Actually let me correct myself – I probably never *need* a class; but I should use one here. It will make my life easier with no detrimental effect.

    To push the example further: what if I have two armchairs in my den but I want these to be upholstered differently? The purpose is the same but just for kicks I want them to look different. So I know they are both in the and they are both ‘s. So that’s easy right? I’ll just do den > armchair + armchair { whatever }. Sweet, done! But what if I remove (delete) the first chair? I could use last-child, but there is that pot plant… So last-of-type? Now I can’t add more chairs. It’s starting to get confusing… I’m left with 3 choices:
    1. Use a class
    2. Try deal with the problems as they arise (i.e. fancy selectors)
    3. Live with matching armchairs

    The order of these is not random – the first option is clearly preferable. Option 2 will be what the client/designer pushes. Option 3 will lead to a very dull web indeed….

    Now let’s say I’m worried about syndication. Let’s say someone gets hold of my html classes and all. Getting a class of .zebra-print is not going to adversely affect them. They can quite happily strip this and ‘re-upholster’ it – as you might do when you get a second-hand sofa. If they don’t want to strip the classes, that’s their problem. My content is meaningful enough for them to do so and, therefore, they must be choosing not to.

    I really do applaud this effort; I think it’s great to push the boundaries and get people looking at the issues differently. Additionally your argument, although flawed, is very thorough and eloquent; so seriously, thanks for going out on a limb and writing this!

  19. 19

    I don’t rely on the phone to communicate but it’s a hell of a lot better than traveling to the other side of the country when I want to talk to my friend.

  20. 20

    My trash fueled flux capacitor is now at maximum charge thanks to this post. See you in the Future!


↑ Back to top