I’m reading through the 63 comments on Matt’s code is food post and I inevitably got to one that mentioned that using CSS to separate content and presentation is a good thing.
I’ve made this argument myself a number of times, but in many ways this is a farce.
If you use CSS to apply the look and feel on your site, you have the benefit of being able to apply it to nice semantic XHTML. That part is great. That is the part we hear and fall in love with.
The ugly truth is this: almost all CSS/XHTML sites have their own version of 
tag soup 
There are limitations to what you accomplish with CSS alone; in many cases your XHTML has to submit to minor alterations for styling to be applied the way the designer intended. A true separation of content and presentation would mean you could make your changes purely in the CSS without making changes to the XHTML. Many times, that is not the case.
I remember chatting with Matt about a way to use DHTML to insert a DIV element into certain code that he wanted to use for styling. This approach is much closer to a separation of content and presentation than hard-coding the tag into the source, but it illustrates the symbiotic nature of the XHTML and CSS.
Using CSS and XHTML is a very smart way to build a site and there are a ton of benefits. When I recently built a new site from scratch, I built it as XHTML 1.1 compliant using CSS for formatting and I have no regrets. I plan to build all my new sites in this manner and eventually convert alexking.org as well. However, to say that I successfully separated the content and presentation using XHTML and CSS (respectively) is misleading.
Misleading indeed… But as you mention, better use tag soup than invalid MacDonalds food!
I actually wanted to pingback you, but it seems that it only works correctly when I ping myself :-). Here is the post:
http://annevankester[...]-myth-of-css
The Myth of CSS?
Matthew Mullenweg’s Code is food generated a lot of comments which appear to be resonating is discussions elsewhere. For instance Alex King responds with The Myth of CSSThe ugly truth is this: almost all CSS/XHTML sites have their own version…
I’m not quite sure how your sourcecode looks like, but as long as your valid to XHMTL 1.1. and you do not practice massive tagabuse, I would say, that you sepperated content from presentation. Each time you use a div or a span to get a specialized presentation for a part of your site, there is by definition a semantic difference, otherwise there would be no reason to mark it up. Most of the time I guess, you use it, to markup some things, that are not covered by html, like menus, navigation or orintation. And sometimes you want to markup things that have only few semantic-value, like Initial-Letters of a paragraph, but I imagine no markup that is purely presentational.
ok. ok “i” and “b” hav only presentational purposes, but actually, what’s the difference between writting “em” and “stong”? None, it both means that the textareas are to be somekind of highlighted. Even the use of blind tables (or replaceing them by equivalent divs) is not completely presentational, as they define specific areas, which have different typographic/usability funtions.
The only important thing, is that you don’t abuse tags.[And actually divs and span can’t be abused, as their only purpose is to have no defined purpose]
And anyway, from a linear, tree-like markup language like HTML, you can never define a so 2D-Thing like a webpage, without carring some of the presentation into the markup. For example:
Menus usually are o the left or on the right of the “main” content, but in HTML you HAVE to place them befor or afterwards the content. But there a no good reasons for choosing neither one or the other way. But on the otherhand the order of the “p”-elements inside your content is important, so somewhere is a gap in the semantics of your content…
I agree, up to a point.
There are some CSS hacks that depend on redundant spans and divs to accomplish their goals; as often as not, this is to accommodate some kind of browser bug.
But using, say, a ‘div id”sidebar”‘ is not, IMO, tag soup. It’s not semantically meaningful, but it does help the author organize his thoughts, and (fwiw) gives a jump-ahead anchor for non-visual displays. And you really can go a long way towards visually re-ordering content in CSS.
That said, just yesterday I cooked up a test document that uses CSS and empty divs in much the same way we used to use shim gifs (only works correctly in non-IE browsers).
Thought: Why would you want to use div and/or span tags if it weren’t for the CSS design?
I’m not comparing using DIVs and SPANs to using TABLEs, I’m saying that there is still information in the XHTML that is used solely for presentation.
I know DIVs and SPANs have no semantic meaning, but it still puts code for presentation into the HTML.
(Anne, I tried posting this comment on your site and got an invalid XHTML error: Tag all may not contain raw character data.)
O yes, my much hated cryptic error messages :-). I will change them eventually. It just means that you have to use block-level elements.
To reply to ben. It does matter where the menu is placed. Try tabbing around or view it in a text-browser. I and B can’t replace STRONG and EM, they don’t have any semantic meaning, just like SPAN and DIV.
To respond to MaThIbUs, that would be necessary if you want to transform your document into a different one (using XSLT or a similar approach).
@MaThIbUs: to group text blocks according to some kind of [hypertextual] function…
@Alex: The difference between tables and divs is, that [blind]tables are tagabuse, while divs, by defintion can’t be abused.
If you’ve got extra-divs or spans in your html, because you need it to get a certain css-layout working, your html is not semantically incorrect. These divs, may not make sense to a reader of the sourcecode, but they don’t corrupt the meaning of the document, as well as different presentations of the document…
@Anne:
1. Of course does it make a difference where you put the menu.
What I meant, when I said, ” there a no good reasons”, was that the reasons for putting the menu before or behind the content, are not of hte same kind as the reasons you place the first chapter of the content before the second on.
Consider, wether you’re going to place a menu at the beginning or the end of a document depends on kind of document. For a weblog or a news page in some cases [outputmedia] it is an advantage
to put the menu behind the content… [ever tried to read weblog via google wap-proxy? ;]
Actually the position of the menu in the sourcecode is some kind of arbitrary, because the menu is on the same conceptual level as the content, but in HTML and XML, theres no way to model
equality without order…
2. ok.ok. concerning “i” and “b” i wanted to say, that the difference between the presentational markup and the semantical markup may be extremly small. In fact ourdays “strong” and “em” are used in the same way, as “i” and “b” were used three years ago: inline elements to highlight [not to say ’emphasise’] special inline text-elements. (Assuming that “i” was not used as kind of tagabuse, like to markup quotes…) The intention in both cases is the same, and if this is contiually the same, there is semantically no difference; besides what’s written in the W3C-Recommendation. ;]
Ben, you’re misunderstanding my post. I’m only saying that most of the time there are still presentation tags in the XHTML. It isn’t a clean separation yet.
Actually, there is semantic difference. Search engines treat those elements different (talking about the I, B, EM and STRONG thing).
And you must be aware that EM and STRONG, opposed to I and B, don’t have a predefined style. I could give them a different color, like red, instead of rendering it italics. There is difference there.
@Alex: I got that. But the question is: Are extra divs and spans [even if only used in combination with and for the purpose of css-styling]presentational or not?
My answer would be: No, they are not presentational, as they have no predefined presentational meaning.
@Anne: Ok. I’ll try it another way:
What’t the textual function [besides how they are interpreted by browsers and the like…] of “i” “b” “strong” and “em” according to the fact that “h1” is a level-one heading of the current document, what is in our textual practice some kind of lable, about the content inside that chapter?
I don’t agree. Having no predefined presentation (and they do – DIVs are block elements) is irrelevent. They wouldn’t be in the source if you weren’t going to use them for presentation styling (in the 99% case).
waarom webstandaarden
Er is momenteel weer heel wat discussie gaande over het gebruik van webstandaarden en de scheiding van content en presentatie. Vooral het Lockergnome redesign heeft heel wat stof doen opwaaien. Zoals we van hem gewend zijn heeft dezwozhere een samenvat…
@Alex: so we obviously have different notions of semantic and presentationl markup.
As I really enjoy this discussion, because, we get closer to that thing we all call “semnatic web”, I would like to continue it, but I’m afraid, you might think, that the comment section of your weblog is not the right place for that.
Anyway, it was a pleassure dicussing with you, and I’ll keep visting your blog.
Best regards,
benjamin
I’ll ignore all the comments and just post my own thoughts. [I could IM Alex, but I am lazy, and I think I want to be public with this.]
The zealots would, indeed, like you to believe that you can separate all styling and structure. More often than not, though, I find myself ending up with a div that wraps all the other content. Isn’t that superfluous? Why can’t you just apply all your styling to body?
Well, in many cases, you just can’t, which is a shame, really.
At that one point, you’ve added some superfluous code.
Now, the interesting thing is that we’re in an ever-fluid system of evolving standards and evolving browser support. Will we ever reach some “end point” where XHTML is “done” and CSS is “done” and it’s just putting together a wireframe in XHTML and sprucing it up with CSS?
Probably not. Why? Someone will want some new feature. A new device will come along that changes how we view content presentation.
Does this mean that we should never have gone to a division? No. You could have XML-ified HTML and left the styling all inside the tags, but then that wouldn’t get you the joy of One Stylesheet to Rule Them All.
Few absolute statements are 100% fact.
You can quote me on that.
Which is why the XSLT looked the way it did for Nextance. Both the HTML/CSS were for presentation, and the content was farther back in the pipeline. You can’t get away from using HTML/XHTML, but you can choose to put your content elsewhere.
Myths of Separating Content/Presentation
Short version: we’re not there yet, though CSS and XHTML are a step forward. Long version: a rant about meaningless…
The Myth of CSS, and the Response
Alex King posted some thoughts about how using CSS to seperate content and presentation is a farce. A powerful statement. And one I don’t buy for a minute. The ugly truth is this: almost all CSS/XHTML sites have their own…
I agree HTML pages still contain loads of hacks, the span tag being the most used tag for hacking little effects.
I guess this is inevitable and that, anyway, just as when you write in real life, a complete separation of style and content would not be relevant.
It is nice to read pragmatic statements, although they always come with provocative titles 😉
From France, sincerely.
I agree completely – I don’t think we should have 100% separation of presentation and content in XHTML – it’s still XHTML, not XML.
The Myth of CSS: Followup
Luke has posted a very thoughtful article inspired by my Myth of CSS post. (Thank you Feedster for making ego searches so easy.)
Many of the initial comments and related posts I got were focused on semantic tag meaning and if I was equating DIVs wit…
I don’t know about any of you guys, but I’ve been seperating my content with presentation for years.
I’ve also been using tables as elements– pre-built legos– and placing them in seperate files…
include (‘ whoa.html ‘)
Simple.
And it’s cached!
Alex, Good to know that you’re a XHTML geek (just like me :p) but did you know that XHTML is not just the DOCTYPE, you must also send the MIMEtype as application/xhtml+xml.
As for XHTML 1.0, modern browsers read it as XHTML but IE reads it as Text/html. But XHTML 1.1 can’t be read as text/html so IE messes things up badly. I suggest using XHTML 1.0 till IE gets full XML support.
I sometimes think, that people are overrating the importance of how the coding of the page looks like and forget the value of good content :O
[…] at talk about best practices in terms of blog site designs, and happened across this article: The Myth of CSS | alexking.org I’m reading through the 63 comments on Matt’s code is food post and I inevitably got to one […]