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

What are the remaining issues that are still holding us back? It seems 
to me like if we know we're going to add this in a version 2, but we 
already have a done specification for it, why not include it?

It seems to me that implementations aren't going to be affected one way 
or the other on this. If we do include it in the spec anyone can still 
implement everything but namespaced selectors. I think implementors are 
competent enough to prioritize appropriately without us holding their 
hand. Especially if their CSS engine does not yet support namespaced 
selectors.

As far as interoperability goes, it seems to me that it would in fact 
help to have it in the spec since otherwise you run the risk of 
implementations going ahead and doing namespaced selectors on their own, 
in non-compatible ways.

So I think that if we're close to done with having namespace support, we 
might as well include it for the sake of having interoperability for 
namespaced selectors. I don't think implementations that don't want to 
implement namespaced support are affected one way or another.

I guess except that they couldn't do silly PR claims like "full 
Selectors API v1 support"). If we wanted to satisfy such desires we 
could say that it's ok to claim full support even without NSResolver if 
your CSS engine does not support namespaced selectors.

/ Jonas


Lachlan Hunt wrote:
> 
> 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.
>

Received on Wednesday, 23 April 2008 22:31:27 UTC