Re: Proposal for limited :matches pseudoclass

On Wed, Jan 14, 2009 at 12:32 PM, Eduard Pascual <herenvardo@gmail.com> wrote:
> On Wed, Jan 14, 2009 at 4:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> The lack of any appropriate opposites for any other combinator is a
>> decent drawback
> I hope we can all agree on that. IMHO, the inability to select some
> part of the document for styling based on its children is currently
> the biggest drawback in CSS, and the source of lots of frustration.
> If we can agree on that need, then we can start discussing the
> possible solutions.

Nod.  This really is a pressing need for authors, but it's also a very
difficult thing for implementors to do in a performant way.  I'm
trying to get my foot in the door with this proposal, in the hopes
that once a simple version exists (which is still very useful to
authors), implementors will start working on the more complex
versions.  Start small and work up, you know?

> Here goes my opinion about the different proposals:
>
> About :matches(), I'd normally just use them to light fires... jokes
> aside, it brings in a (maybe needlessly) confusing syntax for
> something that, IMHO, is quite essential. I can't opine any further on
> it, because I'm still struggling to understand how it would work.

Ah, let me see if I can make it more clear.  This is, in my mind,
fundamentally a pseudoclass issue.  You want to match an element in
the document, but only if it fulfills certain criteria.  This is how
all pseudoclasses work - they specify special criteria that an element
has to fulfill to be matched.

In this case, you only want to match an element if it has a particular
child (or adjacent sibling).  So, you specify it exactly as you would
any other CSS rule, by writing your normal selector to target the
element, then putting the pseudoclass on it detailing the condition.

To take an example I used above, you might write "a:matches(> b)
c:matches(> d)".  This means you're matching an element "c" which is a
descendant of "a", and furthermore, "a" must have "b" as a child, and
"c" must have "d" as a child.

Written in the "<" syntax, that would be "b < a d < c" (yes, I found I
could simplify it further).  This selector cannot be written in the
basic "!" syntax.

Given the "<" version of the selector, I challenge anyone to assert
that it is as easy to identify the primary elements in the selector as
it is to identify them in my version.  It is *not* immediately obvious
which parts of the selector are primary (that is, actually part of the
selected path) and which are secondary (extra branches used to specify
conditions on the match).  I also believe it is more difficult to
write.  You have to either 'overshoot' the element you want to target
and then pull back (done twice in the selector when I target b and d,
and then pull back to a and c, the elements I actually want), or
repeat the selector for the desired element (it could also have been
written as "a > b < a c > d < c") which is horrible both for reading
and writing (especially, imagine if these weren't simple element
names, but rather complex selectors in their own right; frex, replace
"a" with "#header li > a" and see how clear the rule becomes).

> About the ! approach (the operator that gets used for this is
> completelly arbitrary): it is an elegant solution, with great
> readability: you just put a "classic" selector on your sheet, and then
> highlight with an operator which node(s) within the traversed path get
> actually selected for styling. And it opens up the possibility to
> select multiple nodes within the path (I can't think of any use case
> for this extra possibility right now; but if the "! approach" is used
> to solve the "select parent/ancestor" need, then we are getting it for
> free).

It seems that way at first, but then consider what happens when you
throw pseudo-elements into the mix (either on the !'d element, or on
the last element (like normal)).  Or if you want multiple 'branches'
(the rule I created earlier in this email has two, "a > b" and "a d >
c").  In general, it's a novel addition to the language that requires
a relatively large amount of specification to make it clear where it
can be used and what changes when it is in use.  A pseudoclass, on the
other hand, requires zero additional specification beyond what it
actually does, because it can lean entirely on the existing rules.

> On Wed, Jan 14, 2009 at 4:03 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Yup, read the thread where that came up, but I'm with Ian in not
>> liking it very much.  It changes too many things about CSS that I
>> think are relatively prime, and allows you to write too many invalid
>> selectors.
> Could you please point us to that thread, --or-- give a summary of
> which things about CSS it changes, and which kind of invalid selectors
> are you speaking of? I fail to see the issues you mention, and I'm
> clueless about what to search for to get to that thread.

Certainly.  It starts on [May 2,
2002](http://lists.w3.org/Archives/Public/www-style/2002May/0011.html).

I could summarize, but I've already done so partially in my emails to
fantasai and others, and I think the dialogue in that thread is
probably more instructive.  Particularly, pay attention to Ian's
emails.

> The "reverse" approach is also nice, because it is simetricall to the
> already existing + and > operators, but it still affects readability:
> currently, when reading a selector, if you go left-to-right then you
> are always going from root/outer nodes to the deeper ones in the
> markup tree (or, if you read right-to-left, then you traverse the tree
> from dept to root); a < operator would break this.

Yup, that's my big objection to that proposal - it significantly
changes how we read a selector, and not for the good, I think.

~TJ

Received on Wednesday, 14 January 2009 19:45:57 UTC