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

Re: Selectors, getElementsByTagName() and camelCase SVG

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 02 Apr 2009 11:08:04 -0400
Message-ID: <49D4D4D4.1040109@mit.edu>
To: Henri Sivonen <hsivonen@iki.fi>
CC: HTML WG <public-html@w3.org>, www-svg <www-svg@w3.org>
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?

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:44 UTC