Re: HTML5 and XHTML2 combined (a new approach)

On 21/1/09 20:30, Giovanni Campagna wrote:
> The biggest advantage of XHTML1.1/2 is modularization

Is it?

How does modularization of XHTML help content producers, user agent 
developers, or end-users in practice?

Has it ever helped you?

How would modularization of XHTML help achieve the stated goals of the 

I've yet to be persuaded that modularization of XHTML actually works or 
that, if it did work, it would make the Web better.

The core idea of modularization, as far as I can gather, was that user 
agent developers could declare the modules they support and that content 
producers could match their content to that support profile:

Whether this sort of fragmentation of the Web is remotely desirable is 
open to debate; personally I want access to _the_ Web on my phone (and 
my TV and my fridge and my cyborg cat), not lots of little walled garden 

But in any case, when people actually try to use those modules, they 
seem to find they cannot declare a profile in terms of the because it's 
rather difficult to carve up XHTML features into useful groups.

The Open Mobile Alliance defined a profile of XHTML for mobile devices 
that included various XHTML modules. But we find this statement in their 

"The XHTML Mobile Profile document type could also serve as a host 
language, that is, a language containing a mix of vocabularies within 
one document type. Those considering its use as a host language should 
consider that it is not strictly XHTML Host Language Conforming, as it 
only partially includes three modules."

OMA wanted XHTML MP to include "start" and "value" out of the Legacy 
module, "b", "big", "hr", "i", and "small" out of the Presentation 
module, and "fieldset" and "optgroup" out of the Forms module.

Isn't a lesson to be drawn that language designers are going to 
cherrypick features not modules, and that, if they are going to do that, 
they are going to need to declare what features they support rather than 
what modules?

> "Another serialization for XHTML" that defines a
> processing model (maybe based on real SGML)

If it was based on real SGML then it wouldn't be useful for processing 
the existing text/html web corpus, and it wouldn't be implemented by 
popular user agents.

> This way we can allow modularization and extensiblity (since content
> model and start/end tag handling are not defined in the same
> specification), although we may need to get DTDs back.

How does defining the content models of elements in one document and the 
implied opening/closing tags of the same elements in another document 
allow "modularization and extensibility" in a way that defining them in 
same document does not?

> All the rest of HTML5 (DOM3 HTML - Scripting Execution Contexts -
> Persistent Storage API - Advanced Network Communications API) are in
> scope of WebApplications WG, and many people inside and outside the HTML
> WG would rather have them separated.

Many people certainly would. Indeed HTML WG/WHATWG are taking steps to 
spin some of HTML5's tangle out into other specifications. For example, 
Hixie has submitted Web Sockets as an IETF RFC:

However, what is needed is not people saying these components should be 
in separate documents but people capable and willing to edit those 
documents. It's not like people are very actively editing the Web 
Applications drafts at the moment.

> In conclusion, the only way to get XHTML widely deployed and implemented
> (and thus to reach PR) is to get rid of HTML5. Start working immediately
> at the XHTML WebApps module, before it's too late.

This still seems like a proposal to turn XHTML 2 _into_ HTML5, without 
any attempt to gauge whether that meets the stated goals of XHTML 2. In 
particular, the emphasis on web applications seems at odds with XHTML 
2's emphasis on documents.

Benjamin Hawkes-Lewis

Received on Wednesday, 21 January 2009 23:39:08 UTC