Erik Dahlström wrote:
On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt
<[EMAIL PROTECTED]> 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/

Reply via email to