W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

[selectors-api] SVG WG Review of Selectors API

From: Doug Schepers <schepers@w3.org>
Date: Fri, 05 Dec 2008 15:34:33 -0500
Message-ID: <49399059.70905@w3.org>
To: "public-webapps@w3.org" <public-webapps@w3.org>, www-svg <www-svg@w3.org>

Hi, WebApps WG-

Here are the SVG comments on the Selectors API LC draft,
http://www.w3.org/TR/2008/WD-selectors-api-20081114/.

The SVG WG thinks that this specification is useful and done well, and
looks forward to this functionality being available in browsers.

As a high-level comment, the SVG WG would prefer to see support for
namespaces in the specification.  We believe that there will be an
increasing amount of (X)HTML+SVG content produced, and that there are a
number of cases where it would be easier for authors to have this
functionality natively, instead of hacking the results of a selector query.

However, we are also sensitive to the preference to get the
functionality into developers' hands as quickly and interoperably as
possible, and don't wish to obstruct quick adoption of this specification.

As a compromise, we believe that if the NSResolver support remains
removed from this specification, there should be explicit mention of
workarounds (see below), and an informative note mentioning that it may
be readded in a future version of the spec, to ensure that implementers
set up their architecture accordingly.

Erik Dahlström offers the following detailed comments, which the SVG WG
generally concurs with:

== 1.1 Examples

> > This script will also function correctly for a table written in XHTML 
> > markup instead of HTML.

I suggest this be reworded to say something like "If the above table is
converted to wellformed XHTML markup then this script will function
correctly on that as well."

Or the sentence could be removed entirely.

== Section 6. The NodeSelector Interface

> > The caller must pass a valid group of selectors.

That's an authoring requirement, explain how that is applicable?

> > The group of selectors must not use namespace prefixes that need to be  
> > resolved.

That also sounds like an authoring requirement. If it's an authoring
requirement please mark it as informative, or as only applying to
"conforming applications".

> > The implementation must first trim any leading or trailing whitespace  
> > from the value of the selectors parameter. The implementation must then  
> > process the value according to the grammar of Selectors ([SELECT],  
> > section 10).

If the processing means that the whitespace-trimmed value must match the
'selectors_group' production please say so.

> > Selectors are evaluated against a given element in the context the  
> > entire DOM tree in which the element is located.

...in the context of?

> > This means that the object will instead contain a list of matching  
> > Element nodes that were in the document at the time the list was created.

Is this time defined? I propose to reword it as follows:
"This means that the object will instead contain a list of matching
Element nodes that were in the document at the time the method was
invoked."

> > If the group of selectors include namespace prefixes that need to be  
> > resolved, the implementation must raise a NAMESPACE_ERR exception  
> > ([DOM-LEVEL-3-CORE], section 1.4).

Since NSResolver was taken out, please consider adding hardcoded namespace
prefixes for svg and xhtml similar to how the empty and any namespaces are
handled by this draft.

Or alternatively forward the reader to DOM 3 XPath for the cases where the
Selectors API falls short. Even if hardcoded namespace prefixes are added
it'd still be a good idea to link to DOM 3 XPath, since it looks like
Selectors API is unable to deal with arbitrary xml markup.

== 6.1 Resolving Namespaces

> > A namespace prefix needs to be resolved if the namespace component is  
> > neither empty (e.g. |div), representing the null namespace, or an  
> > asterisk (e.g. *|div), representing any namespace. Since the asterisk or  
> > empty namespace prefix do not need to be resolved, implementations that  
> > support the namespace syntax in Selectors must support these. [SELECT]

Please clarify the relation between the term 'null namespace' and the term
'default namespace' in CSS Namespaces[1].

== 8. Examples

Please add an example such as this one:

<html xmlns="http://www.w3.org/1999/xhtml">
  <body>
   <svg xmlns="http://www.w3.org/2000/svg">
    <font id="mysvgfont">
     ...
    </font>
   </svg>
   <font face="Arial">Example</font>
   <svg:font id="anothersvgfont" xmlns:svg="http://www.w3.org/2000/svg">
    ...
   </svg:font>
  </body>
</html>

Then explain how to use the Selectors API to select only the svg 'font'
elements and how to select only the svg font elements that have a prefix
on the element.

== References

Please add a normative reference to CSS Namespaces[1].

Clarify if "Other references" means "Informative references" or something
else.

[1] http://www.w3.org/TR/css3-namespace/


Regards-
-Doug Schepers, on behalf of the SVG WG
Received on Friday, 5 December 2008 20:34:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT