Re: [csswg-drafts] [css-nesting] Syntax suggestion (#4748)

> I’m not sure how this is different from starting with a selector that starts with & and then later modifying it in the OM to one that doesn't (without adding @nest). It's the same kind of positional awareness, just larger scale (rule list vs selector list of a single rule).

That "larger scale" is the problem. The current spec just needs to have a check in the rule serialization algorithm to output the rule with `@nest` if the selector isn't appropriate for direct nesting. (And if we do "always `@nest`, we don't need any special cases at all.) Your proposal needs something significantly more complex/fiddly, based on knowing if you're the *first* nested rule in your parent, and possibly inserting *fake rules* just to satisfy the parsing concerns, which is a *completely novel thing in CSS*.

> In fact, it could even happen with the current syntax if you rearrange the selectors in a selector list (e.g. &.button, .button-group > & to .button-group > &, &.button.

No, the requirement in the current spec is that if you're directly nested, *all* the selectors in the list have to be directly nestable, precisely to avoid this sort of authoring hazard.

> Positional awareness is everywhere, that's how parsers work! 

As the author of the Syntax spec, and the writer of a number of additional parsers for various languages, I know that. ^_^

But not all positional awareness is created equal. Knowing what parsing context you're in is important; it should be obvious and easy to determine, and ideally hard to accidentally flip. Your proposal doesn't satisfy this, I believe - it has three separate parsing contexts: properties, then a single rule starting with `&`, then any rule at all - and I think it's relatively easy to mess that up. Nested rules that are valid at one spot in a parent rule are *invalid* in another spot; removing a rule (the first one that flips the context over) can invalidate rules coming afterward; etc.

> A lot of these suggestions (including mine) are trying to do the very opposite: make preprocessor code somewhat more compatible with CSS Nesting so that migration is less painful (both in terms of migrating existing stylesheets, as well as migrating muscle memory, which is much harder).

No, every one of them requires similar or more migration effort than the current spec, and most present a significantly different syntax model than what every existing nesting syntax uses

Your proposal is no different. Most Sass nesting, from what I can tell, does *not* start with an `&`; they instead usually use relative selectors that start with a combinator (including, most commonly, the descendant combinator). So authors dropping a preprocessor and moving to raw CSS will very likely have to modify their rules anyway. And, going to my earlier point, they won't be able to do so trivially either - they'll have to check if the first nested rule leads with an `&`, and if not, add an extra dummy rule to force it into the right parsing context.

> I would be strongly against making the syntax even more annoying than it is today by having to prefix everything with @nest. Having used it a lot, it's already a pain to add & and @nest as needed. The cognitive overhead of deciding whether @nest is needed is orders of magnitude smaller than the overhead of writing @nest (even with autocomplete) or filtering it out mentally when reading stylesheets.

Then we can keep the current spec. ^_^

> Designing syntax around parsing instead of people is completely the wrong kind of prioritization and a usability antipattern. Authors are above spec editors and authors are above implementors in the priority of constituencies. If certain syntax makes things significantly easier or faster for authors at the cost of complicating implementations or spec work, that in most cases is a worthy tradeoff.

That's why I explicitly called this out as a theoretical purity concern; I assumed using the term-of-art from the priority of constituencies would make it obvious that I recognize what level this concern is at.

But the priority of constituencies is not an absolute, as I'm sure you know. Theoretical purity can win out *if* it leads to greater overall usability or future-friendliness, even if it's somewhat less optimal in an individual situation. It's important to not throw things out a priori just because they're from a "lower" level.

My concern here is about (a) learnability and (b) extensibility to other contexts. The more things stick to "standard"/pre-existing CSS syntax constructs, the easier it is to learn and explain; every diversion from the CSS standard practice means another oddity for authors  to learn and remember. As well, the more things stick to standard practice, the more likely we can use it in other CSS contexts without having to do anything special; we wouldn't even need to *think* about mixing it in syntactically, it will Just Work.

Most notably:

> Is this a theoretical concern or has anyone actually added a & somewhere in a selector and was surprised to find its meaning change? I've been using implicit descendants in Sass for years and never had this problem nor have I heard anyone have this problem.

If we use "always `@nest`", then we don't have *any* parsing concerns, and could easily allow relative selectors instead (including implicit descendant combinator), because the prelude of an at-rule is wide-open in its syntax. We can't do that today because it would require us to add more parsing carve-outs for detecting a rule vs a property.

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


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

Received on Thursday, 11 November 2021 22:02:28 UTC