Is just read The Myth of CSS and I must say that I disagree with some of the points being made throughout the post:
The ugly truth is this: almost all CSS/XHTML sites have their own version of tag soup in a combination of extra DIVs, SPANs and BRs used purely for formatting and blocks that have to appear in a certain order for an effect to be applied properly.
I agree with the BR element part, but I have never come across a situation were I would need that particular element for a visual solution (that sounds evil, doesn't it?). The problem here is that Alex King is comparing DIV and SPAN with tables. Of course, he likes standard-compliant sites as much as you do (at least, that's what I think), but he misses the point that DIV and SPAN have no defined semantic meaning at all, where tables do. Tables are intended to be used for tabular data, like site statistics, not for layout. A data processor, like a search engine, would expect that tables contain tabular data, just like H1 contains the most important header. It would not expect that tables contain a layout, since it looks to the semantics of different elements. It can't make assumptions of the content, since a search engine can't read, it processes data.
DIV and SPAN however, have no defined meaning. Therefore, a data processor doesn't index their contents different and that leads for me to the conclusion: they are different from tag soup
. You could ask yourself if it is good to have elements that have no defined meaning, I would say no. For HTML however, this is different. As I tried to say yesterday (most of my posts are incomplete ;-) ), HTML is not markup language that can handle every situation you come across. I think that Ben explained that quite well. In HTML we need these elements for situations where we don't have the right elements to do the job and sometimes we need them to "hack" around browser limitations. You could say that they are useless at that point, but please remember they have no defined meaning (that is very important). Next point:
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.
Another point where I have a different point of view. I think that the point Eric Meyer made a while back (in The Incomplete Divorce) is a really good "answer" to this:
My semantic correction is that we aren't trying to separate presentation and content, but presentation and structure. Doug makes this point throughout the latter part of his post, but I think this is the important thing to state right up front. Without content, it's very difficult to have any presentation, except maybe a blank browser window (very minimalist, but not necessarily useful).
Read the whole post for some very good explanation and examples on this subject. As I side point, XSLT and/or STTS will solve this "problem". From now on, it separate presentation and structure
.
(I hope that pingback is going to work...)
If you ever read the specs of XHTML 2, you'll probably noticed <section>. It's a tag that's gonna replace almost the entire "div-soup" that I use now to group my paragraphs. In XHTML 1.1 and lower, div has a use, dividing pages in different sections of paragraphs, but <section> will be more accurate for that.
Spans are useful for code highlighting. There's no standard for describing code. Spans must be changed into "CodeML", there's a standard for mathematical things, why not for syntax highlighting in code?
About the "seperation between content and presentation", in my experience (which isn't that big, but I know where I'm talking about) it's almost always possible. You need some very very weird stuff, if a lay-out is impossible to write in clean code.
By the way, your posts are too long, I have to scroll and that sucks ;)
As I pointed out yesterday ;], HTML, was desing for a special purpose - to markup scientific articles - what was and still is quite an easy job for HTML or any XML-Language, because, the tree-like structrue of clean HTML and any XML is perfect to markup linear Texts. Actually SGML was created to markup linear texts.
AND scientific articles and novels etc. have such an easy structure, that it's quite easy to map the tree-like-stucture of them onto a 2D graphical presentation.
BUT todays website have only a few things in common with a printed atricle. Their far more complex in the way, the use the 2D of their presentation. So it is no wonder that neither HTML nor any XML-Language could perfectly "markup" the structure of today websites.
So we have to find hacks and workarounds within the borders of HTML. But this is not as bad, as the discussions about "pure semantical" markup prentend it to be, because the meaning and the quality of of the markup depends on the fact, that the webdesigners on the one hand, and the browser-programmers and searchengine-programmers and semantic-web-tools-programmers on the other hand, agree on the meaning of the elements and attributes. Markup does not have meaning besides such agreements. Compare C. M. Sperberg-McQueen Writings on that:
http://www.w3.org/People/cmsmcq/doclist.html
esp:
http://www.w3.org/People/cmsmcq/2004/bielefeld/bielefeld.html
http://www.w3.org/People/cmsmcq/2002/whatmatters.html
I'm not sure wether there will be a better semantic Markuplanuguage for the WWW than HTML, but right now it's to early to design it, because our medium ist still to young, and things develop to fast, to design an allembracing Markup of 2D/3D interactive Interfaces for multimedia Content.
We have to workaround with HTML but that does not mean, that we ought to produce tag-soup all along. Use HTML, as semantic as it gets, and if you reach the borders of it, hack it! But keep semantics in mind.
If you act like this, you'll get 99% XHTML 1.1. valid Markup, that semantically quite fine, but not maybe not as good as it might be in a far more advanced Markuplanguage. So I think,there's no need for "the myth of css" or any semi-religous battles around the purity of Markup...
...but he misses the point that DIV and SPAN have no defined semantic meaning at all, where tables do.
I don't miss that point at all, I'm saying that because these tags do not have semantic meaning and are usually used for presentation. That means we sitll have presentation tags in our XHTML.
And I want to point out that neither div nor span is without semantic meaning, and neither do they play a different role in XHTML2 than they do in XHTML1. A div has the role of a genric division of a document, a section of content. There's very few documents on the web where there is no place it's semantically correct to place a div to wrap sections. The span has a little weaker meaning, only meaning a generic grouping of text. Note that their explicit semantic meaning is a generic one, in difference to the specific semantics of all other HTML elements. The XHTML2 section element differs in meaning to div in that it is not a generic section of a document, but a generic section of text/content.
Also, I don't agree that the use of div and span as seen on the web today is in general presentational. Why? Because when you want to use a certain presentation on a group of elements or general contents, that means there is a structural relevance for that grouping even if there is no semantical meaning to the group besides being a group. Thus div and span in their properties of being generic grouping without any other semantic meaning are spot on.
liorean: spot on! That is what I think as well, and you say it well. On the other hand one can see sites where there is a clear over-use of divs and classes (dubbed divitis and classitis), which is especially a beginners' mistake. In that sense I think Alex may have a point.
I don't seem to understand the whole article due to my bad English, but this is my view on some things.
My semantic correction is that we aren't trying to separate presentation and content, but presentation and structure. Doug makes this point throughout the latter part of his post, but I think this is the important thing to state right up front.
I think we do both. For example:
Without content, it's very difficult to have any presentation, except maybe a blank browser window (very minimalist, but not necessarily useful).
It depends on the things we are talking about. Like Scalable Vector Graphics. It's a XML subset, but it's more presentational then structural.
Due to the tragedy in Madrid, I haven't read the article in question; for me some site are available and some aren't. Anne's site is, and I have some comments based on his post and these comments...
These comments pose, for me, an interesting yet nit-picky problem, something that I have encountered in many places of web design.
If we think of div's for grouping common elements, then what happens when you come across, for example, a ul used for the main navigation of a website?
On fiftyfoureleven, and in my blog, I have the main sections separated using div's, but since a ul is a block level element, I didn't bother wrapping the navigation section in a div with an id of 'navigation'.
The result, besides inconsistency in my markup, is that now I have style hung on div elements that aren't really required in my document *and* in a ul element that *is* required in my document.
Nitpicky, but relevant, I think.
Well, just because the div element is a generic grouping element doesn't mean other elements aren't also grouping elements. They tend to be specific grouping elements, however. If you have a group of elements or contents, they should be marked up as a group. If that group is generic you should mark them up using div, however, if they are a list, it's semantically more correct to use a specific grouping element such as ul, ol or dl; chosen depending on what semantics the list can be ascribed. div is generic, and should only be used when there isn't a more specific element to use.
@liorean: Hmm, fine. For me "genreric" sounds very much like "none". But to be precise, you're right.
@Jerome: Great Comment. And Here you got the point: If XHTML should be pure Semantics, why should anyone devide XML from XHTML?
My answer: because XHTML factually is a language to markup internet-infaces and in that function it's semantics can't only concentrate on textual elements, as a website simply exists of much more.
Ladies and Gentlemen, I'd really like to contiue this discussion, but I'm afraid, Annes not happy, if we abuse his weblog for this. Anyone got a proposal for a good Forum? I met Anne at the Operas webdesign forum, maybe we could contiue there?
Cheers liorean that's a good explanation.
Ladies and Gentlemen, I�d really like to contiue this discussion, but I�m afraid, Annes not happy, if we abuse his weblog for this. Anyone got a proposal for a good Forum? I met Anne at the Operas webdesign forum, maybe we could contiue there?
Why shouldn't we continue here? Isn't the goal of allowing comments to start a discussion?
Be my guest ;-)
As always, I am little concerned with the holy crusade for semantic purity. I am a pragmatist. Until I have relative design freedom, I am not going to worry about subtle markup issues.
The 'tag-soup' issue is HUGE, but it is not so much about semantics as practical production issues. Using CSS instead of FONT tags is better because it strips hundreds of tags and replaces them with a few general declarations. Likewise, replacing tables with divs for layout has practical benefits that far outweigh the slight semantic improvement. For one thing, a div is only one tag whereas a table is (at least) 3. Also, a div accepts presentation in a much more generic fashion without all the assumptions that browsers make about tables.
I agree with the article's premise that most so-called standards-based pages have many tags used expressly for formatting. Of course they do! You need hooks to apply CSS. I think the 'Myth of CSS' is something that someone could only come to believe if they never actually wrote CSS/XHTML but read a lot of web design blogs (how many people do that?). Anyone with experience intuitively understands that XHTML and CSS files do not exist in a vacuum.
Now, I like Eric Meyer's point, but I come at it from a different angle. My goal is not to separate anything _per se_. I separate things where it's convenient and makes production and maintenance easier. Nothing more, nothing less.
Interesting points Gabe, but there's no reason to be concerned with a 'holy crusade for semantic purity'. I think your pragmatic vs. semantic purity situation is a result of how the 'net evolved.
Had 'they' foresaw some of what it would become today, I would imagine that the some appropriate tools would have been written... Oh wait a sec, they were, CSS isn't a new thing, it's the damn browsers that put us in this situation, again.
If browsers were capable of doing what they were supposed to do, chances are we'd be degrees closer to the 'semantic purity' of which you speak.
That being said, although there is no tangible reason at the moment to discuss these types of issues, being aware of them is important. Awareness helps to ensure that proper tools are developed in the future, and it helps web developers themselves to be aware of what it is they are doing, and what they should be doing in the future.
Thanks Anne, for the invitation.
As I am more in XML than in HTML, I'm not that much a friend of pragmatic sollutions and workaround that are focused on how browsers behave.
But on the other hand I'm not conviced of the "holy crusade for semantic purity" either.
As it we worked it out in Alex weblog comments, there are at least two notions of semantic markup
1. Every Markup that does not explicitly markup any structural or contentfocused part is presentational. For example: Divs used only for CSSpurposes are presentational markup
2. Only explicit presentational markup is presentational. For example: "i" and "b" are presentational, while additional divs are not, as they are only "generic".
The question that arises from these two positions is: what is the division of presentation and structure/content good for. Why do we want it, and what's the benefit of it?
The answer to this question comes from within the deep escence of digital media: digital information have no neccesary presentation, as they are at lest 5 to 6 times interpreted on their way from ones and zeros, to the screen.Many applications, escpecially the early ones treated this property as bad: Word and PDF have a hard time to look precisely the same on every Computer.
But actually this property is a chance, it is a property that no other medium has, and that can dramatically be used for cultural, economic and whatever purposes
The internet, [besides to publishing houses] is the firstplace, where this property gets a central role: We devide the structure and the content from the presentation, because, we want to be able to create different presentations: For regular browsers on 1024x768 Screens, for browsers on mobilephones with, [I guess] 100x200 Screens, for a appropriate print-presentaion on DinA4 Papers, for Braillebars, for automatic text-reading-engies in - for example- cars. Or maybe we even want to transform our XHMTL-page one day into a future standard we don't know yet like XWAPHTSVGML-Whatever 2.0 or whatever.
With this application in mind, additional generic elements with CSSpurposes only, are no harm, as they are most of the time simply ignored. Only real tagabuse is be harmfull for crossmedia-applications.
A secind thing to keep in mind when talking about semantic-markup is that "semantic web"-thing which definetly exists of more than semantic XHTML...
For semantic-web-applications, like improved searchengines and ontolgies like OWL and XTM it is uite important to have semantically correct data, as the work with the documentstructres. But again in this case, generic elements do no harm as they should be ignored, as long as it is not stated otherwise, by addintional stylesheets, or whatever. So again, every things fine, as long, as you don't abuse tags.
And the last point - the one I made here before - The HTML DTD was designed for scientific articles, while the whole Internet-idea was much like the Vannevar Bushs Memex or Ted Nelsons Xanadu: a textual database highly crosslinked. Both of them as well as the developers of HTML had an Idea of what the information-network should look like, that was very very close to typographic and layout concepts of scientific articles. They simply could think of all the menus, navigation bars, orientation stuff, and crazy Ideas of graphic- and interface designers, that make up today state-of.the art webpages.
So it's no wonder, that there are no tags in the XHTML that are meant to markup menues... etc. But we have to devide a menu from the content, from the logo, from the orientation, so that user could do what they are supposed to do: use it. So from my point of view XHTML is far to short to cleanly markup webpages. It could be much designed much better for designing webpages on 1024x768 screens. But with generic Elements I can work it aorund and create pages that have al the design, usability and whatever advanteages of the past 8 years, without destroing the benefits of semanticmarkup, while at the same time, by using mostly these "only generic" elements I even keep my markup save for future applications, as the generic markup simply IS generic and could be ignored or used for other purposes...
So it�s no wonder, that there are no tags in the XHTML that are meant to markup menues etc.
The <menu> tag defines a menu list, but this element is depricated in HTML 4.01 and it's not supported in XHTML: W3Schools - The <menu> tag
I'm also not sure if a menu should be structural or not. for example:
But what about a menu. Should it be structural or not?
The question that arises from these two positions is: what is the division of presentation and structure/content good for. Why do we want it, and what�s the benefit of it?
A division is often used for presentation, but I think it could be more then that. A division can groupe elements and content together. This way you should know they belong together.
@Jerome:
A division is often used for presentation, but I think it could be more then that. A division can groupe elements and content together. This way you should know they belong together.
Ups, I think, you got me wrong. I didn't mean the "division"-Element. I meant the separation of presentation and structure/content... But as you seem to know a lot about tha too, you may have a good answer for that too...?
Damn my English sucks arse. Well I don't have a straight answer for it. Maybe someone else has.
The question that arises from these two positions is: what is the division of presentation and structure/content good for. Why do we want it, and what�s the benefit of it?
Why is it a Good Thing(TM) to separate presentation from structure? Because if you do, the structure becomes more usable.
If the content of a document is properly marked up for structure, you can use it for multiple purposes:
For each of those cases, the application involved can apply different kinds of styling. Some of it can be provided by you, the author. Other aspects can be provided by the application.
If you have a large site with thousands of documents, separating structure and presentation makes a lot of sense. If you want to alter the appearance of your site, you only have to update one style sheet, rather than making changes to the thousands of documents.
Does that begin to explain why this is a Good Thing(TM)?
@Jerome: I guess, it was more up to my arse sucking English ;]
@TOOLman: Ok, these things have I listed also in one of my above comments. So bu these purposes of the separation, you don't get problems with additional "divs" and "spans".
@anyone:I'm not sure how many people still read this comments section, but I still have question, as I'm working on my Ph.D. which copes with these problems: Waht would you say, ARE the structural Units of a website, besides the ones we have in HTML? What is the Essence of the Concept we call Website?
Waht would you say, ARE the structural Units of a website, besides the ones we have in HTML?
There definitely could be in most web sites. The problem is that they are different in different sites. Incorporating new elements for them in (X)HTML would probably bloat the language, and it's dubious whether it would benefit user agents very much.
I could see the possible use for a <menu> element (not the old deprecated one). A user agent could present that in a consistent fashion. XHTML2 will give us <nl>, if I'm not mistaken.
Similarly, there might be a use for <header> and <footer> elements, which could be replicated on each page in a paged medium.
I'm sure there are lots of such elements that would be useful on some web sites. The question is if they are useful enough to bloat the markup language with…
Well, I think there are four clear distinctions here:
And of course, you can answer on any of theose levels, more or less specifically. There's no definite border in between them either, it's a gliding scale. Still, I think HTML and XHTML needs more of the two extremes, as well as a distinction between what elements are whihc kind. A list may be written in a reguler sentence, inline, but XHTML doesn't allow any of it's lists inside an element which takes only inline level elements. Sadly DTD doesn't allow for this, but I would like to see a method of "delegating" a content model limit to children, for elements to which that limit does not apply.
Actually I'm not interested in creating or proposing new Elements. The Concept of the thing we call "website" was once very close to the concept we call "book" or "article". But websites moved on to become something new. And I'm interested in all the things and properties, that websites have, that books and articles don't have.
(is it a navigation element?)
So it comes up to the question: By which concepts could replace "navigation" in the above sentence?
Versuschka G?proposes in her Book Grids for the Internet [I only have a german version of this book, so I'm not sure, wether it has the same content, but the german one is really worth it's money] next to navigation, orientation, logo and picture/text (content)
But I'm not sure, wether this is all... Any Ideas anyone?