Re: Proposal for limited :matches pseudoclass

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.
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.

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).
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.

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.

Well, this is my viewpoint.
Greetings,
Eduard Pascual

Received on Wednesday, 14 January 2009 18:33:34 UTC