W3C home > Mailing lists > Public > www-style@w3.org > September 2013

Re: [selectors4] Use pesudo-class instead for selecting parent elems

From: Simon Sapin <simon.sapin@exyr.org>
Date: Tue, 03 Sep 2013 09:15:14 +0100
Message-ID: <52259A92.3090207@exyr.org>
To: Xidorn Quan <quanxunzhen@gmail.com>
CC: www-style@w3.org
Le 03/09/2013 03:00, Xidorn Quan a écrit :
> On Tue, Sep 3, 2013 at 12:38 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
>> Le 31/08/2013 08:10, Xidorn Quan a écrit :
>>
>>> Hi all,
>>>
>>> I am new here. I have a suggestion for selecting parent elements.
>>>
>>> In the current draft, a new mechanism is introduced to change the
>>> subjects of a complex selector, which is prepending (or appending)
>>> exclamation mark, so that an element can be selected according to its
>>> descendents.
>>>
>>> But IMHO, it is not a flexible way to do so. Sometimes we may want to
>>> select not the elements with specified descendents themselves, but the
>>> elements related to them, like preceding, descending, etc. Consider
>>> the following document:
>>>
>>> <UL>
>>>       <LI>
>>>       <LI><UL></UL>
>>>       <LI>
>>> </UL>
>>>
>>> It is not possible for current selectors4 definition to write a
>>> selector to represent LIs which follow a LI who has an UL inside.
>>> There are many similar cases.
>>
>>
>> :matches() to the rescue:
>>
>> li:matches(*! ul) ~ li
>
> I found that in the overview table, :matches only accepts compound
> selector as its arguments, so I didn't know this usage.

That looks like a bug in the overview table.


> However, after I checked the details, I found that :matches accepting
> complex selector requires complete profile, which might not be
> implemented for CSS for performance reason.

The definition of the complete profile (minus the fast profile) is stuff 
that can not be implemented with good enough performance in stylesheets. 
If it turns out it can, we will move stuff between profiles.


> It is not acceptable to me.
>
> I believe that :matches which supports complete complex selector is
> hard, if not impossible, to be implemented in a fast way, but it is
> possible for the pseudo-class I requested which narrows the looking-up
> range to its descendents.

Is it? As far as I understand, the problem here is that a dynamic change 
anywhere in the tree, in the presence of such selectors, would require a 
big part of the tree or the whole document to be restyled.

Does your proposal really help with that? Especially (see below) if the 
argument to :has() can start with a combinator.


>>> However, if we use pesudo-class instead, like :contains() or
>>> :has-child(), the problem can be solved. For the example above, we can
>>> use "LI:has-child(UL)~LI" to select the elements required.
>>>
>>> IMO, this kind of notation looks more intuitive, and won't introduce
>>> new symbols to complexify the grammar. And we would not need to worry
>>> about whether the mark should be prepended or appended anymore. Just
>>> drop it.
>>>
>>> What do you think about this idea?
>>
>> :has-child() seems less general than the subject indicator. Isn’t it?
>
> I don't think so. :has-child() might seem to be confusing. :has() or
> :contains() should be a better name.
>
> The pseudo-class :-hitch-has() in hitchjs.com mentioned by Brian
> Kardell has exactly the same function I wanted. You may want to check
> it out: http://hitchjs.com/describe/native.html#has

It seems to me that :-hitch-has(<foo>) is exactly the same as 
:matches(*! <foo>)

-- 
Simon Sapin
Received on Tuesday, 3 September 2013 08:15:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:34 UTC