Jonas Sicking wrote:
Anne van Kesteren wrote:
On Tue, 19 Feb 2008 11:31:50 +0100, Jonas Sicking <[EMAIL PROTECTED]>
wrote:
I do sort of think that it's a pity to disallow a selectors
implementation in a browser from implementing additional selectors on
top of the ones in the CSS implementation, for example for the
reasons Boris mentioned. I don't feel very strongly about it, but I'm
wondering what the rationale for forbidding it is.
So that the "API" stays consistent. If a new selector comes up that
only makes sense in either we can always revisit this approach.
So for what it's worth I just ran into a selector that basically only
makes sense in a JS API but not in CSS. Apparently some javascript
toolkits support a :hidden selector that only matches elements which
matches elements that aren't displayed (presumably they or a parent are
display:none or visibility:hidden). Such a selector would never work in
CSS as it causes circular dependencies, but seems to be popular in
javascript.
http://ejohn.org/blog/selectors-that-people-actually-use/
The selectors spec doesn't currently define such a selector so it's not
really an issue now, but it might be in the future.
I have revisited this issue and decided to downgrade it from a MUST to a
SHOULD level requirement that these APIs support the same selectors that
are supported in CSS. This allows for appropriate exceptions to be made
for any possible future extension to selectors, such as the :hidden
example, which would work for selectors API, but not CSS.
This change will be reflected in the next editors draft.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
