Classes? Where We’re Going, We Don’t Need Classes (CSS)(coding.smashingmagazine.com)
coding.smashingmagazine.com
Classes? Where We’re Going, We Don’t Need Classes (CSS)
http://coding.smashingmagazine.com/2012/06/19/classes-where-were-going-we-dont-need-classes/
13 comments
When the HTML structure changes, the CSS changes in accordance. That is what is supposed to happen. You do not understand the technology.
I did this once, I quickly abandoned it as I felt it was madness. It was for my personal site (just like his) that's a testing ground more than anything. After writing far more styles than I felt was necessary for such a simple page it was easy to see future problems once it was done. Biggest example as many pointed out is that if I moved HTML elements around in the markup then I would have to rewrite huge chunks of the style sheet even though I wasn't changing the actual design of the elements.
My soon former job involves two websites that have a large chunk of its markup with no classes or ids provided by the CMS. It is a nightmare to support or to add a new feature. I have a selector that is eight elements deep, all to target one cell in a table embedded in other tables. Well, to be fair, I'm guessing the author wasn't considering that kind of site. I can scare you at the campfire with stories of the tables I deal with that have no classes or ids. We've rewritten a good chunk of the CMS to clean up the markup and add classes to make my life as a front-end guy much easier.
This reminded me of the tables, I need some quiet time now.
My soon former job involves two websites that have a large chunk of its markup with no classes or ids provided by the CMS. It is a nightmare to support or to add a new feature. I have a selector that is eight elements deep, all to target one cell in a table embedded in other tables. Well, to be fair, I'm guessing the author wasn't considering that kind of site. I can scare you at the campfire with stories of the tables I deal with that have no classes or ids. We've rewritten a good chunk of the CMS to clean up the markup and add classes to make my life as a front-end guy much easier.
This reminded me of the tables, I need some quiet time now.
While I don't agree at all with the idea of abandoning classes for clever ancestry-driven selectors, the author is absolutely right about the advantages of the HTML5 content model and the portability of semantic markup.
I wish more people would advocate for a middle ground between this content driven approach and an OOCSS approach. They work so nicely together.
Who ever said that you should stop caring about using semantically correct tags when using portable classes for styling?
I wish more people would advocate for a middle ground between this content driven approach and an OOCSS approach. They work so nicely together.
Who ever said that you should stop caring about using semantically correct tags when using portable classes for styling?
Ancestry driven selectors are the essence of CSS. Classes are a cludge.
In my experience, styles that are applied directly to elements cause more problems than they solve. Outside of a minimal reset, and a few general elements like h1, h2, etc., I try to avoid applying styles to base elements. I have yet to see any real-world problem with classes. And I really don't understand why "classitis" is a concern for anybody.
What is a style "applied directly" to an element if not a class? It's written on the element itself.
'Classitis' is certainly not a concern for parsers because they do not know it is going on. Then again, that's my point.
'Classitis' is certainly not a concern for parsers because they do not know it is going on. Then again, that's my point.
It appears that where he is going is only as far as a small blog stylesheet. I appreciate his argument about context being important in styling, but it creates a very fragile stylesheet that could crumble with a simple change of the context. If you're updating often, this would just be too difficult to maintain.
This article has bunch of stuff but the author doesn't clearly justify the premise. Much a read about nothing.
"In English, a verb cannot be substituted with a noun"
I beg to differ. You should Google that.
I beg to differ. You should Google that.
Technically that's turning Google into a noun rather than replacing a verb with a noun. You still conjugate it as "I Googled," "I will Google," or "I like to Google things." English's lack of inflection in the "base" forms of words just tends to obfuscate parts of speech somewhat.
If only all projects could be as easy as the examples presented.
Read my comments for the original article carefully. Projects are made easier to maintain by foregoing classes.
Element names belong to a shared lexicon which all developers and sufficiently up-to-date parsers understand. Classes are invented per project. They are a superimposition. They muddy the water.
Element names belong to a shared lexicon which all developers and sufficiently up-to-date parsers understand. Classes are invented per project. They are a superimposition. They muddy the water.
I found this article extremely thought provoking.
The rhetoric is the design community has been content first design, and such a bold choice in CSS authoring would really support this idea.
I would love to try this out in a real project.
The rhetoric is the design community has been content first design, and such a bold choice in CSS authoring would really support this idea.
I would love to try this out in a real project.
The top comment by M. Andrews says it best:
"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)."
"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)."
Exactly. I'll just add that css selectors are inefficient in terms of performance (see https://developer.mozilla.org/en/Writing_Efficient_CSS ).
And really it would be better to avoid references to linguistics when talking about a markup language, especially references from early structuralism which, basically, has failed.
And really it would be better to avoid references to linguistics when talking about a markup language, especially references from early structuralism which, basically, has failed.
While that Mozilla page is completely accurate, it's very rare that your CSS is your site's performance bottleneck. The vast majority of the time you're better off making your structural CSS choices based on developer maintainability, not prematurely optimizing rendering performance.
To wit: browsing the article's source code and searching for "class=" yields 1158 results
It's not my website.
This is unfair - the author of the article has no control over SmashingMagazine's markup/CSS.
> In summary: classless HTML might work well on small, mostly trivial sites, but long term, it’s not scalable or modular
> > To wit: browsing the article's source code and searching for "class=" yields 1158 results
I wasn't suggesting the author was responsible for Smashing Magazine's source; I was demonstrating that sufficiently complex websites have good cause for using classes. Styling all of that markup without those classes would be an absolute nightmare.
> > To wit: browsing the article's source code and searching for "class=" yields 1158 results
I wasn't suggesting the author was responsible for Smashing Magazine's source; I was demonstrating that sufficiently complex websites have good cause for using classes. Styling all of that markup without those classes would be an absolute nightmare.
[deleted]
[deleted]
[deleted]
Exactly - this is yet another contrarian article, and I hope I will not assign it too much meaning because it's anecdotal (anecdotal in the sense that it works for the author with his small blog).
HTML itself is scalable and my method is sympathetic to HTML. Scalability is a non-issue.
Agree. I used to study Artificial Intelligence 10 years ago and they were saying exactly the same things about semantics back then. I don't believe it will ever happen. API's, specifically designed to be read by a computer are taking that place already.
"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."
Still a case can be made to reduce use of classes. e.g. for input[type=text], etc. Typically for any one site the style for most elements should remain consistent - you wouldn't have half a dozen different styles of input[type=text].
I haven't worked on an especially large website before and I'm unsure of the following points:
1. Let's say you're integrating two site-lets into a bigger site. Would namespace be a problem for classes specified in the two site-lets? What about namespace clashes between different "plugins" (e.g. jquery UI or something less polished).
2. Would the use of classes lead to "specificity war"? e.g. lets say we have the following CSS:
If we're using relative position selectors instead there wouldn't this problem be solved?
You mentioned being afraid of changing the HTML if your CSS is html dependent. Well if your website warrants a refactor of HTML wouldn't it warrant a refactor of CSS as well? After all, CSS is for describing how a piece of HTML should be presented. If you want to describe how an alternate set of HTML be presented, you use an alternate set of CSS rules, hopefully instead of injecting style information into content HTML that should ideally be only presenting information. There's a reason we stopped using <b></b> and <font></font> within our HTML, right?
Still a case can be made to reduce use of classes. e.g. for input[type=text], etc. Typically for any one site the style for most elements should remain consistent - you wouldn't have half a dozen different styles of input[type=text].
I haven't worked on an especially large website before and I'm unsure of the following points:
1. Let's say you're integrating two site-lets into a bigger site. Would namespace be a problem for classes specified in the two site-lets? What about namespace clashes between different "plugins" (e.g. jquery UI or something less polished).
2. Would the use of classes lead to "specificity war"? e.g. lets say we have the following CSS:
h1:first-child { padding: 10px; }
h1.large-heading { font-size:x-large; padding: 25px; }
<div><h1 class="large-heading">some text</h1> <p> some content </div>
h1:first-child { padding: 10px !important; }
h1.large-heading { font-size:x-large; padding: 25px; }
If we're using relative position selectors instead there wouldn't this problem be solved?
body > h1:first-child { padding: 10px; }
body > div > div > h1:first-child { font-size:x-large; padding: 25px; }
body p + h1:first-child { font-size:large; padding: 25px; }
You mentioned being afraid of changing the HTML if your CSS is html dependent. Well if your website warrants a refactor of HTML wouldn't it warrant a refactor of CSS as well? After all, CSS is for describing how a piece of HTML should be presented. If you want to describe how an alternate set of HTML be presented, you use an alternate set of CSS rules, hopefully instead of injecting style information into content HTML that should ideally be only presenting information. There's a reason we stopped using <b></b> and <font></font> within our HTML, right?
> Typically for any one site the style for most elements should remain consistent - you wouldn't have half a dozen different styles of input[type=text].
You could easily have more than half a dozen. You might have 3 different color schemes (light, medium, dark inverted), 5 different widths (what kind of form field is it?), 3 different font size contexts with customized padding, one with autocomplete and one without, one that's flat and one that's 3D, one that displays default text and one that doesn't... multiplying those yields 360 different variations, generated from 17 different classes.
Not all those variations will actually be used, but this is certainly a reasonable visual vocabulary for a medium-size site.
You could easily have more than half a dozen. You might have 3 different color schemes (light, medium, dark inverted), 5 different widths (what kind of form field is it?), 3 different font size contexts with customized padding, one with autocomplete and one without, one that's flat and one that's 3D, one that displays default text and one that doesn't... multiplying those yields 360 different variations, generated from 17 different classes.
Not all those variations will actually be used, but this is certainly a reasonable visual vocabulary for a medium-size site.
Aside from the flaws in this, summed up very well by the top comment, I was quite taken aback by his swipe at Drupal. He links it to a tweet from 2009 that's taken out of context and references one particular Drupal module. It's a very flexible CMS/framework - if you're building Views it's up to you to customise the output to your liking. He's demonstrating a rather poor and naive understanding of it.
I've been a Drupal developer for a while now. I've been recently playing with Rails because that's what I wanted to be doing in the first place, but just didn't know enough about enough to be able to really get it. Thanks in no small part to working with Drupal I now know enough about enough to be able to get some stuff done in Rails. And the more I work with Rails, the less I'm interested in working with Drupal in the long-term.
So much of working with Drupal is just overriding what Drupal wants to spit out instead - here's this Views markup, or this user registration process, or this database schema, now customize it to your liking. Rails takes the exact opposite approach - here's nothing, now make what you want. As my abilities grow, I'm coming to greatly appreciate the second approach.
Perhaps it's the author's experience with other modern development tools rather than a misunderstanding of Drupal that's informing his bias.
So much of working with Drupal is just overriding what Drupal wants to spit out instead - here's this Views markup, or this user registration process, or this database schema, now customize it to your liking. Rails takes the exact opposite approach - here's nothing, now make what you want. As my abilities grow, I'm coming to greatly appreciate the second approach.
Perhaps it's the author's experience with other modern development tools rather than a misunderstanding of Drupal that's informing his bias.
While I agree that his jab at Drupal is off base, because I don't agree with this article in general. Drupal does make extensive use of classes in its templating system, so I can see why the author would have a problem with it.
I see the class functionality in the templating system as a benefit, and makes styling much easier, but for someone who dislikes classes, I can see why the author wouldn't like Drupal.
I see the class functionality in the templating system as a benefit, and makes styling much easier, but for someone who dislikes classes, I can see why the author wouldn't like Drupal.
I think this issue generalizes to other content management systems. Drupal aims to allow users to create sites without needing to understand the underlying HTML, and most general-purpose Drupal modules produce class-heavy HTML because that is, once you understand the class naming conventions, relatively easy to style without needing to change the HTML structure.
This represents a trade-off - 'uglier' HTML and extraneous CSS classes in return for a drastic reduction in development effort and the knowledge required to bootstrap a typical project. This trade-off makes sense if an in-depth knowledge of HTML is not your strong point (and even most web devs are not fully-fledged "front end developers" conversant with the finer points of the W3C's latest magnum opus), and if you would benefit from having a lot of boilerplate stuff (user registration, access control, content management, RSS, caching, RDF, email notifications, widgets/blocks, templating engine, etc.) for free. Sure, if you're willing to do all of that stuff yourself, you can ensure that no CSS class is wasted (or, indeed, no CSS class is used at all). But most people can't make that trade-off, and even those who can would struggle to justify it beyond the most trivial or superficial projects.
The best solution is probably to take a framework and modify its output to look the way you want it to. That's why the swipe at Drupal is odd, as pretty much everything Drupal does can be modified via hooks (kinda like AOP) and templates.
This represents a trade-off - 'uglier' HTML and extraneous CSS classes in return for a drastic reduction in development effort and the knowledge required to bootstrap a typical project. This trade-off makes sense if an in-depth knowledge of HTML is not your strong point (and even most web devs are not fully-fledged "front end developers" conversant with the finer points of the W3C's latest magnum opus), and if you would benefit from having a lot of boilerplate stuff (user registration, access control, content management, RSS, caching, RDF, email notifications, widgets/blocks, templating engine, etc.) for free. Sure, if you're willing to do all of that stuff yourself, you can ensure that no CSS class is wasted (or, indeed, no CSS class is used at all). But most people can't make that trade-off, and even those who can would struggle to justify it beyond the most trivial or superficial projects.
The best solution is probably to take a framework and modify its output to look the way you want it to. That's why the swipe at Drupal is odd, as pretty much everything Drupal does can be modified via hooks (kinda like AOP) and templates.
I use Drupal (when required) in exactly in the way you describe, building Views and customizing the output. It's workable, but compared to the alternatives it's a pain in the butt.
If you haven't checked out other content management systems, you're missing out. Imagine if the Views workflow were made first class and efficient, instead of being tacked on.
If you haven't checked out other content management systems, you're missing out. Imagine if the Views workflow were made first class and efficient, instead of being tacked on.
I think just using a lot less classes, in combination with these selectors, would get most of the benefits without seeming so dogmatic and crazy. I guess most people "grew up" with half-finished CSS support (or if they're software like Drupal rather than people, they've not yet been refactored to reflect current browser capabilities) and so don't feel comfortable with the further reaches of CSS, but I find it quite liberating to use nth-child() instead of putting .odd or .even classes on things.
Not to mention that classes are very handy for attaching javascript event handlers.
This is because, in my real-world experience, HTML structure can change very easily. The h1 turns into an h3 for SEO reasons, a wrapper div gets added for a visual effect, an extra span gets thrown inside an existing one. And suddenly, all the CSS is broken because it all depended on the exact structure of the HTML. Maintenance becomes a nightmare.
But if you do everything with named classes, then nothing breaks at all. Writing CSS without classes makes as much sense to me as writing JavaScript code without function names.