W3C home > Mailing lists > Public > public-html@w3.org > November 2012

Re: Statement why the Polyglot doc should be informative

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 9 Nov 2012 18:10:44 +0100
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-html WG <public-html@w3.org>
Message-ID: <20121109181044498547.47e42a42@xn--mlform-iua.no>
Henri Sivonen, Fri, 9 Nov 2012 16:22:25 +0200:
> On Fri, Nov 9, 2012 at 3:52 PM, Leif Halvard Silli wrote:
>> Feel free to explain why that is a sign of "confusion".
> I’m not sure what I can explain if you don’t recognize the claim that
> Polyglot gives you better structure as being obviously bogus.

I was thinking that polyglot would prevent you from doing e.g. 
<p><table/></p>, but then Validator.nu told me that such nesting is 
also forbidden per the rules for XHTML5 (and this despite that that 
HTML5’s motivation for that restriction is "peculiarities of the 
parser", see the spec 
). Thus, it would not be conforming to do that anyhow, not even per the 
conformance rules for XHTML5. So I "you are right", in that case.

But "better" is a very unspecific word. I don't quite see how you come 
to such a conclusive conclusion. Some of the requirements that polyglot 
markup sets, leads to "better structure" for the *XHTML* serialization. 
For instance, you don't have to include <tbody> in XHTML5, but you must 
do so in polyglot markup. The fact that the XML declaration is 
forbidden is, I would argue, very good for XML tools and parsers, as it 
encourages them to drop it entirely = more HTML5-conforming. 

Other requirements, like those on <style> and <script>, encourages use 
of external scripts/css - a well recognized best practice. 

The structure is also "better" in the sense that the author can freely 
use the result as either HTML or XHTML. And an authoring tool would not 
need more than a single serialization if using polyglot syntax = 

>> Is there a concrete reason to mention libxml2?
> If you don’t mention which particular software hoops are for, people
> will continue jumping through the hoops long after it’s no longer
> relevant. Consider the requirement of Appendix C to have a space
> before />, which was motivated by Netscape 3 or IE 3. (I don’t even
> remember which at this point!)

You mean that if one had marketed it as "Netscape 3-compatible HTML 
with XHTML-syntax", then one would have stopped adding the space once 
Netscape 3 was irrelevant. That could be. And going after specific 
parsers and authoring tools is a possibility. One could try to keep a 
list of where it is useful ...  

HTML5 is designed to be "serializable as XML 1.0". That's a good. But I 
have found that *being* valid XML 1.0 syntax, often is helpful when 
trying to work out solutions that are legacy-compatible. It simply is a 
useful and practical way of thinking and authoring.
leif halvard silli
Received on Friday, 9 November 2012 17:11:21 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:58 UTC