W3C home > Mailing lists > Public > www-svg@w3.org > January 2009

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Tue, 27 Jan 2009 00:38:32 +0100
Message-ID: <497E4978.70607@lachy.id.au>
To: Alex Russell <alex@dojotoolkit.org>
Cc: Erik Dahlström <ed@opera.com>, Doug Schepers <schepers@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, www-svg <www-svg@w3.org>

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 Monday, 26 January 2009 23:39:12 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:41 GMT