RE: [selectors-api] Proposal to Drop NSResolver from Selectors API v1

From IE8's perspective, I'm obviously in favor of this. There is great benefit to getting this spec to recommendation now that there is critical mass from browser implementers.



-----Original Message-----
From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org] On Behalf Of Lachlan Hunt
Sent: Wednesday, April 23, 2008 2:19 PM
To: public-webapi
Subject: [selectors-api] Proposal to Drop NSResolver from Selectors API v1


Hi,
   Anne and I have discussed the possibility of dropping the NSResolver
features from Selectors API, and possibly moving it to version 2 of the
spec instead.  These are the reasons that we have for doing so:

1. Simplifies the API

2. Lack of Support

Current builds of WebKit and IE8 don't support namespaces yet. So far,
their implementation efforts have focussed on the other sections.

3. Lack of use cases that necessitate the use of namespaces in selectors

The majority of use cases don't need namespaces. Even the examples in
the spec don't need them.

As evidence, witness how often namespaces are used for selectors in CSS.
  In practice, even mixed namespace documents, such as XHTML+MathML+SVG,
can get away without using namespaces in CSS at all.  Since the tag
names in those languages differ enough to allow for mostly unambiguous
selection without namespaces.

4. Reduces the attack surface

Many of the problems with the current spec relate directly to
implementation issues with handling unexpected behaviour from
NSResolver's, even though it's an edge case for a feature that won't be
used all that much relative to the other parts.  Obviously, removing
support for namespaces also removes all the potential problems they cause.

5. Provides more time to work out the issues

Moving it to v2 gives more time to work out the issues with the
NSResolver.  This will allow v1 compliant implementations to ship sooner
rather than later, which will allow us to see how the APIs actually get
used in practice.

With more implementation and usage experience, we'll be able to study
the use cases more closely, and determine whether or not namespace
support is really needed.  As long as the API is defined in a forwards
compatible way, introducing namespace support later if needed shouldn't
be too much of a problem.

6. Allows for better interoperability

Implementers will be able to prioritise their efforts and focus on
getting interoperability between the most important parts of the spec,
instead of spending a disproportionate amount of time on less freqently
used features.  This will allow for more implemenation and testing time
for the other parts of the spec, and thus greater interoperability.

7. Reduced test suite size for v1.

Significantly reduces the number of features to be tested in the test
suite, and allows for more time to be allocated to writing test cases
for the more important features, which will actually allow for more
thorough testing.

The changes required to the spec would not be too difficult.  It would
basically just require removing all NSResolver related sections and
examples, and requiring implementations to throw NAMESPACE_ERR if a
namespace prefix is used.  This approach would be forwards compatible
with a future version of the spec that defined the NSResolver.

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

http://www.opera.com/

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

http://www.opera.com/

Received on Wednesday, 23 April 2008 21:56:09 UTC