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

So to recap:

	1.) someone made a mistake by allowing namespaces in XML
	2.) SVG makes heavy use of this feature as a way to specify many  
intrinsic operations for which HTML simply adds "local" tags (e.g.,  
links)
	3.) well intentioned attempts to unify the platform say "hey! lets  
get everyone using the same (good enough) query language!"
	4.) the SVG world points out their heavy reliance on XML features
	5.) we tell them to go script themselves instead of exposing an  
intrinsic property of tags to the extant selector syntax

I really do loathe namespaces, but is the selectors API actually going  
to be this impoverished? If so, I fear it will prevent the actual  
mixing of SVG and HTML in meaningful ways.

Regards

On Jan 26, 2009, at 3:38 PM, Lachlan Hunt wrote:

> Alex Russell wrote:
>> On Jan 26, 2009, at 1:49 PM, Lachlan Hunt wrote:
>>> Alex Russell wrote:
>>>> Can this be represented in a :not() clause somehow? Foisting more  
>>>> work onto script is the wrong answer.
>>>
>>> No.
>> How about "not yet"?
>
> The answer is still no given that it's not possible to do as you ask  
> with this version of the API.
>
>> Needing to do this filtering in script is clearly a spec bug. QSA  
>> is already littered with them, but an inability to filter an  
>> intrinsic property of a tag in the query language that's native to  
>> the platform is tactable.
>
> Namespace resolution was intentionally removed from this spec,  
> mostly due to the lack of compelling use cases.  The vast majority  
> of use cases can be performed without need for namespace prefixes at  
> all.
>
>> We just need to invent a pseudo-property for elements which can be  
>> matched by a ":not([someProperty=<your_ns_here>])".
>
> Selectors already has a namespace prefix syntax available.  The  
> issue is that there is no method for declaring the prefixes in this  
> version of the API.  Introducing a new selector is not the right  
> solution to this problem.
>
>>> The SVG WG explicitly requested an example illustrating how to  
>>> filter elements based on the namespace URI that works in the  
>>> general case, given that there is no longer a namespace prefix  
>>> resolution mechanism supported in this version of the API.
>> So they obliquely pointed out a spec bug.
>
> That depends if you consider the lack of support for namespaces to  
> be a bug or a feature.  But, as I said, the decision to exclude it  
> was intentional.  The bugs with the namespace resolution mechanism  
> was taking up ~90% of the spec development time, while solving only  
> a small percentage of the use cases.  The cost-benefit ratio wasn't  
> worth it for this version of the spec.  The issue will be re- 
> evaluated for the next version.
>
>> But SVG is stuck w/ 'em until it can find a way to evolve out of  
>> the XML ooze.
>
> Most tasks can be performed without worrying about namespaces.  The  
> issue only comes up with mixed namespace documents when you want to  
> select one of the few elements that share the same local name in  
> both HTML and SVG and using descendant combinator, as in "svg video"  
> or "svg a", is insufficient.
>
> -- 
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/

Received on Tuesday, 27 January 2009 17:14:01 UTC