W3C home > Mailing lists > Public > spec-prod@w3.org > July to September 2011

Re: Publication of specifications as HTML5

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 19 Aug 2011 18:59:27 +0200
To: David Carlisle <davidc@nag.co.uk>
Cc: spec-prod@w3.org
Message-ID: <20110819185927782706.9d0620ef@xn--mlform-iua.no>
David Carlisle, Fri, 19 Aug 2011 15:41:55 +0100:
> On 19/08/2011 15:09, Leif Halvard Silli wrote:
>> Thus, with Polyglot Markup you*could*  use inline mathml and svg.

> If there is a requirement to support browsers that don't do mathml or
> svg or canvas or dir=auto or.... then we need to omit those features (or
> specify exactly how fallback is supposed to work) for normative
> documents.
> The question about whether to use xml or html5 syntax for the
> features that are allowed may come up, but it is less important

You say "syntax". Do you really mean MIME type?

IMO, the question of whether to serve as application/xhtml+xml and/or 
text/html should be seen as an integral part of the question about 
which legacy browser - and whether - to support legacy browsers.

Because, legacy IE is not the only legacy browser for which support 
should be considered: Firefox before version 4 (?) has problems with 
unknown HTML elements - as mentioned in the WHATwg blog once, the 
problem is solved by serving as XML. Likewise, when it comes to SVG, 
then legacy support is old, as long as the page is served as XML.

So: Just as legacy version of IE needs - as Rich pointed out - 
JavaScript to support HTML5, other legacy browsers needs 
application/xhtml+xml in order to support the features you had in mind 
- SVG and MathML - and even HTML5 itself.

One should define:

  1. A feature level (taking into account the possibilities,
     including application/xhtml+xml)
  2. Which strategies are REQUIRED to follow to make as many
     browsers as possible support that feature level
  3. Optional strategies, to support even more browsers.

> as it's
> fairly trivial for anyone processing a document to serialise an html
> document as xml or an xml document as html, but if examples are in
> mathml or canvas or assume full bidi processing, then the document is
> pretty hard to read using a browser without those features.

Well, what the browser supports, partly depends on how the document is 
delivered. So I can't see that serialization can be separated from the 
feature question.
Leif H Silli
Received on Friday, 19 August 2011 16:59:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:16 UTC