[csswg-drafts] [css-nesting] Another problem with mixing declarations and rules - error recovery (#8349)

plinss has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nesting] Another problem with mixing declarations and rules - error recovery ==
I'm not sure if this has been discussed before or not, but I just realized there's another issue with both option 3 and the lookahead approaches to nesting. Error recovery.

There are different behaviors for error recovery with declarations and rules, an invalid declaration consumes everything up until the next unenclosed `;`, where invalid rules consume everything up until the next unenclosed `;` or block `{}`.

Consider the following example:
```css
div {
    background: green;
    .nested {
        color: blue;
    }
    background: red;
```

What color is the background of the `div`? In a browser that doesn't support nesting, it'll be green, in a browser that does, it'll be red. This is a problem.

Having a `&` prefix doesn't fix this. Lookahead doesn't fix this. AFAICT the only thing that does is a full at-rule prefix, e.g. `@nest` (even a bare `@` doesn't fix it) because this causes the browser to shift back into rule recovery mode when it was expecting a delcaration.

I see a few paths forward here:

1) We forbid declarations after rules. This is still problematic as browsers that support nesting will ignore all declarations after the nested rules, while older browsers will only ignore the first one.
2) We require a `;` after nested rules. I think this is fragile.
3) We just YOLO it and tell people "don't do that". If people really want to put declarations after nested rules they need to add a `;` between the last rule and the first following declaration if they want compatibility with older browsers.
4) We require a full at-rule prefix. Probably the least popular, but the most safe option.

I'm open to other suggestions...


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8349 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 22 January 2023 21:03:43 UTC