- 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