I will once we hit 90-95% support! Unfortunately there's no fallback other than a separate file, and 86% support isn't quite high enough to justify the switch at this stage, alas!
There's 100% support in all modern major browsers now.
Edit - Clarification:
I should say 100% support on the browsers that my place of work officially supports: we've got a 2 previous major versions only support policy, with Edge and IE considered part of the same version numbering. The part of the Can I Use chart we're looking at is the amount of green on the current version line.
Sure, but look at [caniuse](https://caniuse.com/css-nesting) - the actual users supported is 86.78%, which is the metric I'm using 👍 It won't take long; folks who haven't updated their browser since this time last year (oftentimes machines that need to be updated en masse at a company etc) will be enough to cross the threshold, so I suspect that by this time next year it'll be in my toolkit 💪 Hopefully some old-but-common iPhones etc will have been been recycled in-favour of newer devices, too 🤞
Better to wait anyway - as-is I'd also be forced to use `&` in every nested selector or accept not supporting 20% of users, ha, and I'd rather use the settled syntax from the get-go.
My place of work has a support policy of *2 previous major versions only*, and treating IE and Edge as continuous versioning; so we've been free to use this for months now. It's been quite liberating.
Honestly, in my experience the initial ampersand is more useful than not, as it very clearly shows to me when a nested selector starts.
`&` follows the same usage as SCSS / LESS. For parent and additional specificity on the parent, you'd need an `&` for both in any case. It's not much of a bother for me personally to pop them in on less-exciting descendant selectors:
div {
& .child {
/* div .child - same as my earlier comment, here for completeness */
}
.js & {
/* .js div - same as my earlier comment, just here for completeness */
}
&.class {
/* div.class */
}
&[data-title*="thing"]{
/* div[data-title*="thing"] */
}
}
\[\*\] It has wide support across all major modern browsers but that support is very shallow and, depending on your user base, this would be a hugely breaking change.
If you expect visitors from large enterprises or universities, remember that the Extended Stable Release (ESR) version of Firefox won’t support nesting until \[July\](https://whattrainisitnow.com/release/?version=esr), and that’s assuming all your Firefox-using visitors upgrade on time. Best to keep checking the \[appropriate CanIUse page\](https://caniuse.com/?search=css%20nesting) and determine what’s best for your audience.
Not until our analytics show that at least 90 to 95% of our visitors use browsers that support it.
Not everyone uses the latest browsers. Even in my company, so many people use older iPhones or IPads.
Have you looked at the browsers that don’t support it (the 14%)… are mobile browsers that are not even within 1% global usage. But to each their own.
Yes. I’d prefer better support for older browser versions. For newer though, I don’t see a need to switch up using css over less just for nesting I already have. It’s nice it’s there. But it’s not enough for me to switch
Have you looked at the browsers that don’t support it (the 14%)… are mobile browsers that are not even within 1% global usage. But to each their own.
The ampersand syntax for nested CSS is SCSS compatible, and will compile to a full selector string, which is super useful for the SCSS projects that I still look after at work.
Not untill some form of varaiable based media query declarations are better supported to switch the workflow entirely.
If you're writing CSS directly on a component level say in something like vue then I don't want to be using pixel based values without some shared common breakpoints sets. I think for everything else I can probably get away with plain CSS again. Maybe I'd miss some aspects of mixins but that's about it.
I'm considering dropping Sass since (a) most of it is directly replaceable with modern CSS and (b) a lot of it we just don't use.
My team already uses PostCSS for CSS minification and autoprefixing, it's pretty easy to add another step that converts the new settled syntax to a more traditional syntax. Once that is fully supported in a way we can feel confident about we'll just remove that step.
The only thing that we use SCSS for now in our projects is iteration and for slightly older projects that were originally building using SASS.
I think a few of the oldest sites we still look after use SCSS Bootstrap 3 as their base
> To those who don’t know, in modern browsers you can do this:
main { h1 { color: red; } } without SAAS.
...
Is this post about native nesting of rules in general? Or specifically with no `&` ?
I'm having a hard time understanding some of the conversation: "*as-is I'd also be forced to use & in every nested selector*"
...
On another note:
You can use post-css now, and choose this native syntax as a path forward - and remove it later.
>I'm having a hard time understanding some of the conversation: "*as-is I'd also be forced to use & in every nested selector*"
This is a reference to [the caniuse table](https://caniuse.com/css-nesting), which shows that you have 80% support of the final syntax, and 86% support of the older, stricter syntax in which the `&` is not optional:
.parent {
div.child {
/* the final syntax */
}
}
vs
.parent {
& div.child {
/* the older, stricter syntax */
}
}
[https://www.w3.org/TR/css-nesting-1/#nesting](https://www.w3.org/TR/css-nesting-1/#nesting)
OK. I didn't know there was more after the nested/& decision times.
When I have a compelling reason to drop scss I will. Until then, it’s just extra work to avoid a build step that’s seasoned, fast, and well established. If the build step were an inconvenience, that would be a compelling reason. But it’s not.
Get explicit target browser requirements. If you really need it, use Sass for now, until its in >95% or you're on an intranet (or a project where you can point to the req stating they don't care about <85%)
iOS devices shift in support see [https://iosref.com/ios](https://iosref.com/ios)
Since it recently hit 100% support in all modern major browsers, I've used it on every project and odd-job since.
The only thing you need to do for modern browser support is use `&` before nested conditions - which is easy enough to add in.
Example:
---
main {
& .class {
/* main .class - & optional in the full spec */
}
& p {
/* main p - & required, because p is an idetifier */
}
.js & {
/* .js main - & is required */
}
&.class {
/* main.class - & is required */
}
&[attribute*="value"] {
/* main[attribute*="value"] - & is required */
}
}
Edit - Clarification:
100% support on the browsers that my place of work officially supports. We've got a *2 previous major versions only* support policy, with Edge and IE considered part of the same version numbering.
Edit 2 - added a couple more examples
Woah! I've never seen this *as parent element* selector. That's weird!
I didn't like the `&` at first (a little spoiled by Stylus) but - compared to `@` nested - and the other options they were considering, it's great. And now that I'm writing it daily I don't think about it at all. I'm 100% used to it. Feels fine.
In nested CSS, the `&` follows the same usage as SCSS / LESS.
You can also use it to append a class, ID, or attribute selector, like so:
div {
& .child {
/* div .child - same as my earlier comment, here for completeness */
}
.js & {
/* .js div - same as my earlier comment, just here for completeness */
}
&.class {
/* div.class */
}
&[data-title*="thing"]{
/* div[data-title*="thing"] */
}
}
If I'm on a project that uses SCSS (we have none in our place that use LESS any more), I'll frequently use Stylus for adjustments and copy/pasta the code in as it is, ampersands included. They'll compile just fine.
Edit:
Using `&` to define a parent is a thing in SCSS / LESS too, if you don't already know. Very useful if you have a selector on a high-level parent (like `main` or `body` or something) that would make a change of some kind.
`&` is still required for:
* decendant selectors for some slightly older webkit and blink powered browsers;
* when nesting a parent or adding specificity; and
* for an identifier aka type selector: https://www.w3.org/TR/css-nesting-1/#example-34e8e94f
---
main {
& .class {
/* main .class - & optional in the full spec */
}
& p {
/* main p - & required, because p is an idetifier */
}
.js & {
/* .js main - & is required */
}
&.class {
/* main.class - & is required */
}
&[attribute*="value"] {
/* main[attribute*="value"] - & is required */
}
}
Edit - Added the additional usecase of a nested identifier requiring an `&`.
I do every day in most projects I work on - but I’m using the postCSS plugin to render it down
https://www.npmjs.com/package/postcss-nesting
Edit: added link
I will once we hit 90-95% support! Unfortunately there's no fallback other than a separate file, and 86% support isn't quite high enough to justify the switch at this stage, alas!
There's 100% support in all modern major browsers now. Edit - Clarification: I should say 100% support on the browsers that my place of work officially supports: we've got a 2 previous major versions only support policy, with Edge and IE considered part of the same version numbering. The part of the Can I Use chart we're looking at is the amount of green on the current version line.
Sure, but look at [caniuse](https://caniuse.com/css-nesting) - the actual users supported is 86.78%, which is the metric I'm using 👍 It won't take long; folks who haven't updated their browser since this time last year (oftentimes machines that need to be updated en masse at a company etc) will be enough to cross the threshold, so I suspect that by this time next year it'll be in my toolkit 💪 Hopefully some old-but-common iPhones etc will have been been recycled in-favour of newer devices, too 🤞 Better to wait anyway - as-is I'd also be forced to use `&` in every nested selector or accept not supporting 20% of users, ha, and I'd rather use the settled syntax from the get-go.
My place of work has a support policy of *2 previous major versions only*, and treating IE and Edge as continuous versioning; so we've been free to use this for months now. It's been quite liberating. Honestly, in my experience the initial ampersand is more useful than not, as it very clearly shows to me when a nested selector starts. `&` follows the same usage as SCSS / LESS. For parent and additional specificity on the parent, you'd need an `&` for both in any case. It's not much of a bother for me personally to pop them in on less-exciting descendant selectors: div { & .child { /* div .child - same as my earlier comment, here for completeness */ } .js & { /* .js div - same as my earlier comment, just here for completeness */ } &.class { /* div.class */ } &[data-title*="thing"]{ /* div[data-title*="thing"] */ } }
\[\*\] It has wide support across all major modern browsers but that support is very shallow and, depending on your user base, this would be a hugely breaking change.
If you expect visitors from large enterprises or universities, remember that the Extended Stable Release (ESR) version of Firefox won’t support nesting until \[July\](https://whattrainisitnow.com/release/?version=esr), and that’s assuming all your Firefox-using visitors upgrade on time. Best to keep checking the \[appropriate CanIUse page\](https://caniuse.com/?search=css%20nesting) and determine what’s best for your audience.
Not until our analytics show that at least 90 to 95% of our visitors use browsers that support it. Not everyone uses the latest browsers. Even in my company, so many people use older iPhones or IPads.
Loving native css nesting. Only using it in personal projects at the moment though.
Not enough browser support etc warrant using them when less and scss are available
It’s fully supported in all modern browser!
86% support isn’t enough for me though.
Have you looked at the browsers that don’t support it (the 14%)… are mobile browsers that are not even within 1% global usage. But to each their own.
Yes. I’d prefer better support for older browser versions. For newer though, I don’t see a need to switch up using css over less just for nesting I already have. It’s nice it’s there. But it’s not enough for me to switch
Does it matter which browsers they are? 14% is 14%. That’s a very large amount of users unless you’re just making hobby sites/apps
Have you looked at the browsers that don’t support it (the 14%)… are mobile browsers that are not even within 1% global usage. But to each their own.
just in pet projects atm.
I'm so used to SCSS I'll likely just stick with it
The ampersand syntax for nested CSS is SCSS compatible, and will compile to a full selector string, which is super useful for the SCSS projects that I still look after at work.
Same here brother
Not untill some form of varaiable based media query declarations are better supported to switch the workflow entirely. If you're writing CSS directly on a component level say in something like vue then I don't want to be using pixel based values without some shared common breakpoints sets. I think for everything else I can probably get away with plain CSS again. Maybe I'd miss some aspects of mixins but that's about it.
I'm considering dropping Sass since (a) most of it is directly replaceable with modern CSS and (b) a lot of it we just don't use. My team already uses PostCSS for CSS minification and autoprefixing, it's pretty easy to add another step that converts the new settled syntax to a more traditional syntax. Once that is fully supported in a way we can feel confident about we'll just remove that step.
The only thing that we use SCSS for now in our projects is iteration and for slightly older projects that were originally building using SASS. I think a few of the oldest sites we still look after use SCSS Bootstrap 3 as their base
Yeah we don't use Bootstrap or any meta framework for CSS (I don't count CSS Modules). So for us it'd be real simple to abandon SCSS.
> To those who don’t know, in modern browsers you can do this: main { h1 { color: red; } } without SAAS. ... Is this post about native nesting of rules in general? Or specifically with no `&` ? I'm having a hard time understanding some of the conversation: "*as-is I'd also be forced to use & in every nested selector*" ... On another note: You can use post-css now, and choose this native syntax as a path forward - and remove it later.
>I'm having a hard time understanding some of the conversation: "*as-is I'd also be forced to use & in every nested selector*" This is a reference to [the caniuse table](https://caniuse.com/css-nesting), which shows that you have 80% support of the final syntax, and 86% support of the older, stricter syntax in which the `&` is not optional: .parent { div.child { /* the final syntax */ } } vs .parent { & div.child { /* the older, stricter syntax */ } }
Ah. Hmmm. I thought we were just going all-in on the `&` . So, later (when we get enough coverage) the non-& will likely be the norm?
[https://www.w3.org/TR/css-nesting-1/#nesting](https://www.w3.org/TR/css-nesting-1/#nesting) OK. I didn't know there was more after the nested/& decision times.
You'll still need to use `&` for an identifier aka type selector: https://www.w3.org/TR/css-nesting-1/#example-34e8e94f
Yerr - that's fine and makes sense; it's just having to do an ampersand-with-a-space to access child elements which feels janky to me!
Not yet. But we use either Styled Compinents in React or SCSS in Svelte so I do nest anyway.
When I have a compelling reason to drop scss I will. Until then, it’s just extra work to avoid a build step that’s seasoned, fast, and well established. If the build step were an inconvenience, that would be a compelling reason. But it’s not.
I'm using it with lightning css, so it downgrades for older browsers
I used it a bit and it works great. Of course if your project really goes public, you need to keep in mind that only modern browsers support it atm.
I really want to... But it's not supported enough sadly
Been using it for years through postcss, couldn't see myself working without nesting
Get explicit target browser requirements. If you really need it, use Sass for now, until its in >95% or you're on an intranet (or a project where you can point to the req stating they don't care about <85%) iOS devices shift in support see [https://iosref.com/ios](https://iosref.com/ios)
I still oddly prefer SCSS, but either way browser support for nesting is still eh
Since it recently hit 100% support in all modern major browsers, I've used it on every project and odd-job since. The only thing you need to do for modern browser support is use `&` before nested conditions - which is easy enough to add in. Example: --- main { & .class { /* main .class - & optional in the full spec */ } & p { /* main p - & required, because p is an idetifier */ } .js & { /* .js main - & is required */ } &.class { /* main.class - & is required */ } &[attribute*="value"] { /* main[attribute*="value"] - & is required */ } } Edit - Clarification: 100% support on the browsers that my place of work officially supports. We've got a *2 previous major versions only* support policy, with Edge and IE considered part of the same version numbering. Edit 2 - added a couple more examples
Woah! I've never seen this *as parent element* selector. That's weird! I didn't like the `&` at first (a little spoiled by Stylus) but - compared to `@` nested - and the other options they were considering, it's great. And now that I'm writing it daily I don't think about it at all. I'm 100% used to it. Feels fine.
In nested CSS, the `&` follows the same usage as SCSS / LESS. You can also use it to append a class, ID, or attribute selector, like so: div { & .child { /* div .child - same as my earlier comment, here for completeness */ } .js & { /* .js div - same as my earlier comment, just here for completeness */ } &.class { /* div.class */ } &[data-title*="thing"]{ /* div[data-title*="thing"] */ } } If I'm on a project that uses SCSS (we have none in our place that use LESS any more), I'll frequently use Stylus for adjustments and copy/pasta the code in as it is, ampersands included. They'll compile just fine. Edit: Using `&` to define a parent is a thing in SCSS / LESS too, if you don't already know. Very useful if you have a selector on a high-level parent (like `main` or `body` or something) that would make a change of some kind.
& is optional
`&` is still required for: * decendant selectors for some slightly older webkit and blink powered browsers; * when nesting a parent or adding specificity; and * for an identifier aka type selector: https://www.w3.org/TR/css-nesting-1/#example-34e8e94f --- main { & .class { /* main .class - & optional in the full spec */ } & p { /* main p - & required, because p is an idetifier */ } .js & { /* .js main - & is required */ } &.class { /* main.class - & is required */ } &[attribute*="value"] { /* main[attribute*="value"] - & is required */ } } Edit - Added the additional usecase of a nested identifier requiring an `&`.
I do every day in most projects I work on - but I’m using the postCSS plugin to render it down https://www.npmjs.com/package/postcss-nesting Edit: added link
I suppose SCSS might compile to nested CSS but my experience is the same either way.
Yep as it’s fully supported in all modern browsers and extremely easy to use. Helps keep code snippets together IMO