W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 23 Apr 2008 23:18:48 +0200
Message-ID: <480FA7B8.4070000@lachy.id.au>
To: public-webapi <public-webapi@w3.org>

   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
Lachlan Hunt - Opera Software
Received on Wednesday, 23 April 2008 21:19:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:10:01 UTC