Re: Selectors, getElementsByTagName() and camelCase SVG

On Apr 3, 2009, at 16:02, Boris Zbarsky wrote:

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

OK. This seems less invasive than putting dual atoms on node infos,  
but it involves doing an HTMLness check in addition to a pointer  
compare.

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

I think matching createElementNS(xhtml_ns,  
"SOMETHING_NOT_IN_LOWERCASE") with either selectors or  
getElementsByTagName() is a non-goal. After all, currently, nodes like  
that are mostly useless in Gecko and WebKit for anything other black- 
box testing of hypotheses about implementation details and can't even  
be created in IE.

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

I considered having dual atoms on the selector side a distinct option  
from #2, but yeah.

More to the point, it's a proposal to remove the case-insensitivity  
fiction from CSS to avoid having plug all the holes in remote corners  
as a matter of principle. OTOH, it isn't particularly nice for the  
spec to constrain where the dual atoms have to live. Perhaps a better  
formulation could be made so that it wouldn't matter for spec  
compliance whether the dual atoms were in the content tree or in the  
compiled selectors.

Gecko and WebKit aren't the only implementations where the  
implementation details of pseudo-case-insensitivity haven't been fully  
papered over if you poke at the right places. Opera 10 has interesting  
behavior, too:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/59
vs.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/60

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

I don't want it to affect perf or dictate implementation policy. I'm  
just OK with leaving the fact that selectors don't really case-fold  
while matching detectable in edge cases.

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

Received on Friday, 3 April 2009 13:34:36 UTC