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

a) authors create multiply namespaced documents, so they need a way to
reliably traverse those documents (either with namespace support or
not)
b) svg links support attributes that xhtml links (i mean xhtml2 links,
ie any element with a href) do not: modifying those attributes is a
use case (for example to disable them and to create a little popup,
like GMail in editing mode does)
the same applies obviously for any element: different elements need a
way to be selected differently.
Reasons may be various: if I want to submit xform using xhr, I must
differentiate between html select and xforms select (this is a
concrete use case). If I want to imperatively animate xhtml links (to
do something more complex than declarative animations and to avoid
putting any element in a dedicated svg) i need to fetch all links
(*[href]) in the xhtml namespaces.

Even if there weren't use case (but there are), we should not
constrain the features of language. Newer authors, with newer ideas
and newer languages, will thank us if we put namespace support in
selectors API.

Giovanni

2009/1/28 Anne van Kesteren <annevk@opera.com>:
> On Wed, 28 Jan 2009 15:28:42 +0100, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>>
>> @Anne:
>> well, assuming that an author will need to match elements across
>> multiple namespaces, it will be easier to use XPath (that also is
>> compatible across multiple browsers) than to use horrible workarounds
>> like "svg :not(foreignObject) *[href]" (all svg links) or "svg
>> not(timesheet) animation" (all SVG but not SMIL animations), or
>> "select[bind], select[ref]" (xforms selects)
>> I think that those example are even easier to rewrite as
>> "svg|*[href]", "svg|animation", "xforms|select", provided a reliable
>> namespace binding mechanisms (the one I proposed)
>
> Well, a) that's quite an assumption which needs to be elaborated on somehow
> and b) those are indeed examples of things you can select easier with
> namespace support but it is not at all clear why you want to do such a thing
> in the first place. I.e. they are not use cases.
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>

Received on Wednesday, 28 January 2009 15:05:23 UTC