Re: Selectors, getElementsByTagName() and camelCase SVG

Henri Sivonen wrote:
> It seems that getElementsByTagName() invoked on a non-HTML node (e.g. 
> SVG node) is specced to compare case-sensitively even into 
> <foreignObject> subtrees.

Yeah, that's not an issue, I don't think.  When getElementsByTagName is 
called on a non-HTML node in Gecko currently, the passed-in string is 
interned as-is, without lowercasing.  This gives immediate 
case-sensitive matching when comparing interned strings.

> This 'correct' approach would 
> only help with the kind of non-conforming cases that only Opera now 
> supports spec-wise correctly (ASCII upper case introduced to the tree 
> via createElementNS()).

Ah, I see what you mean.  The spec calls for these to be treated as 
"HTML elements" in an "HTML document" and to be matched 
case-insensitively, so if an element is created via:

   createElementNS(xhtml_ns, "HEAD")

it should be in the result set for getElementsByTagName("head").  This 
is indeed an annoyance.  I can see how the spec ends up here, in its 
insistence that the namespace is the only thing that identifies HTML 
nodes....  Right now in Gecko that node would not end up in that list.

I think there are three obvious options here:

1)  What the spec currently has.
2)  What Gecko/Webkit currently do.
3)  Having createElementNS(xhtml_ns, str) ascii-lowercase str in HTML
     (but not XHTML, of course) documents, then do what Gecko/Webkit
     currently do.

Is there a reason to not take approach 3?

-Boris

Received on Thursday, 2 April 2009 15:17:08 UTC