- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 02 Apr 2009 11:08:04 -0400
- 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? -Boris
Received on Thursday, 2 April 2009 15:17:08 UTC