Re: Proposal: parent selectors

On Thu, Jan 21, 2010 at 5:44 PM, Eduard Pascual <herenvardo@gmail.com> wrote:
> The fact is that there is a rising demand for a descendant selector,
> exemplified by the amount of times this request has been brought to
> discussion on this list (and a need, proved by the use-cases brought
> forward into the discussions). Sooner or later, this will get into
> CSS. It is true that it has a significant impact on performance, and
> it's an implementation challenge to mitigate it (as well as a task for
> authors wanting to have this sooner rather than later to help
> implementers as much as we can to overcome that challenge).

This is why I suggest :has-child(), as a stop-gap.  IMXP, the majority
of use-cases for :has() are either about children, or would require
only a light page rewrite to make it about children.  Thus, pushing a
limited form of :has() that can be much more easily optimized will
allow us to solve more use-cases faster.

It would probably be smart to work with the principle of
shorter-name-greater-use, and use :has() for finding children only,
then later introduce a :has-match() pseudoclass for the general case
(or, if it makes sense, break it up further into :has-sibling and
:has-descendant pseudos).  That way, even when the more general (and
more expensive) methods get added, people will still intuitively reach
for the shorter-named one when possible, which is best for all
parties.

This does mean that we break parity with jQuery, but I think it's
worth it if this would make it easier for authors to do the right
thing and avoid killing the perf of their page.

~TJ

Received on Friday, 22 January 2010 00:00:51 UTC