[csswg-drafts] [cssom] Should new rules serialize fully on a single line? (#12959)

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

== [cssom] Should new rules serialize fully on a single line? ==
There was a discussion around this in https://github.com/w3c/csswg-drafts/issues/4828, but I don't understand what the resolution actually means:

> `RESOLVED: We define this is CSSOM to match browser compat as much as it exists.`

Can we clarify this?

Assuming we can't mess with the serialization of old rules for compat reasons, we may have to accept that e.g. `@media` serializes with newlines and indents. Do we still want to go for the single line behavior for _new_ rules? If yes, does the single-line-ness carry over to any _inner_ rules that would otherwise use newlines/indents in a different context?

Example:

```
@function --f() {
  --local: 1px;
  @media (width > 200px) {
    --x: 2px;
    --y: 3px;
  }
  result: 4px;
}
```

This serializes as this nonsense in Chrome:

```
@function --f() { --local: 1px; @media (width > 200px) {
  --x: 2px; --y: 3px;
} result: 4px; }
```

That's because `@function` tries to be single-line, but `@media` wants it the old way.

It would be far more reasonable to serialize the whole thing on a single line, but @emilio notes that it could be weird that `myFunc.cssRules[0].cssText` would serialize a `@media` rule differently than what you'd get for the same rule top-level.

We could address that by having two modes: legacy mode, and single line mode. Every serialization starts in legacy mode, but as soon as you enter a "new" rule, any child constructs are also serialized in single line mode. That would allow `myFunc.cssRules[0].cssText` to serialize consistently with the top-level, while also placing everything on a single line for `myFunc.cssText`.

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


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

Received on Thursday, 16 October 2025 13:44:12 UTC