W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2017

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

From: Jonathan Neal via GitHub <sysbot+gh@w3.org>
Date: Mon, 09 Oct 2017 22:08:41 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-335303794-1507586907-sysbot+gh@w3.org>
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**.

```css
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 https://github.com/w3c/csswg-drafts/issues/1855#issuecomment-335303794 using your GitHub account
Received on Monday, 9 October 2017 22:08:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:19 UTC