johnhudson wrote:guy wrote:Haven't seen the article but evangelising the politically correct usage of HTML5 made me laugh. Reality check? What heresy, we have a religion on our hands.
Not politically correct; just best practice. Have a look at
http://www.whatwg.org/specs/web-apps/current-work/ and tell me what is wrong with it.
"Best practice" - really? Best for whom?
The core problem is its mantra to move away from the original user-centric language and instead to take a rigid bottom-up view of the distinction between structure, content and style. That has never worked and never will. Web pages and the people who write them are top-down things. That would be okay as a rule book for a programming language, but not for a language to be used by us mere mortals.
Style is, supposedly, banished ruthlessly to CSS, with html reserved for semantics. In practice this has neither happened nor can happen.
HTML Tables layout is reserved for data, and for page layout it is a Sin. But what if I want a table-like page layout? Why, how kind, the
CSS table model provides all the missing table components. Oops, except for things like the analogues of cellspacing, cellpadding, rowspan, colspan, which are now an utter nightmare to implement. But hey, these CSS constructs were actually introduced in order to present a tabular display where the programming language has no concept of such a thing. Oops again. Instead of old Devils like me styling page layouts using semantic tables, we now have HTML5 Angels coding semantic tables using a styling language - broken our mantra there all right.
Then there is the fact that most people rely on visual clues in a way that does not separate structure, content and style in a rigid way. Is a page layout a semantic thing or a styling thing? CSS has a concept of "normal flow": content is presented in the order it appears in the sequential flow of the source page. Is normal flow a semantic or stylistic concept. Well, if we break normal flow and present Section 2 above Section 1, I think you will agree that the presentation has broken the semantics of the content. Here, breaking normal flow has broken the semantics. But now consider a centrally-focused layout with boxouts all around. We may happily code the boxouts in any order because we must break normal flow in order to position each to best effect. This time, breaking normal flow does not break the semantics. This helps to illustrate how the relative positioning of objects is sometimes a matter of semantics and sometimes a matter of style. Page layout cannot be cleanly dumped in either camp, and separating the two into distinct languages makes an utter cabbage of the way many page designers go about their business.
Every DTP pro will tell you how important frames are. html5 hates frames, only the iframe is left, as a kind of apology for a media container. The html5 designer must resort to floating divs all over the place and managing how they jump around. More cabbage for the page designer.
Consider how the em and strong elements have wholly failed to replace the b and i elements and must now exist uneasily alongside. em and strong are semantic concepts, b and i are styling concepts.
Sorry, but HTML5 may be intended as a coder's paradise but the truth is, time and again the hard facts of life force it to break its own mantras. And even when it doesn't, there are plenty of real people out here with the strongest of practical motivations to do that for it.
Oh, yeah, and then there's accessibility. I once coded duplicate web pages using nested html tables and css to lay it out, then a blind friend with a reader visited them. The html page read flawlessly, the css read backwards because the reader assumed normal flow. When I told him the html was not only tables but nested he was astonished - his reader had treated them utterly transparently and he had no clue they were there. So don't start.
[Update] Here's another way to look at the fundamental problem. HTML1 tried to provide a semantic model for the styling of content, while HTML5 seeks to provide a styling model (CSS) for the semantics of the content. It's back to front. IMHO we should be enhancing the original model, including:
Reintroduce frames as a layout tool, so we really can limit Tables to tabular data.
Compatibility between frame transclusion and browser navigation.
Adding units like pt and em to html attribute values
Normalise attributes across elements by allowing elements more kinds of attribute, not less.
"Oh no", you cry, "you have borked my nice semantic DOM". Have I? Then take a leaf out of the MathML book. Over there they have the problem that a given semantic object (such as a decimal division) may be represented by different characters (a comma, a period, a mid-dot) in different mathematical representations, aka styling schemes, while a given symbol (such as a period) can represent different semantic objects (times, decimal division) in different mathematical representations. The have had to resort to dividing the supposedly purely semantic idea of elements into presentation, content and semantic elements - the semantic element being a recursive idea of a semantic construct whose job it is to define the content as a semantic construct, whoop-de-doop. Being an approved HTML5 extension for use in web pages, your nice DOM must of course be compatible with all that MathML semantic spaghetti. So no, I haven't borked your DOM at all, it's already way ahead of you. You just need to recognise the heresy that some elements are semantic in nature and some are not, just like mathematicians already do.
One more for luck. We have seen there is a difference between presentation and semantic elements. The html div element is a purely semantic construct, designed to contain a set of semantically related constructs. But it is also intended to be used to put a presentational box around a set of visually related constructs. In other words, the div is a dog's breakfast of an element. To get a clean system, it is necessary to split it into two distinct types of element - the one purely semantic (no styling permitted) and the other purely visual. In my scheme above, I suggest that the frame be resurrected for the presentational aspect.
Have I told you enough yet about what is wrong with HTML5?
"We don't need no frikkin' aliens, we c'n do this ourselves!" — anon.