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

Alex Russell wrote:
>     5.) we tell them to go script themselves instead of exposing an 
> intrinsic property of tags to the extant selector syntax

Note that there _was_ an attempt to allow a prefix-to-namespace mapping 
setup.  As far as I can tell, it failed at getting standardized, because 
no one ever managed to propose a way to do it that:

1)  People considered adequate for the purpose of actually mapping the
     sort of prefixes that they needed t map.
2)  Didn't have security issues.
3)  Didn't have all sorts of undefined behavior in corner cases.

For what it's worth, the initial Gecko implementation did include a 
namespace resolution mechanism, but it worked by basically doing the 
thing that was easy for Gecko in said corner cases.  I'm pretty sure it 
hit points #1 and #2 above.

To make progress here what's needed is not complaining about the 
imperfection of the world (it's imperfect; we all agree) but a concrete 
proposal for a concrete prefix-to-namespace mapping approach.  This 
would need to address the three points above, as well as whatever other 
issues were raised against the initial NSResolver proposal.  I assume 
you've read those threads, yes?

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

Can you give an example of a "meaningful way" to mix SVG and HTML and a 
set of nodes to be selected along with a reasonable justification for 
why one would want to select those particular nodes, which is unworkable 
with the current API?  It really helps to have use cases in mind when 
designing functionality.

-Boris

Received on Tuesday, 27 January 2009 17:45:57 UTC