- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Sat, 12 Mar 2005 07:33:18 -0500
Ben Meadowcroft wrote: > If we're intent on producing an "HTML 5" specification which introduces > enhancements beyond improving the form controls etc I don't see why we are > debating the content model of DL's etc in this forum? Surely we should > discuss it in the context of XHTML 2.0 and when that is released as a > final recommendation cherry pick the good bits (DLs, sections etc) and > back port them to HTML 5. Actually, the opposite is true. XHTML 2.0 is not backwards compatible, and they therefore can either choose markup that *happens* to be backwards compatible, or they can go with something completely new. HTML5, by contrast, must gracefully degrade into HTML 4.01. Therefore, if we create markup for HTML5, it can easily be incorporated into XHTML 2.0, whereas concepts for XHTML 2.0 may be impossible to port to HTML5 because XHTML 2.0 does not guarantee backwards compatibility. > If XHTML 2.0 becomes adopted in user agents, > like mozilla <https://bugzilla.mozilla.org/show_bug.cgi?id=161463>, surely > it is easier for them to also support HTML 5 if they only have a few > important areas of difference, like the web forms enhancements. As my above comment clearly shows, it is easier for XHTML 2.0 to accommodate HTML5 then the other way around. Just look at forms. Everything related to forms in XHTML 2.0 is done by XForms. HTML 4.01 doesn't even have namespaces. So which is easier, forcing everyone to use XHTML 1.x for HTML5 features and making them use XForms to get new controls for something like a date or time, or just adding new values for the <input> element's |type| attribute? And note that XHTML 2.0 needs only to add an XHTML module to support HTML5 markup. We're already taking things from XHTML 2.0 and seeing if they fit into HTML5. I believe <di> actually comes from XHTML 2.0. However, even if we wait for XHTML 2.0 to be finished, we may not be able to use any of the end result because HTML5 and XHTML 2.0 have fundamentally different design goals. HTML5 aims to extend existing HTML. XHTML 2.0 aims to reinvent HTML entirely. XHTML 2.0 always has the option of being dependent on HTML5 markup and features. The opposite isn't true. > Perhaps we should stop thinking of this as HTML 5 and more as EHTML (for > Enhanced HTML) so we can introduce new version numbering etc. We could > start off with EHTML 1 which introduces the Web Forms stuff, then EHTML 2 > could be released later which back ports XHTML 2's good features (as well > as new web forms stuff). I think this might make evangelising EHTML a bit > easier, it worked for DHTML after all! First of all, DHTML was never an extension of HTML. It was a way of manipulating and HTML document using scripting languages. It was effectively a "proto-DOM". It did not change the HTML DTD, and markup, change the semantics of existing markup, et cetera. "HTML5" directly adds new markup and semantics, and makes changes to existing portions of previous HTML specifications. This is exactly what every version of HTML has done. Therefore, why is a version number not appropriate? Is it because the W3C decided to switch to a different version number when they went to XHTML? They could have easily called it XHTML 4.01. It wouldn't be the first time someone did this. No, they went with 1.0 because they chose to discontinue all development of HTML in favor of XHTML. It never occurred to them that HTML development would continue, so they went with a problematic versioning system. So the bottom line is that going with something other than "HTML5" is nothing more than pandering to influential individuals inside the W3C. It may be to our advantage to do so, but considering the actual specs aren't officially called "HTML5", it really doesn't matter that much. The official name of "HTML5" is effectively WF2+WA1+WC1, so let W3C and others figure out what they want to call it once we're done working on the specs.
Received on Saturday, 12 March 2005 04:33:18 UTC