- From: Martin Janecke via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 May 2016 23:03:20 +0000
- To: public-css-archive@w3.org
Yes, I fully agree that removing things from the spec that aren’t going to be implemented is the right thing to do. I didn’t mean to suggest anything else. I have difficulties to understand why `@scope` has nothing to do with nesting as done by CSS pre-proccessors though. To me all these have the same effect: Less: #header { color: black; .navigation { font-size: 12px; } .logo { width: 300px; } } Scoped CSS: #header { color:black; } @scope #header { .navigation { font-size: 12px; } .logo { width: 300px; } } CSS: #header { color: black; } #header .navigation { font-size: 12px; } #header .logo { width: 300px; } Now that you’ve said it, I have found the css-nesting draft which does offer some useful features. Using it, the same code as above would look like this, if I’m not mistaken: Nested CSS: #header { color: black; & .navigation { font-size: 12px; } & .logo { width: 300px; } } It looks quite similar to the Less code, maybe even more so than the scoped code, but due to the `&` in every rule, nested CSS can’t do what both Less nesting and `@scope` achieve: Take some CSS code, say h2 {color: red} p {color: green} and encapsulate the whole code without modifications by nesting/scoping it with a container element’s ID. Less: #container { h2 {color: red} p {color: green} } Scoped CSS: @scope #container { h2 {color: red} p {color: green} } So, in this case, I’d say that the pre-processor’s nesting has more to do with css-scoping than with css-nesting. I may be wrong though. -- GitHub Notification of comment by prlbr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/137#issuecomment-222271325 using your GitHub account
Received on Friday, 27 May 2016 23:03:21 UTC