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

Doug Schepers wrote:
> 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.

There are several features which will be considered for inclusion in the 
next version of the spec.  Why should this one in particular be called 
out over any other requested feature?

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

The real intention of that statment is to illustrate that the method 
works on the DOM, independently from any specific syntax used to create 
the DOM.  I have rewritten it to make that more clear.

   "Note that the script operates on the DOM and works independently from
    the syntax used to create the document. Thus this script will also
    work correctly for an equivalent table created from well-formed XHTML
    instead of HTML, or dynamically created and inserted into a document
    using DOM APIs."

> == Section 6. The NodeSelector Interface
> 
>>> The caller must pass a valid group of selectors.
> 
> That's an authoring requirement, explain how that is applicable?

It seems perfectly applicable for the spec to define how the methods 
need to be used by conforming applications.  Please explain why you 
think it is not 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.

I have addressed these two concerns by adjusting the requirements for 
conforming applications to state:

   "The caller must pass a valid group of selectors that matches the
    selectors_group production ([SELECT], section 10) with the additional
    provision that leading and trailing whitespace ([SELECT], section 4)
    is permitted. This group of selectors must not use namespace prefixes
    that need to be resolved."

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

I'm not sure how to phrase that any more clearly.  It means that when 
evaluating a selector, all elements in the document may be taken into 
account, and not just those within the node's subtree.

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

IIRC, the original reason for saying "at the time the list was created" 
instead of what you propose was that, when the NSResolver was still part 
of the spec, it was possible that the nsresolver function could modify 
the document in ways that would affect which elements were matched.  I 
could change it, but I'd prefer to get feedback from implementers about 
the implications of the change before doing so.

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

Similar functionality was previously requested and rejected for the xml 
and xmlns prefixes, and I see no reason to treat the xhtml and svg 
prefixes any differently.

http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html

Additionally, doing so could have adverse affects on any future plans to 
introduce a proper namespace resolution mechanism.

> Or alternatively forward the reader to DOM 3 XPath for the cases where the
> Selectors API falls short.

Please explain how providing a reference to DOM 3 XPath would be of any 
benefit?  How would it help readers in their understanding of this spec?

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

I do not understand your request.  The null namespace and default 
namespace are entirely different concepts.  The null namespace refers to 
the lack of a namespace, whereas the default namespace refers to the 
namespace declared without a prefix, and used when matching unprefixed 
selectors.

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

As Boris explained, and as I'm sure you're well aware, it is not 
possible to distinguish between elements with the same local name 
without using namespaces.  I cannot demonstrate the impossible and have 
not included the example in the spec.

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

Why?  It is the Selectors spec that defines the meaning of the namespace 
prefix syntax that is used, and this spec does not include any features 
that depend on the CSS3 Namespace Module.

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

I changed the heading to Informative References.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Monday, 8 December 2008 16:37:57 UTC