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

On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:

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

Given that NSResolvers were taken out of the spec it deserves to be called out, and the problem described. Were there any other features that were removed in this LC draft?

The SVG WG have no objections to listing other features that will be added in the next version. 

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

Thanks, that is satisfactory.

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

See http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0453.html.

>>>> 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 first part is satisfactory.

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

What are the consequences on future versions of the spec?

The SVG WG will agree to the proposed wording if NSResolvers (or equivalent) are listed as a feature to be added in the next version of the spec.

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

You were only missing an 'of' in the sentence there, simply adding that will be enough to satisfy this comment.

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

Fair enough.

Some of the things I could potentially see at risk of being non-interoperable are listed below.

Using the Selectors API: 
  
  * on a subtree that is outside of the document
  * on a document that isn't fully loaded (e.g triggered from a load event on some element in the document)
  * triggered from a document load event

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

Those are quite different, since neither of the svg or xhtml namespaces are predefined (unless you count doctype declarations possibly).

So essentially Selectors API is a downlevel client[2]?

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

The SVG WG agrees that it would adversely affect such future plans, and would be satisfied with a mention in the current version that namespace resolution mechanisms will be added the next version of the spec along with examples showing how to work around this issue.

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

There are limitations in Selectors API that will force people into either doing workarounds, or to use another technology for the selection.

It seems the SVG WG isn't alone in wanting to have the informative reference to DOM 3 XPath:
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0451.html
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0449.html

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

This was just a confusion with namespace prefix declaration in CSS 3 Namespaces, and since the Selectors API doesn't do any declaration of prefixes because NSResolvers were dropped this doesn't need to be addressed.

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

The SVG WG disagrees with this reasoning. People will run into this problem, and it seems appropriate to give an example and to show how to work around the lack of namespace-aware selectors. Note that even if it's not possible to distinguish between the elements using Selectors API alone, the result can be filtered e.g using DOM Core methods to give a meaningful result. Another workaround could be to pass a descendant combinator selector such as "svg font" to check the the <font> element has an <svg> element ancestor, this would cover many of the use-cases. 

It would also be useful to mention the backslash escaping mechanism for downlevel clients[2].

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

The SVG WG agrees that since Selectors API doesn't do namespaces part of selectors it's not necessary to have a normative reference. However, given that some (although trivial) namespace resolution is done (the any namespace and the null namespace) it still warrants having an informative reference to CSS 3 Namespaces[1].

>> Clarify if "Other references" means "Informative references" or something
>> else.
>
> I changed the heading to Informative References.

Thanks, that's satisfactory.

Cheers
/Erik, on behalf of the SVG WG (ACTION-2376)

[1] http://www.w3.org/TR/css3-namespace/
[2] http://www.w3.org/TR/css3-selectors/#downlevel

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

Received on Tuesday, 9 December 2008 11:49:17 UTC