I see that many didn't read the hidden part of the post that explains why SCSS version can not be used.
Here's the relevant excerpt.
> ## Why can’t everything be directly nested?
> Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule.
> For example, if a parser starts by seeing color:hover ..., it can’t tell whether that’s the color property (being set to an invalid value...) or a selector for a <color> element. It can’t even rely on looking for valid properties to tell the difference; this would cause parsing to depend on which properties the implementation supported, and could change over time.
> Requiring directly-nested style rules to use nest-prefixed selectors works around this problem—an & can never be part of a declaration, so the parser can immediately tell it’s going to be parsing a selector, and thus a nested style rule.
> Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.
Thanks for pointing this out, I indeed missed that (it's hidden behind a folded caption).
It still doesn't explain why all the proposals feel the need to be more powerful than SCSS nesting (allowing "reverse nested" definitions where the element being nested in is not at the start), but it does explain the need for "&".
EDIT: Actually, it looks like SCSS supports the same thing by using '&' anywhere in the definition. I'll just stop posting since it looks like my knowledge is too rusty to contribute positively.
Thanks, I couldn't get it through the link since it's behind a "text fragment" link which only works on Chrome[1], a bit ironic if you ask me when we are discussing a standard :)
I assume that the requirements for a browser implementation are more strict than for existing pre-processors such as Sass because 1) the performance budget is much more limited for interactive use compared to pre-processing and 2) browsers need to handle adversarial inputs gracefully. Are there any other reasons?
The color:hover example seems like a pretty wild edge case. I'd be interested to see a more solid example of a 'boundless' lookahead requirement. In my simplistic view surely a strict mode that requires semicolons after properties (as opposed to commas or curly brackets after selectors) would do the trick?
Edit: I put together (painfully typed out on a phone) an example regex[1] to use the color:hover example. It isn't perfect, but it also isnt boundless.
Choosing only among the given proposals, what I see is one clear, concise and reasonably elegant syntax, and two ugly and noisy ones. Frankly it vaguely feels like the two latter options are there just to shepherd the ‘community’ (if there's such a thing) toward the least egregious variant and offer a semblance of discussion. It's not even necessarily bad that there's one obviously best option, if it's dictated by technical constraints—just, why bother me with the other two?
If they're seriously considering the latter two options for us to be stuck with, that's very concerning, and I'll be nervous about the whole affair until something definite rolls out.
Of course, it might be that the syntax authors foresaw some future problems that I don't, but their arguments aren't provided.
In fact, I don't even see why the `@nest` marker is necessary at all. The W3C draft says, “Some valid nesting selectors, like `.foo &`, are disallowed”—but why? They introduced the `&` marker to tell nesting rules apart from anything else, but then it turns out that they can't do that with the marker either? See `&` anywhere in the selector, realize it's a nesting—how much lookahead is needed for this? `&` can't be in a property name or media rule, can it? Surely there's a reason for this constraint, only I can't figure it out—granted, I barely know anything about implementing a CSS parser.
(Update: text cited by @pointlessone notes that a nest-selector might look like `color:hover & something`, which is indeed quite wacky and apparently befuddles the parser.)
Also, philosophically, a more-verbose marker like `@nest` would help avoid the growth of ascii salad in the syntax (the way that Python and Lisp avoid it, compared to Bash and Perl)—specifically if the marker was used instead of both `@nest` and `&` together in those proposals. However, it's probably not such an issue in regard to a feature that's gonna get plenty of exercise and is practically core functionality.
If i read this right, the only reason we can't just use & anywhere in the selector without some funky @nest indicator, is that browser vendors don't want their css parser to have unbounded lookahead just to figure out if something is a selector or a property.
I gotta say, this strikes me as rather developer hostile. Now, developers have to appease a crippled parser by injecting @nest (or a billion brackets) strategically. The amount of devs that are going to have to scratch their heads at each of these three weird proposals is way more than the amount of devs building CSS parsers, so I think they don't have their priorities straight.
I mean, in the 99.9% case, nested selectors are going to be at most some reasonable amount of tokens long. I understand wanting to avoid too many heap allocations but if that's the only issue, would it be that big a hack to first try to parse it with a bounded (but reasonably long) lookahead, and just reparse the whole thing in "insane CSS" mode with mallocs all over the place if the bounded one errors out? That way virtually all sites keep the fast small CSS parser and if some web dev really much challenge the engine with obscene code, it's supported but slow. They do this all over the JS engine, why can't CSS get a teeny tiny little bit of that attitude if it means CSS stays easy (enough) to learn?
Stuff like that is, however, complex. Complexity breeds both slowness, expense to implement, and security risks (at the very least DoS risks). It may also require a pretty significant rearchitecture of existing css parsers, which will hinder adoption. It also makes future competing browser engines that little bit less likely.
There's a bit of tradeoff here of devs vs. users.
But regardless, I think the implicit syntax (as is) is clearly the worst anyhow - because it's important even for devs to avoid syntax with gotcha cases. Unfortunately the optional/implicit style can't always avoid @nest, and precisely in more complex cases it is required. That makes those even more confusing; I'm not a fan of adding complexity precisely where it hurts most, even if it's a little shorter in some cases.
Had the implicit syntax _always_ allowed omitting @nest it'd be a different story, that's clearly best, but if browser-manufacturer's refuse that option, well, then let's not make it optional only in some cases.
Personally, I'm not sold that this is a great feature at all, because nesting encourages high selector specificity, and tightly coupled details of the dom structure with css. That's still a recipe for specificity battles and refactoring gotchas, no matter the syntax. Nesting is a dangerous feature because it's pretty attractive superficially, but leads to pain way later in the development process: not good.
In some niche cases (e.g. for pseudo-elements or media queries) there's never a maintainability problem with nesting, and hey, those are some of the cases where there's no parser ambiguity either, even with the implicit nesting syntax! I'd rather CSS restricted the nesting feature to those sane choices, than repeat SCSS's mistakes.
These all feel like an overengineered solution in search of a problem, with some degree of tunnel vision in that all three proposals try to support the same broad set of capabilities.
It looks like somebody decided that nesting support must somehow support "reverse nesting", eg. that you'd like to define what happens to .foo when it's inside a .bar, but nested inside the definition for .foo:
.foo {
.bar > .foo {
...
}
}
Does anybody actually want this? It feels counter-intuitive and weird, and with the syntaxes proposed, seems to provides little benefit compared to just doing it as the old ".bar > .foo" without nesting.
If you drop the requirement for nesting to work in reverse, you can just go with the proven SCSS syntax which is extremely clear, straightforward to use, and requires 0 extra characters typed.
EDIT: Apparently the '&' or some other special token is required to prevent the need for unlimited lookahead while parsing. This is actually explained behind a folded caption in the article, which I initially missed.
To play devil's advocate: there's a case to be made that reverse nesting is precisely the the _most reasaonable_ case for nesting, and that forward nesting is the one to be avoided.
The problem with nesting is that it is seductively easy to write, but encourages two coding issues that cause maintenance headaches later on. Firstly, it encourages high selector specificity, and that means potentially enjoying specificity battles later on. Secondly, it encourages tightly coupled DOM structure with CSS - and tight coupling makes later development more expensive.
Both of these issues are significantly less serious when using reverse nesting than forward nesting.
Forward nesting allows for expressing the concept of "parts of a component" by it's DOM structure, so when the component is tweaked, selectors that aren't explicitly tied to any part of a component suddenly break. But reverse nesting is more natural to use in the context of expressing a special case; i.e. my thingmabob is generally green, but in this specific context it's grey.
So on coupling, reverse nesting is less risky: whil it's not impossible to "compress" your css and thus introduce coupling between component structure and a reverse nested selector, it's not a very natural mistake to make.
And on specificity too, reverse nesting is less likely to cause surprises - after all, since you're expressing a more specific situation, you're almost always likely to want the nested selector to win that specificity battle.
So, I'd argue that reverse-nested selectors are actually one of the few general class of nested CSS selectors that are unlikely to cause maintenance headaches later on. Similarly harmless are nested media selectors (again, because nesting implies expressing an exception), and nested pseudo-elements (because there structure and CSS are intrinsically coupled an expressed within the CSS anyhow).
What you call "reverse nesting" is actually the only best good kind of nesting. QED?
Just piping up to say yes, absolutely want the ability to put the `&` anywhere. Your example isn't exactly correct, what I use it for is adjusting styles of the element I'm referring to based on a parent class. The `&` isn't automatically prepended - it puts the element reference in the spot it sits in the CSS. In your example, the `.bar` would be the parent class that is adjusting the styles of the current element.
For: `@nest .bar > & { ... } }` (just using the first syntax for simplicity here)
That doesn't translate to: `.foo { .bar > .foo { ... } }`
Apologies if I misunderstand, but your "reverse nesting" syntax already works with scss. I.e. `.a{ .b & {}}` => `.b .a {}` ... I'd quite honestly use it fairly often, usually with state/data modifiers on an ancestor (or ancestor sibling!)
The cat is out of the bag but, one fear i have is how easy it is to abuse nested selectors this way. When I first was exposed to SCSS I also started seeing selectors like `.helpPage .faqSection .sidebar ul li` in lots of codebases I touched because it seems so neat and tidy in SCSS and made it easy to make that CMS generated list look just the way you want it to without injecting local class= attributes. Then 6 months later you want to restructure your containers and all your magic selectors work differently. Deep nesting is a trap those of us who have tried to maintain SCSS eventually learn and we use all sorts of naming conventions (e.g. BEM) to avoid it but for beginners having it there without tooling will probably mean we see even more of it in the wild at first.
Edit: I still voted for `@nest` -- CCS is a pretty complex language for sure but I think it's terse expressiveness is why it's been successful.
I agree in regards to people abusing selectors, but I see that kind of code even without nesting. People don't understand (and IMO don't bother to learn) CSS specificity. Then they wonder why their CSS falls over.
Perhaps I simply don't see the ambiguity after having used Scss, Less and the like for a long time, but isn't the simple `&` by far the best option here? The other two are absurdly verbose without offering any real benefit.
IMO this is one of the things, like TypeScript, where transpiling before hitting the browser is good enough considering the downsides of baking this into three web engines.
Obviously `@nest always` and `brackets` are the same in disguise, and are here cause they're conceptually cleaner.
The problem with both of these is that they're unnecessarily verbose.
Why not have a shorter token than `@nest` and something that doesn't want more indenting (like `{}`)? For example `\`? And then if you want to make things a little less verbose, just assume the first character is going to be `&` cause that's going to be 99% of use cases.
Isn't that effectively what you get with the first option (with the `&` character)? You don't need `@nest` unless you want to embed the ampersand as anything other than the first character (which, I'll admit, is one of my major use cases). But given the prevalence of @ elements in CSS already (like @media for example), I'm ok learning/teaching @nest for those specific cases.
For me, the "equivalent css" is the most readable form in most of the examples given.
I can understand how this would be useful in some situations. However, from a practical perspective, I've found that writing nested CSS ends up creating a tight coupling between DOM structure and style rules which makes everything more brittle and harder to refactor [1].
I've personally been spoiled by the scoped styles in Vue [2] which makes this style of isolation in CSS mostly unnecessary. It serves a similar purpose as related encapsulation ideas like shadow DOM, BEM, CSS modules, and styled components.
Yes, I cannot agree more. I did the survey in the vain hope that I could leave a comment or even vote for “no nesting”, i.e. “equivalent CSS”. Most of the given examples are great evidence – some concerningly great evidence – for Tim Petersʼ “flat is better than nested”:
I think option 1 is the worst, because it's not actually optional; it's required precisely when css selectors become complex. That the kind of gotcha that just makes everything harder to explain and read.
I hope the proposal fails entirely, and that no nesting syntax is adopted. It's not worth it, and nesting in SCSS is abused more often than not anyhow.
There are a few exceptions like pseudo-elements and media queries that are always harmless, but most nesting is just asking for specificity gotchas later, or component refactoring surprises.
Languages that transpile to CSS require extra tooling and setup, and if there's one thing our web apps have too much of it's tooling and setup. I will be able to make much stronger cases to get rid of SASS, SCSS etc when this happens.
No crazy selectors with an ampersand in the middle allowed, but a way to apply a parent or ancestor selector, a bit like :where() or :is(). There could be :in() for ancestors.
I'd be happy if they just left it here. You can only nest pseudo-classes and pseudo-selectors, and everything else either use your own tool to generate the CSS or just not not nest.
Honestly, if SCSS works, then I don’t see how they can say it’ll be a problem in the browser. It already works, lets not require everyone to redo everything they already have.
Have the browser show a warning in the style of “An unbounded lookahead is making this page slow” when, and if it happens, and the site owner can do something about that crazy thing.
I feel like easy nesting shouldn't be included in CSS. The only few times it's actually useful and harmless to have nesting in Sass is when we want to do stuff like styling anchor's hover and focus styles at the same time. And this is already solved in CSS with :is() and :where().
Most of the time I see nesting used, it ends up either in a stylesheet that is less readable than without it, or in generating css classes that are way more specific than necessary.
Thinking about this as someone who teaches web dev: this shouldn't happen. As others have mentioned, this goes just far-enough past the scope of CSS to just leave as a pre-processor feature. This will be an absolute nightmare for beginners and lead to a lot of messes/time wasted chasing bugs.
If you can't get the as-is SCSS syntax natively without a bunch of hacks, it shouldn't be done (a bummer, as I'd love to have that natively).
What could (should?) happen is codifying a pre-processor model into the standards track. Have a standard and then make some library the reference implementation.
I'm reminded of OCaml's `let rec` which I'm somewhat surprised to not see any mention of, neither here nor the w3c's GitHub issues (https://github.com/w3c/csswg-drafts/issues). I was originally thinking of only treating nesting from a parent to child but the child to parent relationship does complicate things (especially since it seems much more likely with CSS to need to modify a parent - assigned from a library or framework, presumably - than typical imperative or functional programming). I originally thought a decorator-type syntax where "this definition includes nested elements" would be reasonable, since any user agent or linter or whatever could be in its rights (depending on spec) to look ahead a certain distance. Obviously this wouldn't actually be too reasonable with arbitrarily distant children.
Anyway, I also initially thought I preferred the brackets since it's explicit and some of the best wording is odd to me, but I think after considering my own `let rec` idea I prefer the optional `@nest` syntax because the only odd case which is relevant - and often enough that succinct but obvious syntax is warranted - is the child->parent->* case. That's the only time I'd want a heads up while visibly parsing css.
[+] [-] pointlessone|3 years ago|reply
Here's the relevant excerpt.
> ## Why can’t everything be directly nested?
> Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule.
> For example, if a parser starts by seeing color:hover ..., it can’t tell whether that’s the color property (being set to an invalid value...) or a selector for a <color> element. It can’t even rely on looking for valid properties to tell the difference; this would cause parsing to depend on which properties the implementation supported, and could change over time.
> Requiring directly-nested style rules to use nest-prefixed selectors works around this problem—an & can never be part of a declaration, so the parser can immediately tell it’s going to be parsing a selector, and thus a nested style rule.
> Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.
[+] [-] krajzeg|3 years ago|reply
It still doesn't explain why all the proposals feel the need to be more powerful than SCSS nesting (allowing "reverse nested" definitions where the element being nested in is not at the start), but it does explain the need for "&".
EDIT: Actually, it looks like SCSS supports the same thing by using '&' anywhere in the definition. I'll just stop posting since it looks like my knowledge is too rusty to contribute positively.
[+] [-] franciscop|3 years ago|reply
[1] https://caniuse.com/url-scroll-to-text-fragment
[+] [-] mfsch|3 years ago|reply
[+] [-] somishere|3 years ago|reply
Edit: I put together (painfully typed out on a phone) an example regex[1] to use the color:hover example. It isn't perfect, but it also isnt boundless.
[1] https://regex101.com/r/aOc2Pz/1
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] account42|3 years ago|reply
[+] [-] scotty79|3 years ago|reply
[+] [-] miragecraft|3 years ago|reply
[+] [-] wruza|3 years ago|reply
[+] [-] aasasd|3 years ago|reply
If they're seriously considering the latter two options for us to be stuck with, that's very concerning, and I'll be nervous about the whole affair until something definite rolls out.
Of course, it might be that the syntax authors foresaw some future problems that I don't, but their arguments aren't provided.
In fact, I don't even see why the `@nest` marker is necessary at all. The W3C draft says, “Some valid nesting selectors, like `.foo &`, are disallowed”—but why? They introduced the `&` marker to tell nesting rules apart from anything else, but then it turns out that they can't do that with the marker either? See `&` anywhere in the selector, realize it's a nesting—how much lookahead is needed for this? `&` can't be in a property name or media rule, can it? Surely there's a reason for this constraint, only I can't figure it out—granted, I barely know anything about implementing a CSS parser.
(Update: text cited by @pointlessone notes that a nest-selector might look like `color:hover & something`, which is indeed quite wacky and apparently befuddles the parser.)
Also, philosophically, a more-verbose marker like `@nest` would help avoid the growth of ascii salad in the syntax (the way that Python and Lisp avoid it, compared to Bash and Perl)—specifically if the marker was used instead of both `@nest` and `&` together in those proposals. However, it's probably not such an issue in regard to a feature that's gonna get plenty of exercise and is practically core functionality.
[+] [-] skrebbel|3 years ago|reply
I gotta say, this strikes me as rather developer hostile. Now, developers have to appease a crippled parser by injecting @nest (or a billion brackets) strategically. The amount of devs that are going to have to scratch their heads at each of these three weird proposals is way more than the amount of devs building CSS parsers, so I think they don't have their priorities straight.
I mean, in the 99.9% case, nested selectors are going to be at most some reasonable amount of tokens long. I understand wanting to avoid too many heap allocations but if that's the only issue, would it be that big a hack to first try to parse it with a bounded (but reasonably long) lookahead, and just reparse the whole thing in "insane CSS" mode with mallocs all over the place if the bounded one errors out? That way virtually all sites keep the fast small CSS parser and if some web dev really much challenge the engine with obscene code, it's supported but slow. They do this all over the JS engine, why can't CSS get a teeny tiny little bit of that attitude if it means CSS stays easy (enough) to learn?
[+] [-] emn13|3 years ago|reply
There's a bit of tradeoff here of devs vs. users.
But regardless, I think the implicit syntax (as is) is clearly the worst anyhow - because it's important even for devs to avoid syntax with gotcha cases. Unfortunately the optional/implicit style can't always avoid @nest, and precisely in more complex cases it is required. That makes those even more confusing; I'm not a fan of adding complexity precisely where it hurts most, even if it's a little shorter in some cases.
Had the implicit syntax _always_ allowed omitting @nest it'd be a different story, that's clearly best, but if browser-manufacturer's refuse that option, well, then let's not make it optional only in some cases.
Personally, I'm not sold that this is a great feature at all, because nesting encourages high selector specificity, and tightly coupled details of the dom structure with css. That's still a recipe for specificity battles and refactoring gotchas, no matter the syntax. Nesting is a dangerous feature because it's pretty attractive superficially, but leads to pain way later in the development process: not good.
In some niche cases (e.g. for pseudo-elements or media queries) there's never a maintainability problem with nesting, and hey, those are some of the cases where there's no parser ambiguity either, even with the implicit nesting syntax! I'd rather CSS restricted the nesting feature to those sane choices, than repeat SCSS's mistakes.
[+] [-] int_19h|3 years ago|reply
[+] [-] krajzeg|3 years ago|reply
It looks like somebody decided that nesting support must somehow support "reverse nesting", eg. that you'd like to define what happens to .foo when it's inside a .bar, but nested inside the definition for .foo:
.foo { .bar > .foo { ... } }
Does anybody actually want this? It feels counter-intuitive and weird, and with the syntaxes proposed, seems to provides little benefit compared to just doing it as the old ".bar > .foo" without nesting.
If you drop the requirement for nesting to work in reverse, you can just go with the proven SCSS syntax which is extremely clear, straightforward to use, and requires 0 extra characters typed.
EDIT: Apparently the '&' or some other special token is required to prevent the need for unlimited lookahead while parsing. This is actually explained behind a folded caption in the article, which I initially missed.
[+] [-] emn13|3 years ago|reply
The problem with nesting is that it is seductively easy to write, but encourages two coding issues that cause maintenance headaches later on. Firstly, it encourages high selector specificity, and that means potentially enjoying specificity battles later on. Secondly, it encourages tightly coupled DOM structure with CSS - and tight coupling makes later development more expensive.
Both of these issues are significantly less serious when using reverse nesting than forward nesting.
Forward nesting allows for expressing the concept of "parts of a component" by it's DOM structure, so when the component is tweaked, selectors that aren't explicitly tied to any part of a component suddenly break. But reverse nesting is more natural to use in the context of expressing a special case; i.e. my thingmabob is generally green, but in this specific context it's grey.
So on coupling, reverse nesting is less risky: whil it's not impossible to "compress" your css and thus introduce coupling between component structure and a reverse nested selector, it's not a very natural mistake to make.
And on specificity too, reverse nesting is less likely to cause surprises - after all, since you're expressing a more specific situation, you're almost always likely to want the nested selector to win that specificity battle.
So, I'd argue that reverse-nested selectors are actually one of the few general class of nested CSS selectors that are unlikely to cause maintenance headaches later on. Similarly harmless are nested media selectors (again, because nesting implies expressing an exception), and nested pseudo-elements (because there structure and CSS are intrinsically coupled an expressed within the CSS anyhow).
What you call "reverse nesting" is actually the only best good kind of nesting. QED?
[+] [-] LocalPCGuy|3 years ago|reply
For: `@nest .bar > & { ... } }` (just using the first syntax for simplicity here)
That doesn't translate to: `.foo { .bar > .foo { ... } }`
It's actually just: `.bar > .foo { ... } }`
[+] [-] somishere|3 years ago|reply
[+] [-] dieulot|3 years ago|reply
.button { @nest div.small-print & {
a { @nest :not(nav) & {
Including the body:
.button { @nest body.has-js & {
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] akdor1154|3 years ago|reply
[+] [-] amichal|3 years ago|reply
Edit: I still voted for `@nest` -- CCS is a pretty complex language for sure but I think it's terse expressiveness is why it's been successful.
[+] [-] LocalPCGuy|3 years ago|reply
[+] [-] Etheryte|3 years ago|reply
[+] [-] esteth|3 years ago|reply
[+] [-] saagarjha|3 years ago|reply
[+] [-] d--b|3 years ago|reply
Obviously `@nest always` and `brackets` are the same in disguise, and are here cause they're conceptually cleaner.
The problem with both of these is that they're unnecessarily verbose.
Why not have a shorter token than `@nest` and something that doesn't want more indenting (like `{}`)? For example `\`? And then if you want to make things a little less verbose, just assume the first character is going to be `&` cause that's going to be 99% of use cases.
And then you get something like this:
But no one ever listens to me![+] [-] LocalPCGuy|3 years ago|reply
[+] [-] indirectlylit|3 years ago|reply
I can understand how this would be useful in some situations. However, from a practical perspective, I've found that writing nested CSS ends up creating a tight coupling between DOM structure and style rules which makes everything more brittle and harder to refactor [1].
I've personally been spoiled by the scoped styles in Vue [2] which makes this style of isolation in CSS mostly unnecessary. It serves a similar purpose as related encapsulation ideas like shadow DOM, BEM, CSS modules, and styled components.
[1] https://csswizardry.com/2012/05/keep-your-css-selectors-shor...
[2] https://vue-loader.vuejs.org/guide/scoped-css.html
[+] [-] Mlller|3 years ago|reply
(1 and 2:)
(3:) (Without nesting:) The nested variants, for my sense, foreshadow grave technical debt – in specs, docs, browser code and CSS files.[+] [-] di4na|3 years ago|reply
All of them are atrocious to type and parse for a human.
The option 1 is probably the best but urgh
[+] [-] emn13|3 years ago|reply
I hope the proposal fails entirely, and that no nesting syntax is adopted. It's not worth it, and nesting in SCSS is abused more often than not anyhow.
There are a few exceptions like pseudo-elements and media queries that are always harmless, but most nesting is just asking for specificity gotchas later, or component refactoring surprises.
[+] [-] donatj|3 years ago|reply
[+] [-] progbits|3 years ago|reply
The 3rd party CSS tooling can pick whatever syntax it wants because it is starting on a green field. Browser probably can't?
[+] [-] somehnacct3757|3 years ago|reply
[+] [-] mrcartmeneses|3 years ago|reply
[+] [-] LAC-Tech|3 years ago|reply
Languages that transpile to CSS require extra tooling and setup, and if there's one thing our web apps have too much of it's tooling and setup. I will be able to make much stronger cases to get rid of SASS, SCSS etc when this happens.
[+] [-] coxmichael|3 years ago|reply
No one needs this monstrosity:
[+] [-] toastal|3 years ago|reply
[+] [-] toastal|3 years ago|reply
[+] [-] Aeolun|3 years ago|reply
Have the browser show a warning in the style of “An unbounded lookahead is making this page slow” when, and if it happens, and the site owner can do something about that crazy thing.
[+] [-] wwalexander|3 years ago|reply
Didn’t they mean “implemented in Chrome and therefore forced into the CSS standard due to browser monoculture”?
[+] [-] jaffathecake|3 years ago|reply
[+] [-] Leimi|3 years ago|reply
Most of the time I see nesting used, it ends up either in a stylesheet that is less readable than without it, or in generating css classes that are way more specific than necessary.
[+] [-] rglover|3 years ago|reply
If you can't get the as-is SCSS syntax natively without a bunch of hacks, it shouldn't be done (a bummer, as I'd love to have that natively).
What could (should?) happen is codifying a pre-processor model into the standards track. Have a standard and then make some library the reference implementation.
[+] [-] harrisi|3 years ago|reply
Anyway, I also initially thought I preferred the brackets since it's explicit and some of the best wording is odd to me, but I think after considering my own `let rec` idea I prefer the optional `@nest` syntax because the only odd case which is relevant - and often enough that succinct but obvious syntax is warranted - is the child->parent->* case. That's the only time I'd want a heads up while visibly parsing css.
[+] [-] cphoover|3 years ago|reply