- From: Brian Kardell <bkardell@gmail.com>
- Date: Fri, 30 Jan 2015 23:06:46 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: public-houdini@w3.org
- Message-ID: <CADC=+jdL-SNJ8EOZq2det_ZwxxRtnEZD7YEDOR_xp21EGPn4=Q@mail.gmail.com>
On Jan 30, 2015 7:07 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > > Several years ago, the Sass preprocessor adding the @extend rule, > which lets you declare that one selector "extends" another base > selector, so that any rules that apply to elements matched by the base > selector also apply to elements matched by the extending selector. > > For example, you can "extend" a .error class with a .serious-error > class, easily applying all the basic .error styling to your > .serious-error elements as well. This lets you avoid duplicating > anything - you don't need to put class="error serious-error" in your > HTML, or ".error:hover, .serious-error:hover" in your CSS selectors, > or manually copy over the .error styling into .serious-error ruels. > > In August 2012, dbaron suggested something extremely similar > <https://lists.w3.org/Archives/Public/www-style/2012Aug/0363.html>, > based on a discussion with Yehuda Katz and Nicole Sullivan (Nicole > provided the original inspiration for @extend in Sass). I pointed out > that this was just @extend with a different, slightly more awkward, > syntax. > > In January 2013, Philip Walton also proposed something extremely > similar <https://lists.w3.org/Archives/Public/www-style/2013Jan/0241.html >, > and I again pointed out that this was just @extend with a more awkward > syntax. > > I finally got together with Chris Eppstein, one of the primary > maintainers of Sass, and banged out a spec for @extend as a CSS > feature. Natalie Weizenbaum, the creator and primary maintainer of > Sass, has reviewed it and found it acceptable, so I now present it to > the group for review: > <http://tabatkins.github.io/specs/css-extend-rule/> > > This proposal adds the @extend rule, based on the semantics defined by > Sass. It also adds the "placeholder selector", which is similar to a > class selector, but no aspect of the DOM can cause an element to match > it. Experience with Sass shows that this is extraordinarily useful in > practice, as it lets you safely design styles without having to worry > about accidentally clashing with an existing classname, and then just > @extend elements into matching it. > > To be precise, the semantics of @extend is that it causes elements to > act as if they have whatever additional features are necessary to > match the extending selector. For example, in the following rule: > > ``` > .serious-error { > @extend .error; > font-weight: bold; > } > ``` > > Any element matching .serious-error is treated as if it also has the > .error class (as that's what's required in order to match the .error > selector). All selectors in the document that mention .error now > potentially apply to .serious-error elements as well. > > There are more examples in the document, so I won't reproduce them here. > > The @extend rule has been one of the most popular and useful features > in Sass since its introduction. It can only be imperfectly > implemented in Sass via selector rewriting (a naive implementation > runs into combinatorial explosions; Sass uses heuristics to tell which > selectors are "most likely" to be important and only exports those).. > We can implement it perfectly in the browser by actually affecting > matching, and bring this super-popular tool to millions of authors > using plain CSS. > > Thoughts? > > ~TJ > Since no one else is saying it, I will: I really liked it on first read. Of course, you know this because I told you when I first saw it, but here it is "for the record"... <3. I'll look at it much more closely this weekend and see if I can offer more.
Received on Saturday, 31 January 2015 04:07:13 UTC