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.
