[whatwg] [html5] DI element
mattraymond at earthlink.net
Sat Mar 12 04:33:18 PST 2005
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
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.
More information about the whatwg