Re: Selectors, getElementsByTagName() and camelCase SVG

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

Yes, precisely.  I should have made that clearer.

>> 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.

All true.  I'm operating on the assumption that for some reason we 
_want_ to match things created using createElementNS(xhtml_ns, 
"SOMETHING_NOT_IN_LOWERCASE") here and trying to figure out ways that we 
can do that without actually doing case-insensitive matching if at all 
possible...

>  * 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.

This is option 2, no?  That is, the current Gecko behavior (modulo 
changes for the SVG camelCase stuff).

 > 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.

Agreed, which is why I'd like to not have this edge case dictate 
implementation policy and affect performance of the common case to he 
deree that it does with the spec as written.

-Boris

Received on Friday, 3 April 2009 13:02:56 UTC