HTML 5 or XHTML 2?
Vlad Alexander has written an article entitled X/HTML 5 Versus XHTML 2, discussing what he likes respectively dislikes.
While I think that both specifications are interesting and definitely contain some nice enhancements, I can’t help but think when, and maybe even if, any of these will be ready for prime time. Maybe I’m just jaded, but for sure there will be endless discussions about which will be the best, different implementations in different web browsers and so on, et cetera…
And just add Tim Berners-Lee’s thoughts and the HTML Working Group Charter to that. Does anyone see a happy united best outcome of this?
Let’s take a look at some goodies mentioned in the article:
- Any element can contain a
hrefattribute and therefore be a link. Great!
acronymis out. Good riddance! Definitely the way to go to have just one element for that purpose.
helement and headings sections. Nice!
separator. Hey, that’s a good name, why didn’t we think of that before (anyone seen code like this before:
<hr class="separator" />)? 🙂
- The new
roleattribute, to add more semantic meaning to an element. Just take a look at these babies: The XHTML Role Attribute! Fantastic! Well needed!
Web Applications 1.0/HTML 5
dialogelement, for, you guessed it: dialogs!
- The perfect element,
figure, for images and its accompanying text.
Finally, some nice additions to
inputelements and their data types:
- numeric data
What’s your take on this? Does any technology seem more interesting than the other? Is any specification/concept generally better than the other, and why? Or, are you better off as we have it right now, maybe with a slew of Microformats thrown in?
Both I and Vlad would sincerely appreciate your input on this, and your thoughts and hopes for the future of the web!
Nice write up. XHTML 2 certainly looks good and I can only see Microformats growing to increase the semantic holes in XHTML, especially as it will probably take an age to implement. I know a lot of people get irritated by the constraints of XHTML but I prefer it. Perhaps I'm anal…
Little mention of XML and XSLT has been made in these discussions. Combined with CSS and good semantic markup (XHTML or HTML) they are quietly transforming how the web works.
XSLT for example can transform a correctly marked up Microformat into pretty much anything. For me that is more interesting than deciding which dialect of HTML to use.
The <code>role</code> attribute just seems like consistent/specific ID names for certain common areas, such as navigation. Could be useful, but could be used nowadays if microformats decided to implement a similar thing – consistent naming conventions for sections within a page.
The <code>href</code> attribute on every element might be useful, but I'm unsure how well Joe Public will handle it. They're used to text (and the odd image) being a link (with an underline and the cursor change). But when you add it to large blocks, what is going to happen?
The <code>figure</code> element is very interesting considering the amount of times you have an image then a description (although, I use a definition list), and I'm sure the dialog element will plug in some hole, but I've never had to use it.
I love the <code>required</code> attribute and the whole webforms in HTML5.
<code>section</code> and <code>h</code> are very interesting and will mean user-generated content (from CMS) will adhere nicely to the correct nesting of headings.
On the subject of seeing a happy united outcome of these discussions…
Take a look at the two suggestions made in the (somewhat compact but very interesting) post http://web-graphics.com/2007/02/01/the-time-to-ab…
Maybe something along those lines could serve us well during the transition to "(X)HTML-the next generation" (whatever it will be based on or include in the end)…
Well – It's a nice dream isn't it? 🙂
What about application/xhtml+xml? Can we make it optional or kill it off altogether? This XHTML 1.1 requirement seems to have impeded XHTML 1.1 adoption. I fear it would impede adoption for any future standard also.
Browsers could be free to receive the document as text/html, test the document, and if it is well-formed, parse it more efficiently. If not well-formed, hand it off to the tag soup parser. Am I being naive about how browsers work? Is this a reasonable request?
I'm not sure which is necessarily a better standard, but I think HTML5 will do much better in the real world. It's backwards-compatible with HTML4, and parts of it have already been implemented in browsers (canvas and some forms improvements). XHTML2 is much more of a departure from previous versions of (X)HTML. I do understand and support the desire to make HTML more semantic. I just think XHTML2 is too radical to ever be widely adopted.
Personally, I'd cull XHTML 2 altogether (what's the point when 85%+ of users still cannot receive it correctly) to concentrate on HTML 5 and for the medium term, a move to XML or even UML.
Longer term I expect to see web development managed through Final Cut Pro style authoring interfaces, rather than the hand coding we know and love.
To me, they look both promising. Maybe a merge of the two would be a nice idea, if not that this would take forever to finish :).
But I wouldn't bother too much at this moment, since they both will take ages before release, let alone that browsers support also takes long. Even now browsers are struggling to support css2 and xhtml 1.0 (not to mention 1.1) to the letter, while both standards are getting pretty old now.
Yeah, I know, not all browsers adopt new technology slow. But since a great majority of users still uses IE, we're kind of stuck with what it supports. Unless you love to make browser-dependant pages off course. In that light I don't expect to do much coding in HTML 5 or XHTML 2 any time soon.
[…] â€°ÃŽÂ½ÃŽÂ®ÃÆ’Ãâ€° ÃŽÂ¼ÃŽÂµ Ãâ€žÃŽÂ¿ÃŽÂ½ Robert Nyman ÃŽÂ¿ ÃŽÂ¿Ãâ‚¬ÃŽÂ¿ÃŽÂ¯ÃŽÂ¿Ãâ€š ÃÆ’Ãâ€¡ÃŽÂ¿ÃŽÂ»ÃŽÂ¹ÃŽÂ¬ÃŽÂ¶ÃŽÂ¿ÃŽÂ½Ãâ€žÃŽÂ±Ãâ€š Ãâ€žÃŽÂ¿ ÃŽÂ¬ÃÂÃŽÂ¸ÃÂÃŽÂ¿ Ãâ€žÃŽÂ¿Ãâ€¦ Vlad Alexander, ÃŽÂ±Ãâ‚¬ÃŽÂ»ÃŽÂ¬ Ãâ€¦Ãâ‚¬ÃŽÂ¿ÃÆ’Ãâ€žÃŽÂ·ÃÂÃŽ […]
I like what HTML5 offers. Further, it removes all arguments for which is better, HTML 4.01 or XHTML 1.0: all well-formed sites with <code>DOCTYPE html</code> + <code>text/html</code> would be HTML5. HTML5 can be used this afternoon. One notable site is W3C Web API Working Group which uses <code>DOCTYPE html</code>. And, it conforms as HTML 5 in the HTML5 Checker and as HTML 4.01/Strict in the W3C HTML Validator (after switching doctypes).
I don't have a constructive opinion of XHTML 2.0. Though, if the W3C – Truly -believed it is the future of web applications, Why bother resurrecting the HTML WG? MSIE, perhaps.
I agree that it will be interesting to see what occurs over coming months between the W3C and WHAT working groups.
I don't know if you have seen it but Help-WHAT.org is the new mailing list for general HTML5 questions.
And now we'll have to choose between HTML and HTML… Great. That's the dumbest thing that could happen : having many different standards and specifications.
Having multiple thinking groups working to get the HTML better is a wonderful idea, and you cite such great ideas from both camps. But having great idea in each specification lacking in the others ? That's just stupid.
Let's hope we won't end up with multiple new HTML specs. Browser support is already lacking, what will happen with multiple standards ?
There's an old joke: "The nice thing about standards is thereÃ¢â‚¬â„¢s so many to choose from."
Thank you everyone for your input. Very good and thought-worthy!
Forgive me for being blunt, but that's a terrible idea! 🙂
That would require two passes to parse a well-formed XML document.
The whole point with serving something as XML is that user agents can expect the document to be well-formed. Thus they can use their fast, light-weight XML parsers and refuse to continue at the first hint of an error.
What in the world is the point of using XHTML markup if you're serving it as HTML? A user agent must treat that as HTML, so any XML features will be unusable.
I think that 'allowing' XHTML 1.0 to be served as text/html is one of the biggest mistakes the W3C have made. Real XHTML (with XML benefits) will never catch on as long as people are allowed to slap an XHTML doctype declaration on any tag soup mess.
Tommy, do any browsers today behave as you describe? It's my experience that many documents served via application/xhtml+xml are not well-formed XML. Furthermore, the browsers that support that MIME type don't refuse to continue as you state above; they do their best to render the page.
Browsers don't need a MIME type to "expect" well-formedness for lightweight processing — the DOCTYPE should be a sufficient indicator.
I suppose my point is that serving pages as XML doesn't mean they are XML and browsers that support lightweight XML parsing handle malformed documents via tag soup parsing anyway…so what good has the MIME type served?
Carl, yes browsers behave as Tommy described (except for mobile browsers, which generally do what you describe, and they are non-conforming). If you don't see it then you're probably still actually using text/html.
The doctype doesn't indicate anything, except for text/html where it indicates whether the browser should use standards mode layout or quirks mode layout. In particular it does not and cannot indicate that the document is XML.
Carl, at least Opera, Firefox (et al) and Safari behave this way. A compliant XML parser must abort when it encounters a well-formedness error. Gecko browsers show the infamous Yellow Screen of Death, while Opera first tries to render the document up to the point of error.
The DOCTYPE declaration is pointless (in this respect) for several reasons: it isn't required; it is only available in SGML-based documents; and it's located within the file. A user agent needs to know the content type before it starts reading, because that information is crucial when choosing how to handle the document.
If the content type is 'application of XML' the UA can choose an XML parser and expect well-formedness. If the content is 'HTML' the UA can choose its HTML parser (a.k.a. tag soup parser). If the content type is 'JPEG image' the UA can call its functions for displaying the image, and so on.
Yes they are. Or, rather, a UA must assume that they are and parse them as XML. If the document isn't in fact XML, the parser must abort with an error message.
In the same fashion, if the content type is 'text/html' the UA must handle it as HTML. Even if the DOCTYPE declaration says it's XHTML or if it's really a JPEG image.
That's the whole point of sending a MIME type in the Content-Type header: to tell the UA beforehand what type of content it can expect. The UA must believe this and act accordingly. The content sniffing that IE/Win does for 'text/plain', for instance, is horrible and contrary to the specifications.
Thanks for keeping up the discussion!
I’ve asked Vlad to read your comment.
As a response to the original article…
Implementation Of Sectioning Elements
Why would div with a role be any simpler to implement than elements? With roles you can have situations where a div is all of an aside as the main content and a footer and a checkbox at the same time; that cannot happen with element names.
Why is <nl> better than <nav>? A navigation section isn't always a list, it could equally well be a table or a paragraph or anything else. <nl> can only be used if you have a list.
How do you suggest we improve sectioning elements?
HTML 4 And XHTML 1 Faults Are Perpetuated Into A Future Spec
Faults in HTML4 and XHTML1 can be fixed.
I don't understand your view on backwards compatibility. Browsers only have one implementation of HTML, or perhaps two (quirks and standards). The more code paths you have in your implementation the more development cost and time, which is not a good thing. Forcing browser developers to add yet another code path when it can be avoided will probably just lead to the spec being ignored by browser vendors.
The problems of numbered headings have been addressed with sectioning elements. The numbers get normalized so it doesn't really matter which number you use, indeed you could use <h1> for all your headings just like you would use <h> for all your headings in XHTML2.
, and <small> have been added to address the need of being able to mark up things that have typographical convensions but don't have specific semantic elements in HTML. Using <span class> for all those cases doesn't really improve anything. <iframe> is heavily used by the advertizing industry, and it is an interoperably implemented mechanism to embed an HTML document into another. Forcing authors to use a less interoperably implemented mechanism to do the same doesn't really improve accessibility.
X/HTML 5 Does Not Comply With The X/HTML 5 Charter
Being backwards compatible does not mean that you have to include all elements the previous version had. (User agents are expected to continue supporting the elements it already supports but are not part of HTML5.) It also doesn't mean you can't redefine semantics. However, for all intents and purposes, in the case of and <small> an HTML5 UA would pretty much do the same as an HTML4 UA.
HTML5 does comply with its charter, but perhaps we have to define backwards compatibility.
What, The font Element Is Supported?
<font> was added because the state of art in WYSIWYG editors don't yet have a way to deal with semantics, so it's better to allow them to insert presentational markup when presentation was called for than to try to force the author to use semantics. WYSIWYG isn't going away any time soon so ignoring them doesn't lead to better results. (WYSIWYG editors are of course free to deal with semantics and ignore <font>, though.)
This has only to do with document conformance (that WYSIWYG editors are allowed to use <font>). It's an open issue though, and as with anything else in the spec, it may be changed or removed.
Support For Predefined Class Names
Class names are not CSS class names. They have nothing to do with CSS. Essentially, if I understand role="" correctly (there are some predefined values and it can be extended), it is the same as role="" except simpler and it was already present in previous versions of HTML.
As with the role="" attribute, the issue with multiple values has to be looked at to see if it would cause any problems.
HTML 5 Versus XHTML 5
If you want to use XML then use XHTML5. If you don't want to use XML then use HTML5. Both are fine. If you want to use both at the same time then you can do that too. You have to jump though hoops to do so but those are the same hoops as Appendix C anyway.
If you think there's too much to choose from then use HTML5. It is compatible with browsers and search engines, and if you want to use it with your "XML tool chain" then all you need to do is replace the XML parser with an HTML5 parser and the XML serializer with an HTML5 serializer.
A Too Hasty Process
The specs, or at least the WF2 spec, started before the WHATWG was created. HTML5 is not a result of too slow process at the W3C, it is a result of browser manufacturers disagreeing with the vision of the W3C with regards to the future of HTML and web applications. The estimated shedule is 15 years for HTML5 to become a Recommendation — you're the first to say it's too hasty. The unrealistic timelines and milestones you referred to are the ones the new W3C HTML WG Charter suggested.
Thanks for the feedback!
Wow, both XHTML 2 and HTML 5 have some great new additions! <code>h</code>, <code>role</code> and the disappearance of <code>acronym</code> sound great.
The new and improved forms in HTML 5 sound great too.
What I don't understand is; why are these new things specific to either XHTML 2 or HTML 5? Why can't HTML 5 drop the <code>acronym</code> element too? Why can't XHTML 2 have cool forms?
All in all I'm a bit skeptical and don't expect to have to change the way I work anytime soon, 'cause it probably is gonna take ages for browsers (and especially IE) to implement the good stuff.
How do you suggest we improve sectioning elements?
1) Predefined sectioning elements are not extensible. You have to modify the spec to add new sectioning elements in the future.
2) Predefined sectioning elements are too generic and waste the opportunity to add real domain-specific semantics.
3) Vendors of visual Web browsers have to write code to support new elements even if new elements do the same thing from a visual perspective.
If I understand correctly, sectioning elements carry 2 semantics:
1) This is a section.
2) This section is of type X.
The first is independent of the second but the second is dependant on the first. So you would need a two-part construct to model this relationship. I suggest instead a single element with an attribute. For example:
Or, I suggest using a
divelement instead of
The spec defines
navas “a section with navigation links”. If you start adding content into this section like tables and paragraphs, this section bulks up and loses its value to future devices that could use this construct for presenting page navigation in a separate window. And the
nlelement could be very useful for small screen devices.
Faults in HTML4 and XHTML1 can be fixed.
1) X/HTML 5 does not fix them.
2) If it did fix them, then it would not be backwards compatible.
The more code paths you have in your implementation [of Web browsers] the more development cost and time…
Building an XML rendering engine (like XHTML 2) is much simpler than enhancing HTML rendering engines. I speak from experience. It is so complex to build a good tag soup rendering engine that current Web browser vendors have created a barrier to entry by encouraging tag soup. What is the business incentive for current Web browser vendors to encourage valid markup?
The numbers [in numbered heading] get normalized so it doesn’t really matter which number you use…
If that won’t confuse content authors then I don’t know that will. It’s kind of like Alice In Wonderland where things aren’t really how they appear.
iframeis heavily used by the advertizing industry
So is this the real reason browser vendors and search engines are against XHTML 2? Seriously, we all benefit from advertisement programs on the Web. Programs like AdSense from Google financially supports small content providers, which is great. But currently these programs do not work when content is served as XML. I would hope that W3C addresses the needs of ad providers even if it means adjusting the XML spec. Let’s find a non-
iframesolution to this very important issue.
Being backwards compatible does not mean that you have to include all elements the previous version had.
This is objective and I bet one can use “set theory” to disprove this.
It also doesn’t mean you can’t redefine semantics.
This is subjective so we can go back and forth on this for a while.
HTML5 does comply with its charter, but perhaps we have to define backwards compatibility.
Great. I think you will find that X/HTML 5 is “compatible” with HTML 4 and XHTML 1 but not “backwards compatible”. But I hope you will also see that there is no need to be backwards compatible.
fontwas added because the state of art in WYSIWYG editors don’t yet have a way to deal with semantics
We have been producing a WYSIWYG editor that does not have a font selector or a color picker for over 3 years. It’s not rocket science. If we can do it, anyone can.
it’s better to allow them [WYSIWYG editors] to insert presentational markup when presentation was called for than to try to force the author to use semantics.
When you give a WYSIWYG user a font selector and a color picker, they will use them instead of semantic markup. Accessibility goes out the window
WYSIWYG editors are of course free to deal with semantics and ignore font
Guess what, it’s easier to sell candy than carrot sticks.
WYSIWYG isn’t going away any time soon so ignoring them doesn’t lead to better results.
But that is what the spec does – it ignores WYSIWYG editors by letting them do what they want. I see great parallels between the environmental movement and Web standards. WYSIWYG editors are like the polluters of the Web and spec writers are like regulators. In this case the regulators are looking the other way.
Class names are not CSS class names. They have nothing to do with CSS.
Not if you use the
classattribute. The spec “overloads” the meaning of
class. And also creates opportunities for conflict with existing documents that use class names that will only be predefined in the future.
If you want to use XML then use XHTML5
Here is the problem. The XHTML 5 spec is saying don’t use XHTML 5 when they say “generally speaking, authors are discouraged from trying to use XML on the Web”. Look, if the authors of the spec feel strongly about this, then they should simply dump XHTML 5. Let’s either treat XML as an equal to HTML or dump it!
@Tommy, Thank you — message is well received. I learned something today and I appreciate the explanation. If you're coming to SxSW this year, I'll gladly buy you a beverage of your choosing.. Robert — sorry for sidetracking the original post topic.
Harmen, HTML5 does drop <acronym>. XHTML2 does have cool forms (XForms).
The main difference is not the feature set, but the compatibility with existing content on the web, current authoring practice and existing implementations.
With HTML5, you don't have to change the way you work even when you want to start using the new stuff (i.e. when they're implemented in browsers). You just start to use the new stuff and it will work.
OK, it seems that many people fail to realise that there is no debate about HTML5 or XHTML2, the answer is HTML5.
In it's current state, XHTML 2.0 is virtually impossible to implement. If they go through with their plan to re-use the XHTML 1.x namespace, it will be totally impossible to implement.
Nothing in XHTML 2.0 is well defined. in fact many things are very much undefined.
XHTML2 changes <script> to <handler>. HTML5 just sticks with <script>
XHTML2 reuses <input> for XForms, without using the XForms namespace (so basicallly, xhtml1:input is being redefined in a backwards incompatible way). HTML5, on the other hand, uses incremental improvement and retains backwards compatibility.
XHTML 2.0 adds <h> for headings, retains the numbered (<h1> to <h6> ) headings, yet fails to define how they interact with regards to the structure of the document. HTML5, on the other hand, retains the numbered headings, yets adds the same functionality as XHTML2 in a much more well defined way.
XHTML2 adds href, and other attributes, to almost every element. Browser vendors have reported that this would be extremely difficult to implement, and probably won't be.
XHTML2 fails to define any error handling, beyond the draconian handling of XML. Error handling needs to deal with more than just syntax errors! e.g. bogus attributes or incorrect values, unknown/unexpected elements, etc.
HTML5 already has many features implemented in major browsers. XHTML2 is not, and will not be, implemented by any major browser.
Basically, HTML5 can do everything that XHTML2 can do, and much more.
Again, I really appreciate this discussion and the great input. Thank you!
xhtml2 offers much more for the future. Mainly exactly because it is not backwards compatible. But then if you see that the most used browser in the real world does not even understand xhtml1.0 you can be sure that html5 will be adopted sooner. And indeed it has some nice features. And so why not?
This is somewhat similar to microformats (aka lightweight semantic web) vs. rdf: One is at hand now and usable now but limited, the other is very very promising but it is future.
But then, one day this future will be the current day and today will be past and forgotten. So basically we need both: What we can have and use now, we should use now, but without letting the real future out of sight.
The HTML5 FAQ should recommend a route away from the current tag soup chaos. I was really worried that this was not a goal any more (considering the negative tone about XML). The following blog entry partly allayed my fears: http://blog.whatwg.org/html-vs-xhtml
Still, the HTML5 FAQ should make it clear that having easily parsable (X)HTML is still a long-term goal.
As for microformats: I really like RDFa as a longer-term (and much more extensible) alternative.
Thanks for your comments!
German readers, there is an revised and improved German translation available now.
You're right, Robert, it's a nice article 🙂
I have a question that I hope will be answered soon. I have an idea for the most incredible website and since I am still technichally challenged, I need to have feedback from those of you that have the experince and knowledge to coach me through the process of creating my delicious website.Of course the extreme adult content I have planned has been the reason I am seeking your input. Thank you
[…] HTML 5 or XHTML 2? Posted in Technology, Developing, HTML/XHTML | Share your thoughts […]
For those of you complaining about the ad industry, don't worry. s is being dropped in favor of . Object can include any type of content, including Flash or TagSoupML in an XHTML2 document.
For those of you complaining about the ad industry, don't worry. iframes is being dropped in favor of object. Object can include any type of content, including Flash or TagSoupML in an XHTML2 document.
I'm not a fan of the way (X)HTML5 is being designed. If it is served as HTML, the document is HTML5, but if it is served as XML or XHTML, then the document is (X)HTML5. What I don't like is the fact that an (X)HTML5 parser will be required rather than a normal XML parser. It defeats the purpose of using XML, IMHO. This fact alone causes a fundamental problem – DOCTYPEs will be used for more than switching browsers into standards mode still, a problem that (X)HTML5 is supposed to be able to solve. How else would a browser (or any user agent, for that matter) distinguish between XHTML 1.0, (X)HTML5, HTML 4.01, etc. to figure out which markup parser to use?
XHTML 2.0 is rather nice. I've been behind it 100% ever since I found out about it.
I may be missing the point of (X)HTML5, but it doesn't seem nearly as useful as XHTML 2.0. In addition, (X)HTML5 introduces elements specifically for presentation (canvas, audio, video), something that was supposed to disappear thanks to XHTML, especially XHTML 1.1 and XHTML 2.0.
In most ways, I agree with Dustin. XHTML 2.0 is the proper move forward. If there are some things from the HTML 5 spec that are worth while, bring them over to XHTML 2 (like the dialog tag).
However, that said, I actually think the best approach would be to use Modularization for everything. Rather than just remove current style forms, allow the use of an XHTML 5 Forms module, along with a core XHTML 2.0 module. Namespaces should be supported everywhere.
The whole "keep XML off the web" part is the biggest mistake I've ever seen. We should be keeping TagSoup off the web, and focusing on moving entirely to an XML-based web.
With XML Namespaces and other such technologies, content authors should be able to pick which models they use. The two places where this is most important is having support for existing style Forms, and scripts. Allowing every tag to have an href and src attribute is a welcome change, blowing away the presentation-specific tags is a welcome change. I do like the HTML 5 forms, as XForms seem overly complex for simple pages. XForms and XML Events should be optional modules, with XHTML 5 Forms and Scripts support available as well.
So I guess what I'm really recommending, is taking the good stuff from HTML 5, adding better Namespace handling, and releasing XHTML 2 as a fully modular markup language. Continuing to support Tag Soup style HTML is stupid, please let it die!
HTML 5 and XHTML should work hand-in-hand.
I mean that like they should be treated as completely separate coding languages. The added attributes and tags in HTML 5 should also be added to XHTML. Both should be well-formed, just that HTML 5 documents should be coded using the SGML format, while XHTML pages use the XML format.
That's pretty much it.
So I’ve been learning a bit about the HTML5 canvas element as supported in the latest milestones for Firefox, Chrome and Opera, and how to use JS with it to make a simple 2D painting canvas.
It certainly got my attention with how simple it is to use with JS – but I was disappointed to learn that, in Chrome at least, the width and height of the element must be set using presentational tag attributes for it to work properly. Strangely enough, when I tried using CSS for the width and height of the canvas element itself and/or a container div, a border was applied correctly but the actual drawing routines were messed up. Somehow, it seems that to alter the co-ordinates passed to the JS drawing functions via the clientX/Y or offsetX/Y properties of the mousemove event object, so the ‘virtual ink’ is drawn at an offset to the actual location of the cursor.
This seems rather backwards if it is actually part of the specification, when for years we’ve been told to abolish presentional markup wherever possible!
Finally, I love the simplicity of the new DTD, even if it doesn’t specify the HTML version which may become problematic if later versions do introduce conflicts despite best efforts… It’s such a relief to be able to just type in <!DOCTYPE html> rather than having to copy and paste one of those long, ungainly relics of ancient SGML syntax. I mean, I only recently discovered that the entire purpose of the ‘-‘ character in the ludicrous ‘-//DTD html blah…’ is supposed to indicate that the DTD came from an organisation ‘that is not registered with the IETF’ – with a ‘+’ meaning the opposite. But it’s 2009 and I can’t remember ever seeing such a doctype declaration with a ‘+’ in it! I was also amazed that the W3C itself, trickling out a steady stream of misunderstood and badly followed doctype definitions for all those years, does not qualify as a ‘registered’ entity in that sense… Made me laugh though. Can’t we get rid of DTDs altogether, at least in XML subsets? To me, it seems that the XML prologue is all that’s needed to inform an ‘agent’ that the document is indeed XML, and the presence of a top-level <html> or <svg> tag (perhaps with a versioned namespace specifier instead of a static 1999 one) could then clarify things… That would change the inner workings of the beast quite substantially though, I suppose. But that’s my point: It’s too arcane!
Here is the simplest way how to understand transit form xHTML 2 to HTML 5.
It will be easier, because it's a painted comic strip:
But your attitude to this topic is clear for me.
xHTML 2 is dead! http://www.w3.org/News/2009#item119 HTML5 will be the super hero.