Re: Proposal for limited :matches pseudoclass

On Wed, Jan 14, 2009 at 10:48 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Tab Atkins Jr. wrote:
>>
>> More importantly, though, I feel this allows you to get some very
>> confusing combinators when you start moving up and down the tree.
>> Frex, "a > b < c d < e" would be possible, but I severely doubt it
>> would be easy to understand.
>
> That's one major problem, yes.  For example, the above combinator matches no
> nodes unless c == a.  Of course one could use .c instead of "c", in which
> case the thing being matched is "Element named 'e' which is the parent of an
> element named 'd' which has an ancestor matching 'a.c', and said ancestor
> also has another child named 'b'."

The letters in my example were meant to be placeholders for any simple
selector, not necessarily limited to element names.  That particular
construct is still useful, though, if you need a parent node to
*contain* b, but the targetted node may lie in a different tree from
b.

It would have been clearer had I used "a" in both places, of course.

> I'm not sure that a selector expressing that would look simple or be easy to
> read in _any_ notation, honestly.

"a:matches(> b) e:matches(> d)" is both simple to write and easy to
read, I think.  It certainly feels clearer than having to mentally
walk the tree up and down to decipher the selector.  It makes it clear
that the primary parts of the selector are "a" and "e" (which matches
with both our intuition and existing CSS patterns), but there is an
additional condition (having particular children) that each must also
fulfill in order to successfully match.  This syncs up exactly with
the existing pseudoclass mechanics and semantics, which makes it
easier to understand and makes interactions with other parts of the
language simpler.

Received on Wednesday, 14 January 2009 18:09:58 UTC