- From: Travis Leithead <travil@windows.microsoft.com>
- Date: Wed, 23 Apr 2008 14:55:56 -0700
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapi <public-webapi@w3.org>
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