W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Namespaces and tag names in the HTML parser

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 1 Aug 2013 22:27:37 +0000 (UTC)
To: Peter Occil <poccil14@gmail.com>
Message-ID: <alpine.DEB.2.00.1308012128220.27623@ps20323.dreamhostps.com>
Cc: WHATWG <whatwg@whatwg.org>
On Thu, 1 Aug 2013, Peter Occil wrote:
> 
> - "Let the current column be the first col element child of the colgroup 
> element" is not considered ambiguous because the "colgroup element" 
> mentioned is understood to be "the colgroup element in question" (see 
> the beginning of the step: "If the current element is a colgroup, follow 
> these substeps:").  On the other hand, the phrase "While the node is a 
> so-and-so element, etc." (and the patterns mentioned in my earlier 
> message) is ambiguous because it is not known beforehand what kind of 
> element is involved.  (Also, ambiguity issues involving "the first col 
> element child" are moot because, as far as I can tell, an element named 
> "col" in a namespace other than HTML can't be a direct child of an HTML 
> "colgroup" element.)

Oh it's easy to end up with non-HTML elements in such places:

   var cg = document.createElement('colgroup');
   var c = document.createElementNS('http://example.com/', 'col');
   cg.appendChild(c);


> - The tree construction stage is more generic than other HTML algorithms 
> with respect to namespaces, while most of the rest of the spec deals 
> exclusively with the HTML namespace, making confusion much less likely.

I think it's a mistake to look at the spec this way. As shown above, it's 
easy for non-HTML namespaces to end up in the middle of HTML elements, and 
processing models have to take that into account. When the spec says "the 
first col element child", it has to be an HTML <col> element. Same in the 
parser. There's no difference.

My main concern is that being triply-explicit (we're already doubly 
explicit, given the text in the intro that says this, and the hyperlinks 
from each occurrence of an element name in the parser to the element's 
definition) will make people start wondering why we're explicit in some 
places but not others, and they'll assume there's some meaningful 
difference, and then they'll start making mistakes because of it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 1 August 2013 22:28:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC