- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 23 Aug 2011 01:05:53 +0200
- To: Aryeh Gregor <ayg@aryeh.name>
- Cc: Ian Jacobs <ij@w3.org>, David Carlisle <davidc@nag.co.uk>, Richard Ishida <ishida@w3.org>, Karl Dubost <karl+w3c@la-grange.net>, Doug Schepers <schepers@w3.org>, Spec Prod <spec-prod@w3.org>, Philippe Le Hegaret <plh@w3.org>
Aryeh Gregor, Sun, 21 Aug 2011 19:12:36 -0400: > On Fri, Aug 19, 2011 at 2:11 PM, Leif Halvard Silli wrote: > >> Can't see that this rules out 'application/xhtml+xml' - on the contrary. > > I'm not ruling anything out. All I'm saying is it should be fine for > W3C specifications to be non-well-formed HTML5, served as text/html. Btw, the HTML4 spec - does it close all its <p> elements etc ? > If some editors or Working Groups want their specifications to be in > other formats, that's fine too, as long as they're some type of > standard(s-track) HTML and can be processed by a sufficiently broad > range of user agents. If the SVG WG were to decide that they want to > include inline SVG in examples in their spec and serve it as > application/xhtml+xml or text/html depending on UA to get the broadest > possible support, I think that's fine. But that doesn't mean anyone > else needs to serve a well-formed spec to browsers. Not so famiiliar with the pub rules. But it seems it would be smart to define the required format (by which I mean elements) first. And then to define how to make that format broadly accessible. If the purpose of permitting HTML5 markup is only related to the use of the HTML5 doctype, to the better (hopefully) definitions of the old features - but not to allow any new elements or foreign content, then application/xhtml+xml would not be necessary for any browser. >> CDATA is not permitted in polyglot markup. [*] '<' is also not >> permitted. The '&' is also not permitted, so <script><</script> >> naturally is unpermitted. Web browsers that support XHTML shows a fatal >> error if included, so it is easy to discover. (Correction: specificly '<script><</script>' does not cause a fatal error ...) > What this means is that you can't have any inline scripts or styles > that include left angle brackets or ampersands. That's a pretty big > restriction. In your previous reply, you said we """should not be talking about polyglot unless we *really* mean polyglot, rather than just "let's make a text/html-to-XML converter available".""" etc. Did you by that mean to suggest that things like <script>/*<![CDATA[*/</*]]>*/</script> ought to become permitted in Polyglot Markup (and thus in HTMl5 proper too)? or did you simply, both then and now, mean to point out the difficulties? FWIW, polyglot markup is not 100% DOM-equal - such a thing would not be possible without forbidding e.g. xml:lang="". So one could, in principle rule that the DOM difference is acceptable ... Is that what you meant? > You can often work around it, like by using JS or CSS > escapes, but it's not something you can handle automatically. One would then, I guess, have to define a polyglot script escape mechanism? -- Leif H Silli
Received on Monday, 22 August 2011 23:06:37 UTC