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

Thanks for sharing your thoughts and explaining things so well, @chriseppstein. There is one thing I would like to understand better.

> 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.

Would you help me conceptualize this with an example? For instance, based on the following CSS, I would expect `<element class="foo bar">` to be **bolder**.

strong {
  font-weight: bolder;

.foo {
  font-weight: lighter;

.bar {
  @extend strong;

I would expect `<element class="foo bar">` to be **bolder** because I have placed `.bar` later in the cascade, and because I expect `@extend` to import other styles, but not import those styles’ original weight. Would you expect something different? If so, why?

I chose that example because it contrasts with what I expect Sass and Tab’s original spec to do. In Sass, it would be **lighter** because of how the cascade is re-ordered. In Tab’s original spec, it would also be **lighter** because the styles being inherited from `strong` have a lower specificity than `.foo`.

Please accept my apologies if you already answered this and I misunderstood you.

GitHub Notification of comment by jonathantneal
Please view or discuss this issue at using your GitHub account

Received on Monday, 9 October 2017 22:08:29 UTC