Re: [csswg-drafts] [css-nesting-1] Syntax Invites Errors (#7834)

@argyleink said in https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1272155603 :

> I think the goal of the proposed change is to have syntax closer to SCSS and to have hopefully better developer ergonomics to avoid common programming errors. This would be via the "parser switch" model vs an & before each rule. Let me know if I missed any other goal. :)

There is another goal, to have support for relative selectors in nested selector contexts.
Relative selectors sometimes (not always!) copy-paste nicely between contexts.

The logic appears to be :

1. we want relative selectors in nesting because relative selectors copy-paste nicely to other contexts
2. relative selectors imply `.foo { bar { /* decl */ } }` and the parser algorithms don't allow that
3. we need the `@nest;` noop to fix the parser issue.
4. the resulting syntax happens to also be more similar to Sass-style nesting

But there might be different ways to have relative selectors in nesting.
I've opened https://github.com/w3c/csswg-drafts/issues/7854 to explore one possible alternative.

> Pros
> 
> Folks who aren’t thrilled to add an & before their nested selectors will appreciate the familiarity and convenience of the new proposal. They’d also appreciate the flexibility to use more than one way of expressing the syntax.

This could be solved in preprocessors where the ambiguity is less of an issue. The parsers in preprocessors are of a different design.

Not saying that it can not be solved in the syntax, but syntactic sugar is what tooling is really great at.

----------

> The learning curve increases for anyone not coming from SCSS, because the previous syntax's simplicity and rigidity was a feature. Folks who do know SCSS still have things to learn, it's not a free switch. For example, BEM style nesting won't port over and most copy/paste scenarios will require throwing the `@nest;` switch in "just in case" or an "I don’t know why, I just always put it there".

> Increasing the flexibility also increases the potential for accidental programming errors. More options also means more cases to be aware of, or the style sheet ends up with errors. It gives some but takes some. Increased flexibility also means ramping up to more nesting styles when reading other authors’ nested styles, and increases friction to understanding style sheets between teams (or even within the same team between selectors that do or don’t have `@nest;` or when importing third-party sheets.

I think this proposal has less flexibility.
It is only more flexibly when writing nested CSS from scratch.
At that point you can chose between multiple options.

And copy-paste from Sass (which is a one time action) happens to be correct more often than with the current syntax.

But it places more burden on readers because they have to figure out again and again which of the modes is currently in play.
- first rule, not first rule
- second rule, not second rule (because it might suddenly become the first rule after a change)
- starts with `&`, doesn't start with `&`
- already added `@nest;`, or not

It also restricts the available options when refactoring code.
Needing to alter unrelated CSS to make it valid again after removing a rule should be avoidable in the syntax design.

How does it interact with git merges?
What if your colleague removes the first rule and you changed the selector of the second?

In the current specification each rule is (in)valid on its own.
There is no spooky action at a distance. This makes reading easier and enables more mutations.

----

> Below is an enumeration of the possible ways to nest. The current spec has two ways (start with & or start with @nest), and the proposed changes make it 4 (the two original styles, @nest; … and first-selector-starts-with-&). I thought it would be useful to write them out so that everyone can see the actual syntax options in practice.
Current spec options for nesting

I am unsure if `@nest .foo { /* ... */ }` still exists in this proposal.
I don't see it mentioned anywhere.

-- 
GitHub Notification of comment by romainmenke
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1272283326 using your GitHub account


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

Received on Saturday, 8 October 2022 10:05:35 UTC