[csswg-drafts] [css-variables][cssom] Shorthands should serialize as empty string when longhands have variables (#6253)

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

== [css-variables][cssom] Shorthands should serialize as empty string when longhands have variables ==
https://drafts.csswg.org/css-variables-1/#variables-in-shorthands says

> while [CSSOM] defines that shorthand properties are serialized by appropriately concatenating the values of their corresponding longhands, shorthands that are specified with explicit `var()` functions must serialize to the original, `var()`-containing value. For other shorthands, if any of the longhand subproperties for that shorthand have pending-substitution values then the serialized value of the shorthand must be the empty string.

However, what about this case?

```js
document.body.style.cssText = `
  --start: 1px 2px;
  --end: ;
  margin-inline-start: var(--start);
  margin-inline-end: var(--end);
`;
document.body.style.marginInline; // ???
```

The shorthand has not been specified with explicit `var()`. And the longhands don't have pending-substitution values.

But the shorthand still needs to be serialized as empty string, because `margin-inline: var(--start) var(--end)` would have a completely different meaning!

https://drafts.csswg.org/cssom/#serialize-a-css-value says

> If there is no such shorthand or shorthand cannot exactly represent the values of all the properties in list, return the empty string.

But with variables at specified-value time we don't know if the shorthand will be able to represent the values or not. So it should always be empty string. I think the specs should clarify this.

Firefox and Chrome serialize as empty string (good). WebKit concatenates `var()` (bad).

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


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

Received on Thursday, 29 April 2021 20:24:32 UTC