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

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:

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 classes4, I question the efficacy of the class attribute per se.

The Class As Imposter

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 label5
View image6.

CSS classes7 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 frameworks8 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

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. Mike9. 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 microformats10 (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

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 Tanguay12 and ajmexico13)

  • 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 specification14 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

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 Debacle15
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 Weems16)

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 algorithm17 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 outline18 as background reading.)

Semiotic Style

View image2820 of Ferdinand de Saussure.

It would be difficult to overestimate the impact that Ferdinand de Saussure21 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 Harris22 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 syntagmatic23. The illustration below transposes these concepts to an example of some semantic HTML.

Semiotic HTML24


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 element25 cannot always be substituted with a block-level26 one. In the diagram above, omitted members of paradigms are shown in light gray.


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?

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

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

To provide an example to accompany this article, I took the step of removing all class attributes from my own blog29. The style sheet30 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

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 related31 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 Definitions32
Google is aware that the word “context” has more than one meaning… depending on the context.View image33.)

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 OOCSS34 specifically sanction the use of classes in a way that denies the influence of context. To quote OOCSS’ GitHub page35, “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 Wizardry36 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

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 article38, 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 interoperable40, 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.


“Roads? Where we’re going, we don’t need roads!” exclaims the inventor, Doc Brown, as his Delorean41-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-formed42 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 polyfill43. Now that the new technology has arrived, they have become obsolete.

(al) (km)


  1. 1
  2. 2
  3. 3!/markboulton/statuses/3576335793/
  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
  40. 40
  41. 41
  42. 42
  43. 43

↑ Back to top Tweet itShare on Facebook

Heydon has a love/hate relationship with CSS and a lust/indifference relationship with javascript. He writes a lot and makes fonts.

  1. 1

    Hi Heydon,

    You should stop writing articles like this on Smashing Magazine and start considering to be respectful in your comment replies.

    Top tips: search “css frameworks” and “template engine” to learn something that is related to real world…

  2. 202

    I wouldn’t go as far as to say you’ve sold me — but this article has given me plenty of (dare I say) food for thought. I think the only way I am going to appreciate the idea behind losing classes is to give it a shot. So, for a little while I am going to try to stick with tags instead of classes, and see how I go. If I can do everything that I normally would have been able to do, I don’t see the harm in it. At this time, I am treating this concept as a novelty.

  3. 403

    Ok, I am back already. I use XHTML, and there’s not enough tags to go around. HTML5 has a lot of tags, but it’s not very well supported yet. Then there’s HTML4 (just forget about not using classes with that). The idea of losing classes is ok, but it’s not practical. At best, I think it’s ok to drop the use of classes for every tag that is supported by html4, html5 and xhtml — and that’s just the main stuff really. p’s, div’s and h1’s. That’s my two cents. My problems started as soon as I couldn’t find a substitute for a div wrapper! It went down hill from there. This article sounds good, but in real life.. yeah..

  4. 604

    This methodology can be used for websites built for the “borg”. No taste, no style, just blocks and headings. To drop classes and use tags, well that’s just a glorified XML document, really. If you ant to add left menu’s and right menu’s and floating containers and dropdowns and various containers (ie: there could be 15 different containers) which show up on the same part of the template depending on the page/corresponding content, etc.. then you need classes and you need LOTS of them. I don’t care if you call them Martin, Shane or Matha. There’s no way to build a functional website with a lot of design elements, without using classes. End of story, Period.

  5. 805

    this article is about what kind of roads the A.I. of browsers have to take and how the communications between machine and human should go , not about building web sites from the perspective of efficient & cooperative ways of doing works.

  6. 1006

    what? …. :D
    Can you inform us on your BBC progress?

  7. 1207

    I like this way. I think in future, all will follow html tags rather then classes.

  8. 1408

    منتدى أسود الفوركس

    October 14, 2012 10:39 am

    It’s perfect time to make some plans for the long run and it’s time to be happy. I’ve learn this post and if I could I want to suggest you few attention-grabbing things or advice. Maybe you can write next articles relating to this article. I desire to read more things about it!

  9. 1609

    You want to control your content and control your website design then I suggest MODx.

  10. 1810

    On the whole I agree with your point. Using classes is never optimal, however it is sometimes unavoidable especially for those of us who either work with designers who do not see design in the same way and clients who want their way. I believe there are times when they can be of use, semantic to a point and necessary.

    Personally I feel your biggest issue here is that you come off as an incredible asshole in your comments and as an arrogant prick in your article. The notion to stop using classes is a scary one to many designers/developers and you are not doing any favors to your cause by cramming it down their throats about how their way is wrong and they are less intelligent for not knowing your way.

    It is always better to ease people into things if you want to make some headway, we don’t need an article on how to get rid of classes altogether, but, how about instead of this write-up you pen a helpful article outlining some ways to avoid them in your day to day work?

  11. 2011

    I will go ahead and assume that because I find this article ridiculous. No one with a lot of large project experience can take you seriously for this very reason. Any by large project I do not mean clicking install for “drupal” and creating a mom & pop website, I mean comprehensive sites that a team of people work on full time.

    So are my assumptions right or are you going to show us an example of this experience.

  12. 2212

    This is off topic but my inner pedant won’t let me leave it alone. Plenty of people do want to build cities and cities are not generally a product of overpopulation.

    Cities developed because commerce, learning, innovation, cultural exchange, and many other functions important to civilization are made more efficient when lots of people congregate in close proximity to each other.

    All that said, I don’t know what, if anything, this means for your and Jason’s metaphor.

  13. 2413

    The best approach is limiting how many classes you create by maximizing the use of HTML5 markup such as header, article etc. Not using ANY classes is the most ridiculous idea, especially if you are creating a large site that requires many divs. Not to mention divs that require relative, absolute positioning.

  14. 2614

    Stumbled across this whilst picking through new ideas …

    Fascinating article and concept with a very robust discussion after – it certainly ruffled a few feathers.

    It’s a concept I’ve been skirting around the edges of for ages – I despise overly complicated CSS mark-up and find wading through reams and reams of classes – even well constructed OOCSS can be *very* time consuming.

    I’ve always practised using as few styles as possible, using the raw html mark-up to do as much grunt-work as possible. Generally, that amounts to using a lot of container classes and inheritance.

    It seems one of the major gripes with the approach of not using classes, is that unless *everyone* in the team is ‘on-board’, it’s going to be a very painful and long ride.

    But I do love the idea and I think it’s possible to accomplish regardless of how complicated the project is – it’s all about management of the project.

    If anything, it’s worth taking home the lesson that at the very least, the amount of classes could be cut down substantially – call it a hybrid approach – for complex designs.
    It may be as simple as a single semantic ID on the body that provides the only hook needed to vary layouts without requiring any other classes in the document.

  15. 2815

    whow !
    gave up reading comments after many, very interresting.

    I understand the approach and i often use all kinds of selector when starting styling my HTML.
    But that is to see and check rapidly that globaly the CSS technics i use are fine and can leave together, most of the time it remains so for single test pages or poor content.

    Very fast i add my first ids, when html tags are to redundants to just have a meaning by themselves: -> context of course, and that makes it easier to share or let someone else take over sometimes. It helps to structure the style sheet.

    Then of course classes are showing up, cause redundant structure are reusable objects and selectors can still skip them -> structure context again.

    Using CSS selector is fun and that’s what they are made for.

    I agree with the idea,
    I disagree cause
    – it’s just not the way it can work,
    – users are not one kind,
    – teams need easy ‘n understable language rules,
    and HTML attributes are to be used.

    ‘back to the future, folks !’ :)

  16. 3016

    forgot to say that ids, class, … are hooks too to CSS and javascript for example (as someone else said it before).

  17. 3217

    Mark, have YOU ever worked on a large and complex project as part of a team WITHOUT using classes?


    Until then, you and the other haters here should put a sock in it and reread Heydon’s article until you actually understand the idea in more detail.

    Here’s a challenge for you, give his ideas a fair shot in 10 small to medium-sized projects where YOU control things. Then come back here and give a PROPER argument.


    … *waits for the penny to drop* …

  18. 3418

    I suspect a lot of the hostility in the comments is probably down to the unwillingness to change. You guys are used to your way of working and perhaps some of you have a certain loyalty to other methodologies.

    But why shoot Heydon down? His article is limited in scope, and you’re making that decision there and then that his idea won’t scale or will otherwise be too difficult to implement? That’s just ridiculous. His article is just an introduction! You need to test his idea in various real-life projects before you shoot Heydon down. Implementing, testing and making required changes along the way is the only way we can create something that works well for everyone who chooses to use it.

    He isn’t saying that his way is the only way. But HTML and CSS are not unchanging and our ideologies and methodologies need to evolve with these languages.

    In principle, I understand what Heydon was talking about, and I’m looking forward to implementing and testing it in my projects. Maybe he isn’t 100% on target but he’s got my respect here because unlike the rest of you, he’s trying to solve a problem many of us have experienced. He didn’t deserve the bashing he got.

  19. 3619

    I completely agree with you, and love the metaphor you used. Thanks for your contribution to this comment thread.

  20. 3820

    I’m just a bluecollar website designer, much of the article and commentaries are over my head. However, what is not lost on me is the importance of building a clear, solid foundation, and keeping a structured, uncluttered form. What Heydon is introducing here is just that.

  21. 4021

    Janis Kamburoglu

    July 23, 2013 5:08 am

    Hi, reading this, you must yourself very well know that there are things you can never achieve without using those “classes”. I find the point in minimizing the classes as much as one can. No offence – U can be hundred times better web developer than me – but the blog, how this can be an example of your post is unclear to me – it looks like empty, yet it is so hard to see through it. ? Maybe use classes?

  22. 4222

    This is something I have tried to do as much as I could for a long time, but there really are some cases where classes are necessary, not just common practice, but necessary.

    I haven’t exhaustively read the comments (there are just so many), but the amount I did read, I saw a lot of mention of “real world”, but only in terms of “real world” common practices, not “real world” limitations of CSS. For example, if I want to add an arrow to menu items that have child ‘s I have to add a class .has-children to style them. CSS does not have a “has-children” selector (though it should), so what would I do without classes?

    So, even though I agree with the principle and believe it should be practiced as much as possible, CSS imposes certain limitations, some of which can be fixed with classes.

  23. 4423

    I would say I agree with this 50%. There was a time when I very much suffered from “class-itis” (as a result of div-itis) because I thought they were the best thing since sliced bread but soon after experienced how hairy that became to maintain and update the HTML.

    So then I went in the exact opposite direction and tried no classes at all, as Heydon proposes here, but the hairiness just got transferred over to difficulty in maintaining the CSS.

    The new sectioning tags in HTML5 are certainly a leap forward in helping to move us away from div-itis, but classes are still necessary in cases where more specificity is needed.

    I’m now at a point where I try to do as much as I can using only plain tags, and add classes generally when I’ve run out of options for tags. I feel it’s a balanced approach vs going to the extreme of either over-classing or ditching classes altogether.

  24. 4624

    Heydon Pickering, your posts in the comments here are all shown with a different background and border color (shades of pink) to indicate that you are the writer of the original article.

    Please explain how you would accomplish this *without* the use of classes. Or would you not do it at all?

    I realize my comment is a bit late to the party and don’t expect an answer, but it would be nice.

  25. 4825

    Roberto Góngora

    April 7, 2014 12:26 pm

    I completly agree with this. Your article gave me confidence on such a rabbit hole, and I’m convinced that content do can determine herarchy and structure by itself, and there for set the base for looks, navigation and responsive distribution, not an easy thing to concieve, but I guess it’s just about getting used to think that way.

    Current DOM manipulation, AJAX and HTML5 tags allow to start making versatile documents, that can fit to any template or print stylesheet, just by relaying on a universal and limited tagging convention, instead of on an infinite anarchic classes nesting and naming. I’ll keep on the subject, but I’m with you if you still think we “don’t need classes”, at least not in the main structure, I dare saying classes should only be added dinamically, as selectors or to fit too complicated stylesheets.

    I wonder what your opinion might be almost two years past into the future.

  26. 5026

    What this article is still missing is links to actual examples of small and large websites built using this methodology.

  27. 5227

    This article is total nonsense (by someone who has a problem understanding classes?) HTML tags hardly do the job. means nothing but some default style that someone decided were the most common way one wished to present content. Actually, having H tags is a concession to the fact that classes are needed, and having 6 h tags even more concession. Since the h tags are just another way of styling ordinary text with “classes” of font-sizes (again, predefined and fixed by someone who thought they knew in advance what you needed to use and the limits of those needs. Littering markup with a whole lot of exception ‘spans’ is just another way of saying, we need classes that can be used or not used to override someone else’s idea of how we want to express our designs. If you have 5 (or a hundred) different ways you wish to specify the style of paragraphs in your code then, without classes, you’ve got a hunt and find nightmare for every/any change you wish to make, and a maintainability problem that goes on forever. I’m working on a site that needs to display or hide hundreds of different list items depending on other conditions, or weekly changes in external events. Simple classes of “on” or “off” on those li makes the job a cinch. Can you imagine having to go in to every page and hunt down every li to add or remove it just for temporary changes? Nonsense. Double nonsense. If you want to have markup supply the variety of needs (and poetry, my discipline, does not use a some limited, standard, “lexicon” — it’s needs are as rich and varied as any genre of writing, often more so since the peripheral styling is not incidental, it is fully semantic (or, as Mcluhan said, “The medium is the message”. ) To handle all the important nuance of styled text with markup tags invites a jungle of complexity no one needs. Stone-age stuff – not to mention the author’s complete misunderstanding of structuralist and post-structuralist critique and really shouldn’t be throwing around names like Saussure (or Derrida or Barthes…etc.) unless they’ve really read and understood them. Obviously this author does not. “little aesthetic differentiation”? Are you kidding. Every word you use is aesthetically differentiated from every other word — even if you use the same word over and over. Go listen to Lenny Bruce’s “fuck you” routine if you don’t think so.

    The real problem is that code jocks borrowed linguistic terms from disciplines they knew nothing about and without understanding them at all. And what we got for the trouble is their ignorance designed into software languages we use. So now we get into these insane arguments about what is “semantic” and what is not. It’s all bullshit to anyone who even had a 101 class in linguistics or poetics or lit. crit. The big mistake in the early design of css was there were no poets, linguists or anthropologists on board those efforts. If there had been, styling properties would have been far richer and more robust, class employment for more natural and reflexive to actual use, and stupid arguments like this article makes wouldn’t be worth the bandwidth its printed on.

  28. 5428

    I tried, and it failed more than once. Markup changes, especially on huge CMS driven websites, and if you have to rewrite the CSS every time, you’re in for a serious headache.

  29. 5629

    I can only speak for myself, but I don’t think I’m alone:

    I use classes for my OOCSS approach *because* I’ve personally experienced the nightmare of maintaining a site that uses direct association.

    They don’t really need to “try out the ideas presented” in order to form a rebuttal…based on their comments RIGHT NOW, it doesn’t take a psychic to sense that they’re speaking from experience.

    I relate to what Matt Andrews, Paul Smith, Stephen Melrose, Ricardo Magalhães and Luke Scammell have all said.

    I know it’s not really nice to “slam an article”, or to bring the author’s ability into question…but I’m sorry, I have to agree. I honestly don’t know how anyone who has worked on large-scale, commercial projects can have this opinion.

  30. 5830

    Heydon Pickering

    June 19, 2012 8:01 am

    Thanks, Jeff.

    Semantic Views is a great step in the right direction but it bothers me that semantics should be relegated to add-on and not an integral part of a CMS that pertains to offer powerful structured content support.

  31. 6031

    Heydon Pickering

    June 21, 2012 3:24 am

    If you are using classes, you have to rewrite the CSS and the markup.


↑ Back to top