W3C home > Mailing lists > Public > www-html@w3.org > January 2009

Re: HTML 5 and XHTML 2 combined

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Wed, 7 Jan 2009 22:13:23 +0000
Message-ID: <ed77aa9f0901071413m79140e4jd0d8f1c4453032dc@mail.gmail.com>
To: "Benjamin Hawkes-Lewis" <bhawkeslewis@googlemail.com>
Cc: "Brett Patterson" <inspiron.pattersonb@gmail.com>, "David Woolley" <forums@david-woolley.me.uk>, Molte <molte93@gmail.com>, "Shavkat Karimov" <shavkat@seomanager.com>, "HTML Working Group Discussion Mailing-List" <www-html@w3.org>

Hi Benjamin,

I have a couple of comments on some of the misconceptions that have arisen.

> 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.

A mark-up language and a MIME type are distinct things. Many
organisations choose to generate documents that are technically XHTML,
but deliver them to browsers using an HTML MIME type, so as to 'force'
the browser to use its HTML parser for rendering.

This gives them the best of both worlds; they can use one or more of
the enormous number of XML tools around to generate their documents,
but they can still have these documents rendered in existing browsers,
without having to worry about whether the browser supports XHTML or
not.

The important thing here is that this technique also means that in
principle, even if a 'new' language is created, it could still be
processed by existing browsers, provided that the new language paid
attention to HTML processing rules.

So XHTML 2 could be delivered with an HTML MIME type, just as HTML5
could be delivered with an XHTML MIME type -- in both cases the
languages are distinct from the delivery mechanism.

Obviously that says nothing about which language is 'better' -- it
simply says that either language could stake a claim to backwards
compatibility, provided that it was careful about how it approached
the question of new features.


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

I think this is a little misleading.

First, HTML5 adds new features that are not backwards-compatible with
HTML 4, but it just so happens that the close relationship between
some of the browser implementers and the spec writers mean that
features are being added quite quickly. In effect, the 'existing web'
is changing, even as we discuss it.

Second, XHTML 2 is not based on ignoring those constraints, although
it would probably be true to say that it was at its inception. For a
long time now XHTML 2 has had a modular architecture, which means that
language designers can create languages that use one or more of the
XHTML 2 modules, and implementers can provide support for whichever
modules they deem appropriate. This makes XHTML 2 useful not just in
browsers and constrained devices, but also for creating Docbook-style
languages, news formats, and so on.

Best regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Wednesday, 7 January 2009 22:14:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:15 GMT