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/