- From: Sam Ruby <rubys@intertwingly.net>
- Date: Thu, 22 Apr 2010 21:34:35 -0400
- 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. Consider: http://tinyurl.com/244esft 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