W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

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

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Wed, 28 Jan 2009 17:31:35 +0100
Message-ID: <65307430901280831g6beb0f73g5dc796c8f76e3c82@mail.gmail.com>
To: public-webapps@w3.org

2009/1/28 Boris Zbarsky <bzbarsky@mit.edu>:
> Giovanni Campagna wrote:
>> 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)
> I should note that that selector doesn't actually work to select things that
> are not inside a foreignObject...  Offhand, I see no way to do that, in
> fact.
Why shouldn't it?

>> 1) discussion of pros and cons of available technologies (don't use
>> functions or objects to avoid infinite loops or recursion, don't use
>> string to avoid syntax problems), it looks that a NSResolver object (a
>> wrapped hash map, not an interface for a js function like
>> XPathNSResolver) is the best solutions
> Would you be willing to expand on why you think that's the best solution?
>  (Maybe it is; I'd just like to know the analysis that led to this
> decision.)
It is the summary of the email Lachlan linked, with pros and cons of
various solutions. The only argument against NSResolver (called
NamespaceResolver in that email) is that we need some new IDL in the
> It would be really nice to make progress here, since I do think that
> namespace support in Selectors API would be quite useful for the SVG case...
> -Boris
It is not only SVG, it is any markup language that may be mixed to
build a compound document.

2009/1/28 Lachlan Hunt <lachlan.hunt@lachy.id.au>:
> Giovanni Campagna wrote:
>> 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)
> The use case should try to answer the following questions.  Try to be as
> specific and realistic as possible, and provide links to real world examples
> if you can.
> Let's go with the first example you gave of selecting all SVG links: "svg
> :not(foreignObject) *[href]".
> Note that the example selector provided won't actually work to select all
> SVG links, at least not in the general case.  The only way that could work
> is like this:
> "svg>:not(foreignObject)>[href],
>  svg>:not(foreignObject)>:not(foreignObject)>[href],
>  svg>:not(foreignObject)>:not(foreignObject)>:not(foreignObject)>[href],
>  ..."
Again I ask the same question I asked to Boris: why "svg
*:not(foreignObject) *[href]" is not supposed to work?
> 1. Why is the author mixing SVG and, presumably, HTML in this case?  I know
> there are use cases for this in general, but we should be specific about
> which.
Because SVG allows for greater presentation than HTML and CSS, but
this greater presentation only applies to a small part of the
document. Or because I have two versions of the same page, one in SVG
and one in HTML, switched by CSS and media queries or JS.
> 2. Why does the SVG contain links?  This may be partially answered by the
> previous question.  Preumably this means that it's not meant as a purely
> decorative image and the links provide the user with something useful.
Because SVG links follow the SVG rendering model: they're positioned,
stroked, alpha blended, animated. Instead HTML links are flowed and
follow the CSS rendering model. Only their container (foreignObject)
is part of the SVG image. Either you put an foreignObject for each
link, or you don't use HTML links.
> 3. Why does the SVG image contain links using elements from a foreign
> namespace in addition to links using elements from its own namespace?
As I said earlier, SVG links are different from HTML links in that
HTML is flowed. If I want to have a rich user interface with animating
buttons on the top of my SVG, but I want to have some HTML content in
the same image, I need HTML links.
> 4. What is the author trying to achieve using a script that needs to obtain
> those links, and why does it only affect links from the SVG namespace, and
> not all links within the SVG image, including those from other namespaces
> within <foreignObject>?
As I said before, scripting may need those for imperative animation,
usually more powerful (but less performant) than declarative one. It
may need only SVG links because SVG links are completely different
than HTML links. Setting a strokeColor CSS property on HTML link has
no effect.
> If you can think of any other questions, feel free to ask them and answer
> them.  The more information we have about the use cases, the easier it will
> be to evaluate them and find an appropriate solution.
This is was not a complete use case, it was just an example.
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/

Received on Wednesday, 28 January 2009 16:32:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:13 UTC