W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: Parent Combinator / Parent pseudo-class

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 23 Jul 2008 10:36:58 -0500
Message-ID: <dd0fbad0807230836o14537ab4meee3948a78585ee9@mail.gmail.com>
To: "www-style list" <www-style@w3.org>
Cc: "Brad Kemper" <brkemper@comcast.net>, w3mail@jixor.com
On Wed, Jul 23, 2008 at 10:05 AM, Alan Gresley <alan@css-class.com> wrote:

> Brad Kemper wrote:
> [...]
>> A parent combinator pseudo-class or parent pseudo-class requires a CSS
>>> parser to walk the chain.
>> Only of immediate children, not of all descendants of a particular
>> has-child selector. Anyone using it more than sparingly should expect some
>> performance degradation.
> But what Stephen is`suggesting is firstly to walk the chain backwards to
> the parent element and then secondly match each particular parent child
> combinator. If my understanding is correct, that is a double performances
> hit.

Stephen's original suggestion may require that, yes (though I doubt it in an
intelligent implementation).  But the :matches pseudoclass does *not*
require this at all.  You would hold a reference to the main element and
then walk down in the ordinary matching pattern.  In other words, the only
additional load on the matching engine would be remembering what node it's
actually targetting, rather than merely targetting whatever's at the end of
the chain when the match succeeds; otherwise, it's exactly identical to
normal matching.  Now, selectors with several :matches pseudoclasses will of
course be a bit more expensive than normal, but that's the same with
anything - overload a selector with something fancy and it'll be a bit

As Brad says, authors will always find a way around.  This particular thing
can be done by walking the DOM in javascript and directly playing with
styles.  Putting it directly in CSS instead makes it (a) defined once by
intelligent developers who know what they're doing, rather than the average
author (or more likely, javascript library author) and (b) likely much more
efficient, as it be inserted into the normal CSS matching flow (thus not
requiring you to do at least two independent matching runs).

The use-cases have already been noted, and are relatively significant (at
least as significant as several of the substring-matching selectors, which
we have a profusion of now ^_^).  There are many times when you may want to
style something based on its contents ( :matches with a descendant
selector), by it's following siblings ( :matches with a sibling selector),
or by some other interesting selector that would normally end up targetting
something other than what you want styled.

Received on Wednesday, 23 July 2008 15:37:43 UTC

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