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/
