[whatwg] [html5] DI element

[Matthew Raymond]

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.