Semantic Snakeoil(brack3t.com)
brack3t.com
Semantic Snakeoil
http://brack3t.com/blog/2011/semantic_snakeoil/
1 comments
As the author, I think we're pretty much on the same page. My example of ``span6`` is from the Twitter Bootstrap (which is also available as Less).
I don't think tools like Less and Sass can save us from this decision, though. You can write hundreds of rules to handle different configurations of HTML elements and remain completely semantic, but eventually you'll have the same configuration in two places where you want them to appear different. Then you have the decision of giving one of them an ID or giving them classes and those have to be semantic (and custom to your site, requiring learning from future devs) or generic and breaking the "semantic all the things!!!" rule.
People are trying to figure this out. Semantic.gs is a great example of that. I just don't see, in our current browser, markup, and styles situation, a way to avoid generic classes that's still new-developer-friendly.
I don't think tools like Less and Sass can save us from this decision, though. You can write hundreds of rules to handle different configurations of HTML elements and remain completely semantic, but eventually you'll have the same configuration in two places where you want them to appear different. Then you have the decision of giving one of them an ID or giving them classes and those have to be semantic (and custom to your site, requiring learning from future devs) or generic and breaking the "semantic all the things!!!" rule.
People are trying to figure this out. Semantic.gs is a great example of that. I just don't see, in our current browser, markup, and styles situation, a way to avoid generic classes that's still new-developer-friendly.
You know, as nerdy as it is, it's this sort of Aristotelian dichotomy between content and presentation that I really nerd out on. I'm reminded of an old SimpleBits staple where Dan Cederholm challenged us to find the most correct way to mark up breadcrumbs. But I digress...
I'm always glad to hear about more creative solutions to solving this dilemma. In my experience, since switching to Sass, I can't really think of a case where I had to sacrifice semantics for style, but perhaps that's an effect of being a designer who's wary of such things (letting the man who shovels sh*t decide how many elephants there should be in a parade, et wot).
Anyway, I don't think I share any normative urgency, (especially with something like W3C specifications). At the end of the day, I'm overjoyed that Sass saves me from 99% of semantics issues. For that other 1%, there's always the style attribute, no? ;)
I'm always glad to hear about more creative solutions to solving this dilemma. In my experience, since switching to Sass, I can't really think of a case where I had to sacrifice semantics for style, but perhaps that's an effect of being a designer who's wary of such things (letting the man who shovels sh*t decide how many elephants there should be in a parade, et wot).
Anyway, I don't think I share any normative urgency, (especially with something like W3C specifications). At the end of the day, I'm overjoyed that Sass saves me from 99% of semantics issues. For that other 1%, there's always the style attribute, no? ;)
I disagree.
As I understand it, in this argument, "usefulness" is defined as "is styled correctly with CSS". To this end, the author cites using `"class"="span6"` on elements, which are presentational, but not semantic.
This argument may have held more clout a few years ago, but tools like Sass have pretty much solved this problem of separation of content and presentation. Using a framework like Compass allows `"span6"`, for instance, to be expressed as a function on a semantic element, leaving your markup intact.
CSS frameworks, like Twitter Bootstrap, still stuffer from this conflation, but that's just a limitation of the tools. I make no claims to a prescriptive argument on the matter--go ahead and do whatever works--but I would be interested what the author would think about Sass, or Less.