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