Re: Selectors, getElementsByTagName() and camelCase SVG

On 4/2/09, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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?

I really like option 3 here. It makes things very consistent in that
HTML elements in a HTML document are case insensitive through and
through. And HTML element would be defined as any element in xhtml_ns.

/ Jonas

Received on Thursday, 2 April 2009 16:20:46 UTC