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

Le 03/09/2013 09:15, Simon Sapin a écrit :
> 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>)


I should add: I’m not convinced that :has() solves any performance 
problem, but if it turns out to be equivalent in expressive power to the 
subject indicator, I like this proposed syntax better. (:has() has no 
equivalent to multiple subject indicators in the same selector, but I’m 
not overly attached to that feature.)

-- 
Simon Sapin

Received on Tuesday, 3 September 2013 08:24:57 UTC