- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 24 Apr 2010 03:29:09 +0200
- To: Sam Ruby <rubys@intertwingly.net>
- 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>
Leif Halvard Silli, Sat, 24 Apr 2010 03:12:12 +0200: > Sam Ruby, Thu, 22 Apr 2010 21:34:35 -0400: >> 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 > > Which had this code: <p/><b>...</b> > >> 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. > > I am sorry to have explained myself badly - or in to many words. > Because, that code example would *not* be a valid polyglot example by > the definition I tried to express. E.g. for <p/>, then I said: [1] > >> a minimized <p /> must be immediately followed by the end tag >> of its parent tag. [substitute/parent tag/parent element/] > [ or be ] >> immediately followed by another 'p' element. > > Thus, in the hypothetical situation that it had been valid to wrap a > <p/> inside a <b>, then, this *would* have been valid: > <b><p/></b>. But not this: <b/><p/>. And not this: <p/><b/>. > > And when you mention elements like <li/><li/>, then you are in fact > using the same principle as I did when I said that a <p></p> > immediately preceded by a minimized <p/> (aka: <p/><p></p>), should be > valid. And as for <i/> or a <b/> and other inline elements, then I think you are right that there are problems. I though that something like this could work: <div><b/></div> However, it appears to be interpreted like this, in Webkit at least: <div><b></b></div> <b></b> So, yes, for inline elements, then it seems like the minimized syntax has to be entirely forbidden. > [1] http://lists.w3.org/Archives/Public/public-html/2010Apr/1102 -- leif halvard silli
Received on Saturday, 24 April 2010 01:29:46 UTC