W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: Proposal for limited :matches pseudoclass

From: Eduard Pascual <herenvardo@gmail.com>
Date: Fri, 16 Jan 2009 00:33:36 +0000
Message-ID: <6ea53250901151633w4d319461tac008143f8f43c39@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style list" <www-style@w3.org>, bzbarsky@mit.edu

On Wed, Jan 14, 2009 at 7:45 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Jan 14, 2009 at 12:32 PM, Eduard Pascual <herenvardo@gmail.com> wrote:
>> 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.
Thanks for the explanation. I have also dug into the list's archives
for your original mail, back in July (I hadn't subscribed to this list
yet, so it took a while to get it); the examples you posted there are
what finally allowed me to get the whole idea.

> 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.
Thanks for the link. Although your examples with pseudoelements were
enough to highlight the issues, that thread was definitelly an
interesting read ;-).
I can now fully agree on your objections towards "!". And it seems
that we have the same reasons to dislike the "reverse" approach.

Now, something I don't fully agree with your proposal are the
limitations. I understand the performance concerns, and even managed
to find (and obviously read) the discussion on that issue starting at
(please, let me know if there is more to the topic than that thread).
I'm CC'ing Boris in the hope he can shed some light on the doubts I'm
exposing here. I'll try to state them clearly enough, but that can't
be easy.
1) The case "foo:matches(~ bar)" suggested in the "performance" thread
doesn't seem to have a clear answer (maybe I just missed it): would it
be a serious performance impact to allow it?

2) Even if we limit to the "+" and ">" combinators, would it be
possible to allow for multiple combinations like :matches(>p>img)? If
that is doable, what about mixing them like :matches(>p+table)?

3) The issue with the general descendant combinator seems to be a huge
one, but... it has only been described in terms of the worst-case. How
much likely are those "worst-case" situations to be found on the web?
It's quite obvious that something like *:matches( .non-existing-class)
would be awfully slow but, given it's blatant uselessness, are such
kind of things worth caring about? After all, if an author wants to
write a page that crashes, they have enough with a while(1) {
document.write("that's gonna crash");} script.
3.1) Still about the descendant combinator, would allowing for the
worst case affect the performance of non-worst pages? I think it's
quite reasonable for more complex pages to take longer both to render
and to execute DOM-manipulating scripts: it already happens with pages
that go too nuts with senseless div-nesting.
3.2) Has it been considered that the power granted by a "full"
:matches() implementation would allow authors to drastically clean-up
markup? I guess this may vary widely between browsers; but wouldn't
such markup simplification compensate (at least partially) for the
computation costs of the :matches() selectors?

I could wait for browsers to experiment with a limited version of
:matches initially; but I think my questions above should at least be
given some thoughts before enforcing any limitation. If even so
implementors don't like the idea of a "full" matches, then I'll give
up :P.
Finally, I'd like to add what I think is a nice example of use-case
for descendants inside :matches() (just to show that it'd be, at
least, useful). The example assumes a HTML document with a form on it,
and I hope it's self-explaining enough:
form:matches( :invalid)::after {
    color: red;
    content: "Some fields are invalid. Please review your entries
before submiting.";

Eduard Pascual
Received on Friday, 16 January 2009 00:34:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC