Re: [selectors-api] Selectors API comments: section 2

Jonas Sicking wrote:
> Anne van Kesteren wrote:
>> On Tue, 19 Feb 2008 11:31:50 +0100, Jonas Sicking <jonas@sicking.cc> 
>> 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/

Received on Wednesday, 19 March 2008 13:12:13 UTC