W3C home > Mailing lists > Public > public-html@w3.org > April 2010

RE: Request for Volunteers: Polyglot spec

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 23 Apr 2010 03:06:35 +0200
To: Tony Ross <tross@microsoft.com>
Cc: Sam Ruby <rubys@intertwingly.net>, Eliot Graff <eliotgra@microsoft.com>, Adrian Bateman <adrianba@microsoft.com>, "public-html@w3.org" <public-html@w3.org>, "tag@w3.org" <tag@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, "mjs@apple.com" <mjs@apple.com>, "plh@w3.org" <plh@w3.org>
Message-ID: <20100423030635881594.11498e3a@xn--mlform-iua.no>
Tony Ross, Thu, 22 Apr 2010 22:48:27 +0000:
> On Wednesday, April 21, 2010 9:26 PM, Leif Halvard Silli wrote:
>> PS: I hope that technical limitations rather than "this is simpler 
>> for authors"
>> will guide the speccing of this spec. It should define a common denominator
>> for HTML5 and XHTMl5. But not anything more strict than that. E.g. I would
>> like to know when I can use a minimized '<p />'
>> *and* get the same DOM in both XHTML and HTML, rather than having a
>> "simple" rule which requires me to *always*  avoid the minimized <p />.
> While sometimes the differences between HTML and XML parsers can 
> result in islands of common ground, I find emphasizing a path that 
> makes writing polyglot simpler for authors more useful. Why does 
> someone really need to know the corner cases where they can use a 
> minimized '<p />' if '<p></p>' works everywhere?

Because as I exemplified in the rest of that message, we can then have 
more identical rules throughout, to the very issue. We can apply a 
similar principle to more elements. To HTML5 void elements, to new void 
elements etc. 

And, also,: if we want polyglot authoring to have an impact on 
'text/html', so that 'text/html' itself moves towards a more XHTML-like 
regularity, in the long run, then we should work towards permission to 
use any syntax which isn't known to create problems in 'text/html'. 

I think a new language/terminology may be needed to express the these 
things ... Because, clearly the start tag '<img>' and the minimized tag 
'<p/>' are not different. Yet, they would some of the same requirements 
about not placing any content between itself and the next tag.

> Ultimately I recognize the balance between simplicity and complexity 
> is a bit case-by-case and sometimes a deeper explanation is needed to 
> enable less common use cases. I just don't see such a use case for 
> the example you provided.

One might ask: What is the use case even for "<p><p>" in _text/html_? 
Two empty <p> elements?  And for minimized tag syntax in XHTML, in 
general, for block elements? 

We should not mistake 'strict' and 'regular'. 'Regular' does not need 
to mean 'square'.  A participant in the Validator mailinglist recently 
presented her XHTML converted web iste to the list. [1] Checking the 
page, I found that it used '</param>' instead of '<param />'. [1]  Is 
that *useful*? Should it be invalidated by the polyglot spec? Why? 
Because HTML5 itself currently forbids it?

Currently I can visit < 
http://validator.w3.org/#validate_by_input+with_options > and type in 
"<p/>" and then click "XHTML 1" under the "Validate HTML fragment" 
pop-up menu. And validate. Why should a validator based on the polyglot 
spec not allow me to do the same?

Sam not long ago pointed to the middle ground between describing a 
polyglot spec as impossible (he had a link to a page at www.whatwg.org) 
and simpler than reality guideline (Appendix C).  But Appendix C is 
both simpler and more complex than reality.

The problem with Appendix C is that isn't accurate. E.g. it says that 
you should leave space between '<br' and '/>'. But why do we need to 
correct that? After all, what is the use case for writing <br/> instead 
of <br />? Saving space? Saving typing? I guess that is why I want to 
write <p/> as well.  

I am sceptical if the polyglot spec becomes a "HTML as we wish it had 
been specced, with clear requirements, no exceptions" etc. 

When the polyglot draft speaks about CDATA inside <script>, then it is 
careful to speak about when to use it and when to not use it. I think 
it should talk likewise about '<p/>' and <param></param> as well as 
about other old truths about what is possible and what is not possible 
in 'text/html' and 'xhtml'.

[1] http://lists.w3.org/Archives/Public/www-validator/2010Apr/0057

[2] http://muralsandfauxpainting.com/

leif halvard silli
Received on Friday, 23 April 2010 01:07:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:01 UTC