4 ms·

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 templa

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

manmal 14y ago
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).
- heydonworks 14y ago
  HTML itself is scalable and my method is sympathetic to HTML. Scalability is a non-issue.
icoder 14y ago
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.
meric 14y ago
"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: h1:first-child { padding: 10px; } h1.large-heading { font-size:x-large; padding: 25px; } And then later a web developer comes along and slaps in a h1 like this <div><h1 class="large-heading">some text</h1> <p> some content </div> He finds it breaks the h1:first-child rule and so goes and adds: h1:first-child { padding: 10px !important; } h1.large-heading { font-size:x-large; padding: 25px; } And we can see where this is heading... when another developer sees the h1:first-child rule overruled his p + h1:first-child rule and slaps an !important next to it. 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; } I know generally you don't use headings like this but I'm trying to craft a simple example. I am not sure it still carries my point properly, so I'm crossing my fingers. 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?
- crazygringo 14y ago
  > 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.
tangue 14y ago
Exactly. I'll just add that css selectors are inefficient in terms of performance (see https://developer.mozilla.org/en/Writing_Efficient_CSS 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.
- lazerwalker 14y ago
  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.
stinky613 14y ago
To wit: browsing the article's source code and searching for "class=" yields 1158 results
- lowboy 14y ago
  This is unfair - the author of the article has no control over SmashingMagazine's markup/CSS.
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - stinky613 14y ago
    > 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.
- deleted 14y ago
  [deleted]
- heydonworks 14y ago
  It's not my website.

manmal 14y ago

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

heydonworks 14y ago
HTML itself is scalable and my method is sympathetic to HTML. Scalability is a non-issue.

icoder 14y ago

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.

meric 14y ago

"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: h1:first-child { padding: 10px; } h1.large-heading { font-size:x-large; padding: 25px; } And then later a web developer comes along and slaps in a h1 like this <div><h1 class="large-heading">some text</h1> <p> some content </div> He finds it breaks the h1:first-child rule and so goes and adds: h1:first-child { padding: 10px !important; } h1.large-heading { font-size:x-large; padding: 25px; } And we can see where this is heading... when another developer sees the h1:first-child rule overruled his p + h1:first-child rule and slaps an !important next to it. 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; } I know generally you don't use headings like this but I'm trying to craft a simple example. I am not sure it still carries my point properly, so I'm crossing my fingers. 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?

crazygringo 14y ago
> 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.

tangue 14y ago

Exactly. I'll just add that css selectors are inefficient in terms of performance (see https://developer.mozilla.org/en/Writing_Efficient_CSS 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.

lazerwalker 14y ago
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.

stinky613 14y ago

To wit: browsing the article's source code and searching for "class=" yields 1158 results

lowboy 14y ago
This is unfair - the author of the article has no control over SmashingMagazine's markup/CSS.
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- stinky613 14y ago
  > 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.
deleted 14y ago
[deleted]
heydonworks 14y ago
It's not my website.