Re: Proposal: parent selectors

On Fri, Jan 22, 2010 at 12:59 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.
> [...]
I already suggested to begin with a limited version before going nuts
with the full version. However, since that doesn't have the problems
we'd get with the full version, I'll keep looking for ways to optimize
the big one in the hope that helps it becoming a reality sooner.

However, I don't think we need to bloat the syntax with different
names for each version: simply use the generic name, like :has() or
:matches(), now for the limited version, requiring the argument to
begin with ">" (or maybe allowing also "+"), and when implementations
of the full version become a reality the spec can just lift the
restriction. In the case of implementations, in principle they don't
need different names to perform "version"-specific optimizations. For
example, if a browser has specific implementations for the "parent
selector" (the one starting with ">"), it can check whether the
argument begins with that combinator or something else while parsing
the CSS and flag or mark the token accordingly. In practice, it may
depend on the implementation details whether such flagging/marking is
doable or not; so it'd be nice to hear some implementer's opinion on
this.

Regards,
Eduard Pascual

Received on Friday, 22 January 2010 01:05:48 UTC