W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Fwd: [selectors-api] Comment on Interoperability Considerations

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Sun, 14 Dec 2008 13:34:07 +0100
Message-ID: <65307430812140434x2d02a492n7ba4da039b34ce31@mail.gmail.com>
To: public-webapps@w3.org
2008/12/13 Norbert Lindenberg <w3@norbertlindenberg.com>

>
> Dear Web Apps WG,
>
> I've reviewed the Selectors API [1], and have one comment:
>
> The Interoperability Considerations section states that in certain cases
> "such implementations could return different results from those that do
> support them". While this is a non-normative section, just referring to
> "different results" seems a bit too vague and is not really helpful for
> applications relying on the specification. Even more worrying, after reading
> the rest of the specification and the underlying Selectors specification [2]
> I can still not tell what the intended behavior is. The Selectors
> specification introduces Profiles, which indicate which selectors are
> supported ("accepted") by a specification using Selectors, but it neither
> introduces a similar concept for implementations, nor does it seem to
> specify the behavior resulting from the use of selectors that are not
> supported by a specification or an implementation.
>
> I would expect the specification to prescribe
> - either that the implementation raises an exception when given a selector
> that it doesn't support,
> - or that the implementation return null (for querySelector) or an empty
> list (for querySelectorAll) when given a selector that it doesn't support.
>
> Maybe we could add the possibility to query DomImpelementation.hasFeature
for SelectorsAPI and different Selectors Profile
Selector API spec already depends on DOM3Core, so it would not be a real
problem to add this requirement, IMO
If the application don't want to check for feature, then application should
report SYNTAX_ERR, since there are tokens it cannot parse in the selector
string. (see end of 6th paragraph, section 6)
Received on Tuesday, 16 December 2008 13:06:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT