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

Re: Request for Volunteers: Polyglot spec

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 22 Apr 2010 21:34:35 -0400
Message-ID: <4BD0F92B.4030407@intertwingly.net>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
CC: Tony Ross <tross@microsoft.com>, 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>
On 04/22/2010 09:06 PM, Leif Halvard Silli wrote:
> 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.



My take (non-chair, etc): Leif, what you are proposing doesn't make the 
rules more identical.  There are a few cases (like <li> and <td>) where 
empty element syntax does no harm: namely because the only valid tags 
that can follow are ones that would implicitly close the element in 
question.  But there are many more elements, such as <i> and <b>, are 
ones where <i/> and <b/> would most likely cause behavior that is 
decidely unexpected.

- Sam Ruby
Received on Friday, 23 April 2010 01:35:15 UTC

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