Comments on Selectors API

Hello svg-wg,

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

For further discussion on Thursday.

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

Cheers
/Erik

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

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 25 November 2008 11:46:15 UTC