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

Erik Dahlström wrote:
> On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt
> <lachlan.hunt@lachy.id.au> wrote:
>> 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.

I have not listed any other potential features because I don't think 
it's appropriate to indicate any sort of premature commitment to any of 
them within the spec and because feature requests are already recorded 
and tracked separately.

http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Selectors+API

Each one will be considered fairly and objectively based on the evidence 
provided, and namespace resolution will be treated no differently in 
this respect.  For this reason, I'm still personally opposed to the 
inclusion of such a note in the spec.

However, having said that, it does seem useful for readers of this 
specification to understand that prefix resolution is not currently 
available.  I have, therefore, included the following note in the spec:

  "This specification does not provide support for resolving arbitrary
   namespace prefixes. However, support for a namespace prefix resolution
   mechanism may be considered for inclusion in a future version of this
   specification."

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

I have changed it from MUST to SHOULD and rephrased the statement so 
that it just describes the syntax of the expected input.

   "Both querySelector() and querySelectorAll() take a group of selectors
    (selectors) as their argument. This group of selectors should match
    the selectors_group production with the additional provision that
    leading and trailing whitespace is permitted. This group of selectors
    should not use namespace prefixes that need to be resolved."

>> "This group of selectors must not use namespace prefixes that need
>> to be resolved."
> 
> What are the consequences on future versions of the spec?

If namespace resolution is included in a future version of the spec, 
then that is not expected to cause any issues.

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

That wasn't clear since "... in the context of?" appeared to be a 
question.  Anyway, this was already fixed.

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

I don't understand what the issue is with this, or how it's related to 
when the list is created.

> * on a document that  isn't fully loaded (e.g triggered from a load
>   event on some element in the document)

This seems to be a reason to retain the current wording instead of 
changing it as proposed.  If the spec said "at the time the method was 
invoked", then the implementation would have to ensure that no further 
changes to the document were made between then and the time it obtained 
the result.  By saying "at the time the list is created" makes it easier 
to populate the list whenever the implementation is ready, simply based 
on what it has available to it at the time.

But regardless of the wording in this case, given the unpredicatable 
nature of loading times, the results could potentially vary anyway, 
depending on all sorts of factors affecting when resources finish loading.

> * triggered from a document load event

I don't understand what the issue is here either.

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

No, although it is possible to be implemented by such a client.  IE8 is 
a downlevel client, but Opera, Safari and Firefox are not.

The API supports the syntax, which can be used for the null- and 
any-namespace cases.  It just doesn't have a namespace prefix 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?
> 
> There are limitations in Selectors API that will force people into
> either doing workarounds, or to use another technology for the
> selection.

Indeed, there are some significant limitations of the current API.  Some 
of them are even more significant than the lack of namespace resolution. 
  But beyond namespace resolution, which hasn't yet been proven to be a 
significant problem in practice, it's not clear to me that XPath solves 
any of the other significant issues (particularly the issue regarding 
selector scoping that is a real problem for JS libraries).

> 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

The popularity of a particular point of view doesn't have any impact on 
the merits of the arguments in favour of it.

>>> == 8. Examples
>>> 
>>> Please add an example such as this one:
>>> ...
>>> 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.

I will reconsider this issue shortly.

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

That technique is already adequately described in Selectors, and since 
this API is not inherently limited to downlevel clients (in fact, most 
implementations are not), doing so does not seem useful.

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

Received on Tuesday, 9 December 2008 15:25:25 UTC