Re: [csswg-drafts] [extend-rule]

To clarify what i meant when I said:

> The specificity of the rewritten selector changes causing the selectors to match in a new overall cascade that is not the same as the original. But an in-browser implementation would not have this issue.

Consider the following CSS with the hypothetical `@extend` implementation:

```scss
.article .important { font-weight: bold; color: black; }
.article .muted { color: gray; }
#a-particular-article h2 { @extend .important; }
```

Sass rewrites this to:

```scss
.article .important, .article #a-particular-article h2, #a-particular-article .article h2 {
  font-weight: bold;
  color: black; }

.article .muted {
  color: gray; }
```

(note: sass should also generate `.article#a-particular-article heading` for completeness, but we don't do this because it's less common and it causes a lot of bloat.)

If there is an element `<div class="article"><h2 class="muted">My Article</h2></div>`, then the
cascade will resolve such that the `h2` element will be `color: black` rather than `color: gray` as would be dictated under the definition I gave initially. You probably prefer this given your initial ask that the specificity/document order of the `A` selector matters, but it is an inconsistency dictated by the specific implementation that Sass is forced to use and was not what we ultimately wanted for an in-browser implementation of `@extend`.

Specifically, `@extend` was created to obviate the error-prone pattern of developers needing to apply multiple selectors in conjunction with each other in the document in order to implement "selector inheritance" as was commonly done in OOCSS and SMACSS approaches to css architecture.


-- 
GitHub Notification of comment by chriseppstein
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1855#issuecomment-335326574 using your GitHub account

Received on Tuesday, 10 October 2017 00:41:03 UTC