Web Forefront

This is progress, because it's based more on reality than on the usual spacy navel-gazing that defines our standards. Netscape was the dominant browser, then it fell behind, and Microsoft IE took over and "ad hoc" implemented what it could and what corporate politics allowed. Then years after it gained dominance, FireFox came along and tried to rewrite history. The result is a cross-browser coding disaster, and as a web developer of 15 years' experience, I blame Firefox more than IE. HTML 5 is a chance for both sides to fix their sites on something productive.

Would you not say that moving to XHTML forced CSS to be adopted? If HTML 4 was still the standard, I don't think CSS would have seen the surge in use, or there would be an even worse mish-mash of HTML 4 and CSS then is currently being used.

Thank you.
Good summary for those of us who create web pages, but are not caught up in all the standards hype.

Hello,

Wow, very detailed and well informed.

However, I have few personal opinions regarding the issue with web development. I personally believe that its mere lazyness not to conform to XHTML standards, and to continue supporting an ill tagset "meta language" as HTML... if anything, XHTML ensures that all devices and interpreting languages are properally interpreted by DOM. This in the long run I suppose ensures a proper standard.

We must not forget that there is more too web development then '.html' files. We have to consider the fact that we can use our own DTD file to define our own tagsets, and if all your worried about is considering whether or not to end your tagset, or to use a differnt character case within your tagsets, that all can be considered inside the DTD. Infact, XHTML is a mere standardization of HTML, while considering a few deprecated keywords, which can eisly be added to the DTD. I hope that most browsers support interpreting the DTD. I figure not all device applications have the required memory or technology put into them to worry about the DTD interpretation, which could be an issue...

Further more, sure support both, heck, build dynamic applications that can process which the browser prefers or is applicable to support, all from within your application. In fact, I believe in the 2, but prefer and trust in XHTML.

Oh dear goodness another lurking security cuprit. Just as the web developer community is learning to counter XSS, SQL Injection, AJAX vulnerabilities, an extra feature is added to HTML; native data validation.
Why is that a potential problem? Because you can't rely on data entry validation done "in the page" i.e. at the surfer's webbrowser.
And if you want to implement data entry validation "in page", just to achieve an attractive and responsive user interface, you still have to the same checks in the "back end". Question: how do you keep the "in page" and "backend" data entry validation checks in sync?
Its double and error prone work. It will either happen badly or not at all.

Well, I should have post this comment at the HTML 5 commitee.

In any case thanks for the soapbox ;-)

Wow. Looking through that draft just makes me wonder what the point is.

There is no way that a relevant tag for every minutia of a web document can be made without the language becoming an over burdened nightmare. I don't understand why they didn't just come up with guidelines for something like the 'rel' attribute which could be applied to block level and inline elements.

[div rel='section'] would seem far more extensible than the 'section' block level element. Especially when you start getting in to stuff like the 'dialog,' 'aside,' and 'meter' tags.

If the 'dialog' tag is to work, especially, it needs more differentiation from a definition list.

What about the 'hypothetical' tag? Or 'statistic?' You could list hundreds of tags that would make as much sense as the new tags in this draft; which is very little, indeed.

Although... I do have to say that I like the 'm' tag. It can stay :)

This is crap. HTML 5.0 come on! I agree with what another user wrote - it's mere laziness that people are dealing with rather than "difficulty" conforming to standards.

We've finally arrived to a point where well-formed XHTML and CSS 2.0 are rendering VERY similar (if not identical) in all browsers.

I was a developer of cutting edge apps during the 4.0 browser wars and I never want to relive the nightmare of writing javascript for multiple DOMs.

We need standards.

Seperation of content from presentation!

"Would you not say that moving to XHTML forced CSS to be adopted?"

Because it would be false.

CSS was embraced by everyone, even though many (most?) did *not* move to XHTML. When sites that are clearly still using HTML 4.01 are nevertheless using CSS extensively, usually exclusively for all layout issues, it's an incontrovertible fact that it wasn't a move to XHTML that "forced" the adoption, because in fact no such move was made. Rather, it's the very useful nature of CSS in itself that caused it's near universal adoption. No one was forced to use CSS, they just did because it's too damn useful to ignore.

Just when I was starting to get my head around XHTML+CSS, y'all go and change things again. ;)

I have to agree with Twan about over-burdening the language with things like the new <article>, <dialog>,<video>,<canvas> and <progress> tags. Though these seem pretty benign, how do you know what else you'll need to add for the next generation of web apps. It may be slightly more cumbersome for people to roll their own <div> classes for these things, but doesn't it make the language more future-proof?

What possible benefit could there be over adding new features to HTML 4.01, rather than adding them to XHTML 1.1? XHTML 1.1 seems like a better choice in every way for a basis for an updated standard.

XHTML certainly didn't force the transition to CSS. It did, however, linked very nicely with it, which promoted the use of CSS even more. Reviving HTML is a step in the wrong direction. Creating new shortcut tags for something that's commonly used these days is a complete absurd. Are we gonna create the forum and chat tags as well just because they are commonly used applications on the web?

Maybe I don't understand all these phylosophical considerations, but why this new stuff requires a new HTML version? expanding XHTML 2.0 modules was no good?

BTW, I'll stick with XHTML.

For those complaining about HTML 5 in the comments, a few notes:

• If you don't serve your XHTML as application/html+xml, you don't really know if you are writing valid XHTML. Running your code through a validator is not enough.
  
• XHTML 2 is not compatible with XHTML 1.
  
• You can't use document.write() in your Javascript in XHTML. You have to use the DOM interface, which is a real pain.
  

Any changes to the web coding are going to have huge impact. I know that global issues like localization and accessability are in the forefront of the design goals. I would like to point out though that whatever the next step in the evolution of web coding is, it should serve humanity in a generic way and should have nothing to do with promoting Microsoft's vision for locking in all the user's in the world. IMHO Microsoft has had way too much influence on the programming paradigms we use today and I want to see the web remain vendor and operating system neutral. New standards should reflect what is best for everyone, and promote innovation. I would like to see us get to a point where web authors will not feel compelled to write IE specific content. If we don't have operating system/vendor neutrality, bad things happen.

A note on the SGML/XML distinction: HTML and XHTML are directly based on SGML and XML: SGML and XML are inextricable parts of their syntax, HTML/XHTML haven't just evolved from SGML/XML. The "heritage" is therefore highly relevant to those having to read the syntax programmatically.

This means that if you have an XML parser, you can read XHTML, but not HTML in general.

Why is this important? The SGML base of HTML makes automated processing and validation (used by ASP, JSP and countless other applications) much, much harder, as all the standard tools have been focused at XML, and SGML is much more flexible (and therefore complicated).

“HTML had mixed-in layout behaviours, allowing attributes like align, bgcolor and width to be placed directly inside markup. XHTML in effect enforced a cleaner content/layout separation, forcing designers/developers to use CSS for all their layout requirements.”

That is simply not true. XHTML 1.0 had the same feature set as HTML 4.01. It just refers to HTML 4.01 for semantics. XHTML 1.0 Transitional (what most people choose when they say they use XHTML) has all the same align, bgcolor and width as HTML 4.01 Transitional. On the other hand, HTML 4.01 Strict only has the attributes XHTML 1.0 Strict has.

“Another reason behind the XHTML push was that it would theoretically allow the delivery of this XML type markup -- properly closed, nested and devoid of layout behaviours -- to any type of device, not just a browser.”

This part of theory has utterly failed in practice. When theory and practice disagree, practice takes precedence. What works is adding an HTML parser to non-browser applications.

“And yet another reason was that HTML was based on the older and more immense SGML language, where as XHTML was to be based on XML, which provided a more simplified rework of SGML.”

HTML5 is not an SGML language.

“We've finally arrived to a point where well-formed XHTML and CSS 2.0 are rendering VERY similar (if not identical) in all browsers.”

That’s just an illusion. If you have that experience, you are serving it as text/html, in which case the browser treats your markup as broken HTML 4.01. There’s no XML parser involved. The HTML 5 spec admits this fact instead of pretending otherwise.

There may indeed be good reasons to expand (X)HTML with new tags and better functionality. However, as some readers pointed out, I do not see the reason for a new HTML version.

The title of this article "HTML 5 : We don't need no XHTML" is misleading. None of the arguments provided by the authors are actually against the X of XHTML. Things apply equally to HTML and XHTML, so why not stick with the cleaner of the two, i.e., XHTML?