8 ms·

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

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.

krajzeg 4y ago
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.
- Semaphor 4y ago
  I’m not sure if I understand you correctly, but I think SCSS does actually support that. dialog { html:has(&[open]) { overflow: hidden; } } Is possible annd creates html:has(dialog[open]) {overflow: hidden;}
  - krajzeg 4y ago
    No, you're right. My SCSS is a bit rusty these days and I simply forgot how flexible it is, sorry for the misleading comment.
  - aasasd 4y ago
    This seems to slap the property on html, whereas the proposed nesting only uses the parent as a selector, and specifies properties for the nested element (if I'm not confusing something again). If scss can do `.parent & {...}`, that would be the same as the proposal.
somishere 4y ago
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. [1] https://regex101.com/r/aOc2Pz/1 https://regex101.com/r/aOc2Pz/1
- Hackbraten 4y ago
  Wouldn’t that break compatibility with existing websites?
  - somishere 4y ago
    Not if you only require strict mode for modern language incantations like nesting
    - Hackbraten 4y ago
      Then you’d have two diverging CSS dialects, which would add complexity, too.
- wruza 4y ago
  The problem is not to tell selector from definition (of course it can, otherwise grammar would be non-reducible). The problem is how far in an array of tokens the distinction can be seen. Parsers know the current state and where to go next out of previous reductions and a few lookaheads which they can use at places known to be clear of ambiguity in a ~fixed number of lookaheads. Parsing something that diverges only down few pages of tokens is problematic size/speed/algo-wise, but the question is how much does that cost really and who should pay. Edit: But honestly I think this is all wrong direction. Any technology, format, method has 1. features and 2. form. Form is irrelevant because you can make tools to convert any form into any. Features are important because you can’t add features by tooling. But $subj adds zero features, only a new form which is already feels like a compromise. Why do that then? We have to brush our tools instead, e.g. create default nginx-scss plugin, standalone scss caching servers etc. Then everyone could use extended syntax without resorting to all-in-one monstrosities like webpack.
wruza 4y ago
More efficient how much?
- lucideer 4y ago
  No way to measure that because the potential inefficiency is infinite - one would need to first work out the likelihood of very large unbounded lookaheads occurring in the wild. It's really less about benchmarking and more about managing risk: large unbounded lookahead in scss might crash a single concurrent pod in your CICD - isolated, detectable and really easily remedied. The same here could crash many users' browsers - not so easily fixed.
  - somishere 4y ago
    Can you elaborate exactly where the unbounded lookahead is required? I genuinely can't see it. I also don't see why a dramatic update like this couldn't also introduce / require a 'strict' style to be considered valid. I feel like we're talking serious edge cases here.
    - lucideer 4y ago
      > Can you elaborate ... I'm not sure I can think of a better explanation/examples than the gp. It essentially comes down to ambiguity between single element selector names (which are unprefixed in CSS - no dot or hash) and property keys (also plain identifiers). The only similar nested braces form we have in current CSS is always @-prefixed. There's no unprefixed equivalent for parent blocks in current syntax (plus those blocks are currently limited to a single level which I guess mightt simplify things further given the prefixed selector is always at root level) > I also don't see why a dramatic update like this couldn't also introduce / require a 'strict' style to be considered valid. I think it could and I think the call for input is open to that as a possibility. The above comment is just referring to a fully compatible direct scss implementation of nesting.
      - somishere 4y ago
        I get your point. However it relies on an example that actually requires an unbounded lookeahead. This is where I'm confused. Sure, these ambiguous blocks (I'm not sure how many examples there are other than color:hover) aren't prefixed, but they are conclusively postfixed. So any lookahead required should be easily bounded. Where does the unbounded aspect come into it? Reposting my earlier painfully phone-typed regex to illustrate the point: https://regex101.com/r/aOc2Pz/1 https://regex101.com/r/aOc2Pz/1 Edit: I should add that I don't doubt that those involved know what they're talking about. I know nothing of briwser-level CSS parsing. I am certain it is a nightmare. I would really just like a better example to explain the unbounded aspect. Especially when it is being given as the primary excuse to cripple / greatly obtusify a syntax I'm being asked for an opinion on. Maybe it's just me but I would expect that an evolution of this magnitude would afford a bit more compromise elsewhere.
mfsch 4y ago
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?
- mort96 4y ago
  One potential reason is, SCSS only needs one implementation, and whatever that implementation does is SCSS. If you write `color:hover { ... }` it doesn't really matter whether SCSS happens to parse that as a `color: hover` followed by an illegal `{` token or if it happens to parse it as a nested selector; whichever the parser chooses is fine. But in a standard, with multiple implementations, you need to strictly resolve all ambiguities in the spec so that all implementations parse CSS the same way; just avoiding ambiguities in the grammar is by far the easiest way to achieve that. Plus, different ways of implementing a parser could have different ways of resolving ambiguities. Maybe parsing `color:hover {}` as a selector happens to be super easy in Firefox's existing parser, but would require a rewrite of Chromium's parser, for example.
scotty79 4y ago
Are CSS parsers multithreaded? Maybe they should be? Maybe then a bit larger lookaheads woulndn't matter?
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- pointlessone 4y ago
  It's not a question of implementation power. It's about spec requirements. Until now CSS didn't require more than 1 token to know where we are. Basically, parser doesn't need to backtrack at all. SCSS apporach, for instance, requires look ahead. Consider: color:hover over some random markup & Currently CSS can be sure whether that is a selector or a property depending where it finds it. If it's in a ruleset or at-rule block, it's a selector. If it's in a declaration list, it's a property-value pair. Now, with nesting it becomes confusing. Parsers can not rely on the state to decide what they're looking at. One way to fix this is, like many suggested here, to require look-ahead from parser. Which can be a solution in a well defined environment. Unfortunately, the Web is not one of them. We have many underpowered kiosk-type devices that probably can not spare arbitrarily large look-ahead buffers. Another solution is to somehow let the parser know what it's looking at. That's why leading & is a good indicator it's a selector. & is not used for anything else in CSS. But for selectors where it's not first we need @nest (or anything else that unambiguously marks a selector). Look-ahead requirements are bad for another reason, too. It makes CSS platform-dependent. Currently any version of CSS clearly states what it provides. Implementations can be partial but they can not claim they support CSS 2.1, for example, when they don't implement 100% of it. Wit look-aheads things become murkier. An implementation can support 100% of the spec but depending on the look-ahead required to parse a stylesheet they might not work. Currently, I don't think there are any CSS features that depend on platform limitations, at least not for parsing. Requiring a look-ahead buffer to parse a stylesheet can be very problematic. Imagine, Twitter got hacked and their embeds started stylesheet have a couple selectors that require 1M tokens look-ahead buffer. How that would break every site that embeds tweets?
franciscop 4y ago
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 :) [1] https://caniuse.com/url-scroll-to-text-fragment https://caniuse.com/url-scroll-to-text-fragment
- clairity 4y ago
  what's also silly is using qualtrics for a single-question survey that has 5 screens, including the google captcha surveillance tracking injection.
- traek 4y ago
  It's accessible on any browser, you'd just need to scroll to the section manually if your browser doesn't support text fragment links.
  - franciscop 4y ago
    I needed to scroll to the section manually since my browser doesn't support it as shown clearly in the caniuse link I shared. It doesn't work for me and I provided general evidence, so how is it accessible on any browser?
  - WorldMaker 4y ago
    You know what is accessible on any browser that they could have done? Proper fragment links from HTML 1.x such as: https://www.w3.org/TR/css-nesting-1/#nesting https://www.w3.org/TR/css-nesting-1/#nesting The W3C document template even kindly provides a quick way to copy those links to every header using the section mark (§).
- JW_00000 4y ago
  Works for me in Firefox. It seems to just rely on a <details> element [1], which should work in all modern browsers [2]. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... [2] https://caniuse.com/details https://caniuse.com/details
account42 4y ago
How does the SCSS syntax differentiate between `& .childclass` and `&.additionalclass` without the ampersand?
- kevincox 4y ago
  It doesn't. If there is no ampersand it is assumed to start with `& `. So `.childclass` is equivelent to `& .childclass` and if you want something else you need to do `&.additionalclass` or `& + .additionalclass` or whatever you want.
deleted 4y ago
[deleted]
miragecraft 4y ago
Doesn't the :has() selector already cause unbounded lookahead?

krajzeg 4y ago

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.

Semaphor 4y ago
I’m not sure if I understand you correctly, but I think SCSS does actually support that. dialog { html:has(&[open]) { overflow: hidden; } } Is possible annd creates html:has(dialog[open]) {overflow: hidden;}
- krajzeg 4y ago
  No, you're right. My SCSS is a bit rusty these days and I simply forgot how flexible it is, sorry for the misleading comment.
- aasasd 4y ago
  This seems to slap the property on html, whereas the proposed nesting only uses the parent as a selector, and specifies properties for the nested element (if I'm not confusing something again). If scss can do `.parent & {...}`, that would be the same as the proposal.

somishere 4y ago

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. [1] https://regex101.com/r/aOc2Pz/1 https://regex101.com/r/aOc2Pz/1

Hackbraten 4y ago
Wouldn’t that break compatibility with existing websites?
- somishere 4y ago
  Not if you only require strict mode for modern language incantations like nesting
  - Hackbraten 4y ago
    Then you’d have two diverging CSS dialects, which would add complexity, too.
wruza 4y ago
The problem is not to tell selector from definition (of course it can, otherwise grammar would be non-reducible). The problem is how far in an array of tokens the distinction can be seen. Parsers know the current state and where to go next out of previous reductions and a few lookaheads which they can use at places known to be clear of ambiguity in a ~fixed number of lookaheads. Parsing something that diverges only down few pages of tokens is problematic size/speed/algo-wise, but the question is how much does that cost really and who should pay. Edit: But honestly I think this is all wrong direction. Any technology, format, method has 1. features and 2. form. Form is irrelevant because you can make tools to convert any form into any. Features are important because you can’t add features by tooling. But $subj adds zero features, only a new form which is already feels like a compromise. Why do that then? We have to brush our tools instead, e.g. create default nginx-scss plugin, standalone scss caching servers etc. Then everyone could use extended syntax without resorting to all-in-one monstrosities like webpack.

wruza 4y ago

More efficient how much?

lucideer 4y ago
No way to measure that because the potential inefficiency is infinite - one would need to first work out the likelihood of very large unbounded lookaheads occurring in the wild. It's really less about benchmarking and more about managing risk: large unbounded lookahead in scss might crash a single concurrent pod in your CICD - isolated, detectable and really easily remedied. The same here could crash many users' browsers - not so easily fixed.
- somishere 4y ago
  Can you elaborate exactly where the unbounded lookahead is required? I genuinely can't see it. I also don't see why a dramatic update like this couldn't also introduce / require a 'strict' style to be considered valid. I feel like we're talking serious edge cases here.
  - lucideer 4y ago
    > Can you elaborate ... I'm not sure I can think of a better explanation/examples than the gp. It essentially comes down to ambiguity between single element selector names (which are unprefixed in CSS - no dot or hash) and property keys (also plain identifiers). The only similar nested braces form we have in current CSS is always @-prefixed. There's no unprefixed equivalent for parent blocks in current syntax (plus those blocks are currently limited to a single level which I guess mightt simplify things further given the prefixed selector is always at root level) > I also don't see why a dramatic update like this couldn't also introduce / require a 'strict' style to be considered valid. I think it could and I think the call for input is open to that as a possibility. The above comment is just referring to a fully compatible direct scss implementation of nesting.
    - somishere 4y ago
      I get your point. However it relies on an example that actually requires an unbounded lookeahead. This is where I'm confused. Sure, these ambiguous blocks (I'm not sure how many examples there are other than color:hover) aren't prefixed, but they are conclusively postfixed. So any lookahead required should be easily bounded. Where does the unbounded aspect come into it? Reposting my earlier painfully phone-typed regex to illustrate the point: https://regex101.com/r/aOc2Pz/1 https://regex101.com/r/aOc2Pz/1 Edit: I should add that I don't doubt that those involved know what they're talking about. I know nothing of briwser-level CSS parsing. I am certain it is a nightmare. I would really just like a better example to explain the unbounded aspect. Especially when it is being given as the primary excuse to cripple / greatly obtusify a syntax I'm being asked for an opinion on. Maybe it's just me but I would expect that an evolution of this magnitude would afford a bit more compromise elsewhere.

mfsch 4y ago

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?

mort96 4y ago
One potential reason is, SCSS only needs one implementation, and whatever that implementation does is SCSS. If you write `color:hover { ... }` it doesn't really matter whether SCSS happens to parse that as a `color: hover` followed by an illegal `{` token or if it happens to parse it as a nested selector; whichever the parser chooses is fine. But in a standard, with multiple implementations, you need to strictly resolve all ambiguities in the spec so that all implementations parse CSS the same way; just avoiding ambiguities in the grammar is by far the easiest way to achieve that. Plus, different ways of implementing a parser could have different ways of resolving ambiguities. Maybe parsing `color:hover {}` as a selector happens to be super easy in Firefox's existing parser, but would require a rewrite of Chromium's parser, for example.

scotty79 4y ago

Are CSS parsers multithreaded? Maybe they should be? Maybe then a bit larger lookaheads woulndn't matter?

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
pointlessone 4y ago
It's not a question of implementation power. It's about spec requirements. Until now CSS didn't require more than 1 token to know where we are. Basically, parser doesn't need to backtrack at all. SCSS apporach, for instance, requires look ahead. Consider: color:hover over some random markup & Currently CSS can be sure whether that is a selector or a property depending where it finds it. If it's in a ruleset or at-rule block, it's a selector. If it's in a declaration list, it's a property-value pair. Now, with nesting it becomes confusing. Parsers can not rely on the state to decide what they're looking at. One way to fix this is, like many suggested here, to require look-ahead from parser. Which can be a solution in a well defined environment. Unfortunately, the Web is not one of them. We have many underpowered kiosk-type devices that probably can not spare arbitrarily large look-ahead buffers. Another solution is to somehow let the parser know what it's looking at. That's why leading & is a good indicator it's a selector. & is not used for anything else in CSS. But for selectors where it's not first we need @nest (or anything else that unambiguously marks a selector). Look-ahead requirements are bad for another reason, too. It makes CSS platform-dependent. Currently any version of CSS clearly states what it provides. Implementations can be partial but they can not claim they support CSS 2.1, for example, when they don't implement 100% of it. Wit look-aheads things become murkier. An implementation can support 100% of the spec but depending on the look-ahead required to parse a stylesheet they might not work. Currently, I don't think there are any CSS features that depend on platform limitations, at least not for parsing. Requiring a look-ahead buffer to parse a stylesheet can be very problematic. Imagine, Twitter got hacked and their embeds started stylesheet have a couple selectors that require 1M tokens look-ahead buffer. How that would break every site that embeds tweets?

franciscop 4y ago

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 :) [1] https://caniuse.com/url-scroll-to-text-fragment https://caniuse.com/url-scroll-to-text-fragment

clairity 4y ago
what's also silly is using qualtrics for a single-question survey that has 5 screens, including the google captcha surveillance tracking injection.
traek 4y ago
It's accessible on any browser, you'd just need to scroll to the section manually if your browser doesn't support text fragment links.
- franciscop 4y ago
  I needed to scroll to the section manually since my browser doesn't support it as shown clearly in the caniuse link I shared. It doesn't work for me and I provided general evidence, so how is it accessible on any browser?
- WorldMaker 4y ago
  You know what is accessible on any browser that they could have done? Proper fragment links from HTML 1.x such as: https://www.w3.org/TR/css-nesting-1/#nesting https://www.w3.org/TR/css-nesting-1/#nesting The W3C document template even kindly provides a quick way to copy those links to every header using the section mark (§).
JW_00000 4y ago
Works for me in Firefox. It seems to just rely on a <details> element [1], which should work in all modern browsers [2]. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... [2] https://caniuse.com/details https://caniuse.com/details

account42 4y ago

How does the SCSS syntax differentiate between `& .childclass` and `&.additionalclass` without the ampersand?

kevincox 4y ago
It doesn't. If there is no ampersand it is assumed to start with `& `. So `.childclass` is equivelent to `& .childclass` and if you want something else you need to do `&.additionalclass` or `& + .additionalclass` or whatever you want.

deleted 4y ago

[deleted]

miragecraft 4y ago

Doesn't the :has() selector already cause unbounded lookahead?