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

@jonathantneal This is a not uncommon misconception about `@extend`. Extend causes elements to "inherit" styles they wouldn't match otherwise. The behavior you describe in the example above is much more conceptually aligned with a kind of composition. Composition and Inheritance often degenerate into very similar concepts for trivial situations like the one you've constructed above but even there the differences of the two models are apparent.

But the behavior of extend that I (and @tabatkins) describe follows naturally from the syntactic choice to use selectors as the abstraction upon which the `@extend` directive is targeting. This is because selectors are not localized or unique, as soon as examples move away from simple selectors or to complex selectors, the behavior that you're describing becomes challenging, if not impossible, to define. Let's consider a more complex (albeit contrived) example:

```css
.article strong {
  font-weight: bolder;
}

.article em {
  font-weight: lighter;
}

section .important {
  @extend strong;
}

section em {
  font-weight: 100;
}

strong {
  font-weight: bold;
}

em {
  font-weight: 200;
}

section strong {
  font-weight: normal;
}

.important {
  @extend em;
}
```

Now consider the following document:

```html
<div id="id1" class="important">unscoped</div>
<div class="article">
   <span id="id2" class="important">important article text</span>
   <section>
     <span id="id3" class="important">important section text</span>
   </section>
</div>
<section>
   <p id="id4" class="important">important section paragraph</span>
</section>
```

Given those styles and this document what do you expect the `font-weight` to be for elements with ids 1-4?

If the specificity and document order of the selector `A` matters in determining the resolution of extended selectors it's unclear how that specificity and document order impacts the resolution. But if the extend directive is simply assigning additional html traits that could cause a selector to match, it becomes incredibly clear how the cascade resolves for `.important`.

If every document element can only be "extended" once, then the document order and specificity of the `A` selectors could be used to determine which one wins. But if that were the situation, the syntax should be changed to make `extend` a property, E.g. `A { extends: B, C, D; }` to match the semantic behavior of selector overrides. Personally, I don't think that design would be very useful.

Early in the design of Sass's `@extend` directive we considered an alternative syntax `@extend A like B;` or something along those lines. Such a syntax could be restricted to the start of a document before any ruleset -- we thought that design was less ergonomic than the syntax we chose, but I think it would have resulted in less confusion between inheritance and composition.

Ultimately, it seems like what you're asking for is the ability to assign a unique css-specific id to a single ruleset and then use it like a mixin at the call site. That's a fine feature, but it's not `@extend` and I think we shouldn't try to build such a concept on top of Sass's syntax with existing well-defined semantics.

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

Received on Tuesday, 10 October 2017 00:07:22 UTC