Re: HTML 5 and XHTML 2 combined

On 7/1/09 18:28, Brett Patterson wrote:

>     * Why not use the disadvantages as well?

Because they're _dis_advantages (i.e. bad) and XHTML 2 is intended as a 
next-generation language?

>       They're going to be there whether we like it not, right?

They aren't going to be there in conforming XHTML 2 content, if any ever 
gets produced.

>     * So what if XHTML2 doesn't benefit from importing of the HTML5
>       "cruft," what would be the downside?

A vastly more complex spec without any advantages that you've been able 
to name?

If you want a backwards-compatible language with both text/html and 
application/xhtml+xml serializations, and that can be reconciled with 
the handling of existing web content, then you want HTML5.

If you want a next-generation language with an application/xhtml+xml 
serialization that can specify completely different ways of handling its 
content, even such that browsers would need to fork their code to handle 
it, then you want XHTML 2.

HTML5 is premised on the constraints of supporting the existing web with 
the same specification; XHTML 2 is premised on ignoring those constraints.

These goals aren't reconcilable, so the languages cannot be combined. 
The best you could do is to find use-cases that one language meets but 
the other does not and suggest solutions compatible with the goals of 
that language to the relevant working group.

As the editor of the HTML5 spec noted earlier in the thread: "all the 
advantages of XHTML2 that are not incompatible  with the goals of HTML5 
have already been taken into HTML5".

I don't know if the editors of the XHTML 2 spec would say the reverse is 
true.

If we try to extract the concrete suggestions to the XHTML 2 WG that are 
not based on misconceptions about either spec, we find the following:

1. Drop "img" and "a" in favour of generic mechanisms ("src" and 
"href"). HTML5 can't provide these mechanisms, although it can meet many 
of the same use-cases through nesting inside "object" and "a". From what 
I remember, the rationale given for preserving "img" and "a" in XHTML 2 
was that it would help existing (X)HTML authors adjust to XHTML 2.

2. Add a way to represent the semantic of header and footer, on both a 
page and section level. HTML5 provides this semantic through the 
"header" and "footer" elements. XHTML 2 probably provides this already 
with role="banner" and role="contentinfo" (from the ARIA spec) - except 
it's missing a way to specify a header area for a section rather than a 
page. Possibly you could define your own role with RDF to directly 
approximate HTML5's "header", though that's not exactly author-friendly!

... that's it, as far as I can tell.

I can imagine other requests based on new features in HTML5 but none of 
them have been made in this thread.

--
Benjamin Hawkes-Lewis

Received on Wednesday, 7 January 2009 19:31:24 UTC