Re: [selectors-api] SVG WG Review of Selectors API

On Dec 9, 2008, at 12:46 , Erik Dahlström wrote:
> On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt <lachlan.hunt@lachy.id.au 
> > wrote:
>>> As a compromise, we believe that if the NSResolver support remains
>>> removed from this specification, there should be explicit mention of
>>> workarounds (see below), and an informative note mentioning that  
>>> it may
>>> be readded in a future version of the spec, to ensure that  
>>> implementers
>>> set up their architecture accordingly.
>>
>> There are several features which will be considered for inclusion  
>> in the
>> next version of the spec.  Why should this one in particular be  
>> called
>> out over any other requested feature?
>
> Given that NSResolvers were taken out of the spec it deserves to be  
> called out, and the problem described. Were there any other features  
> that were removed in this LC draft?

I think the important part of the comment is "to ensure that  
implementers set up their architecture accordingly". Now that's a bit  
of a pipe dream in the general case, but there is a specific issue to  
do with this specific situation. See below.

>> Similar functionality was previously requested and rejected for the  
>> xml
>> and xmlns prefixes, and I see no reason to treat the xhtml and svg
>> prefixes any differently.
>>
>> http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html
>
> So essentially Selectors API is a downlevel client[2]?

That's an interesting question. From that section of CSS Selectors (http://www.w3.org/TR/css3-selectors/#downlevel 
):

"down-level client will view and match element type and attribute  
selectors based on their fully qualified name (...). CSS selectors may  
be declared using an escaped colon "\:" to describe the fully  
qualified names, e.g. "html\:h1" will match <html:h1>." And further:  
"Note that selectors declared in this fashion will /only/ match in  
down-level clients." (original emphasis)

So say some service I'm using sends me some piece of DOM containing  
<evil:kitten dahut:type='tamarou'/> and a bunch more of that, with  
proper namespace declarations and all. I'm one sexy hacker and I want  
all them kittens, and the only way that works is:

   var cutesy = document.querySelectorAll("evil\\:kitten");

So that's all fine and good, but now you crazy kids at the browser  
factories decide to ship us a new a wicked cooler Selectors API, that  
supports NSResolver (or something like that). What happens? Does my  
code break suddenly? Or do you detect that I'm not using an NSResolver  
and implement a special branch of the code to emulate dumblevel  
clients? Do you hack your parser so that selectors that match using \:  
match against the QName and the rest use namespaces (and if so what do  
we do with those that have neither \: nor | ?).

 From here it looks like a good plan for a punk rock concert, except  
without the music and without the beer. So if we're not going to have  
the fun stuff, I formally request that the spec be light on the drugs  
and violence, and include a discussion of its strategy to include  
namespace support later without breaking the above case.

>> Please explain how providing a reference to DOM 3 XPath would be of  
>> any
>> benefit?  How would it help readers in their understanding of this  
>> spec?
>
> There are limitations in Selectors API that will force people into  
> either doing workarounds, or to use another technology for the  
> selection.
>
> It seems the SVG WG isn't alone in wanting to have the informative  
> reference to DOM 3 XPath:
> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/ 
> 0451.html
> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/ 
> 0449.html

These two could in fact be tied together into a "Working with  
Namespaces" section. My example above would have been evolution- 
friendly had it used D3XPath instead of hacking around Selectors'  
limitations.

>>> == 8. Examples
>>>
>>> Please add an example such as this one:
>>>
>>> <html xmlns="http://www.w3.org/1999/xhtml">
>>>  <body>
>>>   <svg xmlns="http://www.w3.org/2000/svg">
>>>    <font id="mysvgfont">
>>>     ...
>>>    </font>
>>>   </svg>
>>>   <font face="Arial">Example</font>
>>>   <svg:font id="anothersvgfont" xmlns:svg="http://www.w3.org/2000/svg 
>>> ">
>>>    ...
>>>   </svg:font>
>>>  </body>
>>> </html>
>>>
>>> Then explain how to use the Selectors API to select only the svg  
>>> 'font'
>>> elements and how to select only the svg font elements that have a  
>>> prefix
>>> on the element.
>>
>> As Boris explained, and as I'm sure you're well aware, it is not
>> possible to distinguish between elements with the same local name
>> without using namespaces.  I cannot demonstrate the impossible and  
>> have
>> not included the example in the spec.
>
> The SVG WG disagrees with this reasoning. People will run into this  
> problem, and it seems appropriate to give an example and to show how  
> to work around the lack of namespace-aware selectors. Note that even  
> if it's not possible to distinguish between the elements using  
> Selectors API alone, the result can be filtered e.g using DOM Core  
> methods to give a meaningful result. Another workaround could be to  
> pass a descendant combinator selector such as "svg font" to check  
> the the <font> element has an <svg> element ancestor, this would  
> cover many of the use-cases.
>
> It would also be useful to mention the backslash escaping mechanism  
> for downlevel clients[2].

My thoughts exactly, and again it seems like fodder for the same  
section.

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Tuesday, 9 December 2008 13:05:16 UTC