Re: [csswg-drafts] [css-nesting-1] Should code portability trump coding habits wrt nesting syntax? (#8029)

> > is that it provides full interoperability between contexts: you can take any CSS code you have today, wrap it in a block, add a selector prefix, and now you have "nested" the existing code without having to make any change.
> 
> I am confused by this statement. It says that you do not need to make any change while outlining the changes you need to make.

I think @argyleink was confused by that statement, too.

Here is an example of HTML/CSS you might find today: (I just took it from the table spec)
```html
<ul class="table">
  <li><b>One</b><i>1</i></li>
  <li><b>Two</b><i>2</i></li>
  <li><b>Three</b><i>3</i></li>
</ul>
<style>
  ul.table { display: table; }
  ul.table > li { display: table-row; }
  ul.table > li > * { display: table-cell; }
</style>
```

Let's say that you inherit that code, and realise that it's not such a good idea to use the "table" class that way in your entire codebase, and you want to limit to a section of your site that contains the articles from the legacy system.

You can take the CSS code, prepend `:where(article.legacy) {} {`, indent the entire list of rules, then close the brace with `}`.

```css
:where(article.legacy) {} {
  ul.table { display: table; }
  ul.table > li { display: table-row; }
  ul.table > li > * { display: table-cell; }
}
```

Now, with the current option, proposal 3, this is not sufficient. You have to go and find all selectors that were starting with an indent, and fix them.

```css
:where(article.legacy) {
  & ul.table { display: table; }
  & ul.table > li { display: table-row; }
  & ul.table > li > * { display: table-cell; }
}
```

This is a manual operation that requires O(n) steps for the author. Each selector needs to be inspected, and then prepended with a '&' symbol if needed. This operation is error-prone and takes time, for something which I expect to be a very common refactoring.

Plus, now, if you want to go back to an independant stylesheet (because, say, you moved to web components and isolated the legacy content there), you have to go back and remove all the `&` symbols since they don't mean anything anymore. If you had used proposal 4 or 5, you would not need to do this.

This is also true if you move from or to `@scope` statements. This is another very likely scenario, given the features work similarly but have different effects on cascade importance.

> I know that writing } { at the end of a declaration is not required but it is placed there to create the visual illusion of nested curly braces (which falls apart with different formatting).

Yeah, that's true. I don't find that other way of writing it that bad, but it does feel less compact. I'd like to note that the examples for the first spec also use artifically-shortened forms though, like `&.c { text-transform:uppercase }` one-liners.

I would also like to point out that with autocompletion these days, you hardly ever write a `}` yourself. They are auto-inserted. The actual workflow when adding nested rules is more likely to be "click after the `}` and type `{` then your rules".


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


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

Received on Monday, 5 December 2022 10:43:21 UTC