- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 22 Nov 2011 21:45:43 -0800
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: Boris Zbarsky <bzbarsky@MIT.EDU>, public-webapps@w3.org
On 11/22/2011 05:30 AM, Lachlan Hunt wrote:
> On 2011-11-22 14:09, Boris Zbarsky wrote:
>> On 11/22/11 8:05 AM, Lachlan Hunt wrote:
>>> The current draft of Selectors 4 includes :matches(), though, which can
>>> partially handle that case, excluding :not([type]), which would have to
>>> be left separate.
>>
>> That seems like a bug in :matches() that just needs fixing if it's meant
>> as a replacement for :any().
>
> Actually, I'm mistaken. The spec says that :matches() can't be used within
> :not(), rather than the other way around.
There's a number of arbitrary restrictions in Selectors 4 in the :matches()
and :not() definitions, which are there mainly to limit implementation
complexity and I'm happy to remove if requested.
The full definition is
:matches() - matches the selector in its argument
:not() - does not match the selector in its argument
where any valid "selector list" [1] is a valid argument to :matches() and
:not(). Combined with an IAmTheSubjectOfTheSelector indicator, this would
allow matching against pretty much any tree pattern.
(It's called :matches() rather than :any() because in the full version, it
can be useful to use it with only one complex selector, i.e. without
commas. And then the word "any" doesn't make as much sense, imho.)
[1] I split out the term "selector" into a number of more specific terms,
because it was getting really confusing.
http://dev.w3.org/csswg/selectors4/#selector-list
Received on Wednesday, 23 November 2011 05:46:22 UTC