Re: Selecting the parent of an element

Addendum: FWIW, it occurred to me that :has can be seen as opening a new
scope, so - provided the current node is matched in the :has-selector - one
could write

    E:has(:scope > F)  vs.  E:has(:scope F)

This wouldn't work for :matches, because the current selector may be within
a scope of its own (e.g., on a rule within <style scoped>) and one wouldn't
want to overwrite this information. To this end a new pseudo-class :current
may work that is useful for both :matches and :has. It'd be awfully limited,
but better than custom syntaxes IMHO:

   E:has(:current > F)  vs.  E:has(:current F)
   E:matches(F > :current)  vs.  E:matches(F :current)

(This still leaves the performance issue, though...)


Cheers,

- Roland


On Fri, Oct 7, 2011 at 20:30, Roland Steiner <rolandsteiner@google.com>wrote:

> On Fri, Oct 7, 2011 at 11:23, Barry van Oudtshoorn <
> bvanoudtshoorn@gmail.com> wrote:
>
>>
>> Hmm. I quite like :has() -- it makes the contents parenthetical. However,
>> would it then be possible to do direct descendants using :has() ? That is to
>> say, does E:has(F) equate to $E > F or $E F? Can one write E:has(> F) (to my
>> eye, that looks odd). Of course, the same question applies to the other
>> combinators.
>>
>> If these issues can be resolved, then I think I'll withdraw my reversed
>> combinators proposal in favour of :has().
>>
>
> IIRC there was a proposal to use '#' in :matches and :has for the current
> node (only in last place for :matches, only in first place for :has). I.e.,
> it would be
>
>     E:has(# > F) vs. E:has(# F)
>
> My main question in all of this is: has anyone thought about how to
> actually implement this without a) traversing the whole tree twice (once to
> set selected styles, once to do inheritance), or b) do a full subtree search
> every time on matching :has()? Additionally, how to handle updating of nodes
> - it seems ANY node could be affected by changes ANYWHERE in the DOM.
>
>
> - Roland
>