First of all, I’d like to point out something that’s not directly related to the issues at hand.
The website of the company I work for is horrid. As pointed out to us via a form submission, there’s no doctype declaration. Nor, I will point out myself, is it a site to be proud of in any way, shape, or form. It uses tables up the wazoo, needless BR tags, etc etc - in short, quite embarrassing for a standards-minded developer like myself.
It’s a simple case of the shoemaker going barefoot. He’s so busy with projects for customers and clients that he has no time to make himself shoes. I’ve got at least 3 big projects on my plate (big is relative, since I’m the only web dude around these parts), and a number of people in the waiting line to ask for sites. In the words of the (in)famous Prince Humperdink, “...I’m simply swamped!”
Ok, enough of that embarrassment. :p
Dante: “What I meant was nitpicking about the little things (strong and b, em and I).”
Yes, for most users, it is nitpicking. But tell that to the blind man who uses a screen reader to surf websites. The B tag is purely presentational, and says nothing about the meaning of the content it encloses. It is merely “Display this text in bold.”
STRONG, on the other hand, is (usually) formatted by default in bold, because that is the commonly accepted way of placing a strong emphasis on content. But when you look at (listen to?) screen readers, they know to place a stronger emphasis on text designated with the STRONG tag, because it designates meaning, not appearance. Semantics (via structure), not presentation.
Rob G.: “This article is not preaching anything new and is merely recanting the widely used concept of separation of content and stylization.”
Partially correct. ;) As stated in one of my previous comments, I wrote this 5 months ago, but it was only able to be published now.
However, at the time of writing, I had not seen anything besides “separate content and presentation”. I did not see any mention of there being 3 players, not 2. And I, needless to say, did not see every single article ever written, so forgive me if I missed something. :)
Steveg: “You could certainly seperate out block structures without too much sweat but where does a set of em tags fit into the scheme. Are they presentation, content, or structure?”
EM tags are semantic in nature, and are structural markup. They have default presentational styling assigned to them by the browser, and they set apart content contained in them as emphasized.
Ronald van der Wijden: “Consider a markup language which did offer all the different elements needed to mark up each and every bit of content with the appropriate meaning: each element could be specifically targeted for styling without any “pollution”.”
Quite correct. This is, according to my limited understanding, what XML/XSLT/XHowManyXAcronymsCanWeHave is for. ;)
Kristian: “Separation must have a purpose. It also seems that the author has missed the point of separation; the main reason this “separation system” should be allowed to exist is to be able to present the parts as a whole. So why not call it a “wholer system”? Since that should be the purpose of separation….
...Sorry for the poor english.”
First things last, your English is considerably better than many (most?? :-/) native English speakers.
Secondly, the purpose of separation is not to present the parts as a whole. That is comparing apples and oranges. “Separation” has no purpose, it IS a purpose. With separation, we allow content changes without affecting site structure or presentation, and presentation changes without affecting content.
Yes, it’s pointless unless put together for the end user. But separation does not have a purpose, it is the purpose. :)
Charles Belov: “IDs were presented here as being presentation. I am in the camp that wants to use them as structure: ID=sitenav ID=pagenav etc.”
That is the proper use of ID and CLASS properties - structural markup and CLASSification. They are handles to allow styling just as much as Hn tags are. The only exception is that the ID/CLASS is user-definable, therefore it does not have a default styling set by the browser.
Mathias Munk Hansen: “You cannot separate structure from content without making the structure ilogical. That’s why I don’t do it.”
Not to the end user, no. But if you store your articles in a database, you certainly don’t want to store the site navigation DIV along with it. That’s a kind of structure, too. I assume you’re talking about STRONG tag structure and the like, however. ;) In that, you are correct - it should be, at every stage, part of the content itself. Which was one of my points in the article. :)
XML and Various Related Flavors: Those of you who have brought this up are probably making a very good point. Unfortunately (see the Shoemaker analogy above), I haven’t had the time to teach myself this branch of coding. Yet.