Re: Selectors, getElementsByTagName() and camelCase SVG

On Apr 2, 2009, at 18:08, Boris Zbarsky wrote:

> Henri Sivonen wrote:
>> 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.

Would selectors then by compiled with dual atoms and nsContentList  
created with dual matching atoms instead of putting dual atoms on node  
infos? So that each selector and nsContentList would have an original- 
case atom for matching against non-HTML nodes and a lower-cased atom  
for matching against HTML nodes? (It seems that without dual atoms on  
the other side, approach #3 is insufficient to make camelCase SVG work  
by pointer comparison.)

> Is there a reason to not take approach 3?

  * It's a difference from current Gecko, WebKit and Opera behavior.
  * Unless done on the XML side as well, it would introduce a new  
difference between text/html and XML DOMs instead of reducing the  
differences.
  * It would introduce a new difference between the Web DOM and the  
W3C DOM.
  * It would violate the principle that the *NS methods give true red- 
pill access to the content tree.
  * A close approximation of the outcome (if I guessed your intent  
correctly) could be achieved with a spec change with fewer  
implementation changes if it were stipulated in a spec that selectors  
don't match case-insensitively against HTML nodes but match against  
HTML nodes after the selector ident has been ASCII-lowercased.

That said, I don't think that the ability to pass ASCII upper case  
characters to createElementNS in the second argument when the first  
argument is "http://www.w3.org/1999/xhtml" is ever useful for Web  
authors.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 3 April 2009 06:51:37 UTC