- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 21 Feb 2008 23:57:09 -0800
- To: Anne van Kesteren <annevk@opera.com>
- CC: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Web APIs WG <public-webapi@w3.org>
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. / Jonas
Received on Friday, 22 February 2008 07:57:03 UTC