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: 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>
Message-ID: <20110823010553601520.f839a12b@xn--mlform-iua.no>
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>&lt;</script>
>> naturally is unpermitted. Web browsers that support XHTML shows a fatal
>> error if included, so it is easy to discover.

(Correction: specificly '<script>&lt;</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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:19:18 GMT