- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Wed, 7 Jan 2009 22:13:23 +0000
- 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 UTC