W3C home > Mailing lists > Public > public-houdini@w3.org > January 2015

Re: Proposal for adding @extend to CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sat, 31 Jan 2015 08:55:13 -0800
Message-ID: <CAAWBYDA_OwqrK0T5nThHYr1cTJCquPqE9V+KvBHuf1z++5Ruqw@mail.gmail.com>
To: Fran├žois REMY <francois.remy.dev@outlook.com>
Cc: public-houdini@w3.org
On Sat, Jan 31, 2015 at 4:56 AM, Fran├žois REMY
<francois.remy.dev@outlook.com> wrote:
> As a starter, I would have loved to see a selector matching algorithm which is conforming this specification; I'm interested in particular in how we can implement this in a single-phase matching, if that's possible. My thoughts is that you can't perform this in a single matching phase and will first need to match rules containing @extend rules, modify the "matchable dom" and repeat until no more additional changes is made to the matchable dom.

Correct, but in practice you can do it in two-ish passes - first pass,
find only the rules with @extend in them (a small set), and do the
iterate-until-stable thing on just them. This'll complete fast, unless
people deliberately go crazy.  Then you can do normal matching on the
second pass.

> This means that selector matching now needs to be performed top-down as selector matching for an ancestor may affect what rules match one if its children as a result of the mutated matchable dom; this may harm the parallelization of matching. That being said, maybe some other characteristics of css matching already do so; that's why I would have liked to see this discussed. I also wonder what might be the performance impact (but I guess only a prototype might inform us).

No, I don't think this affects the way you have to do selector
matching.  You just let @extend mutate the data structures you use for
matching, and then do matching normally.

> My second thought is this simply isn't going to be easy to create a consistent matchable dom using @extend. I have some examples:
>
>     :not(.open) { @extend .open }
>    .open { @extend :not(.open) }
>
>    .a { @extend .b }
>    .b { @extend :not(.a) }
>
>    <div> <e1/> <e2/> </div>
>    :not(button) + e2 { @extend button }
>    :nth-last-child(2 of button, e1) { @extend button }

Yes, I think we have to prevent use of :not(), and apply a restriction
to any selectors taking complex-selector or selector-list arguments to
restrict them to only accept compound selectors as well.  I need to go
over the Selectors spec in detail and see if there's anything else
troublesome, but I suspect that's enough.

> It may also be hard to manage security restrictions:
>
>     a:visited { @extend button }

Ooh, good point.  Yeah, probably wanna say that @extend doesn't work
in a :visited rule.

~TJ
Received on Saturday, 31 January 2015 16:56:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:22 UTC