W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2019

[csswg-drafts] [css-grid] Spaces in grid-template-areas serialization (#4335)

From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
Date: Thu, 19 Sep 2019 03:46:59 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-495557169-1568864817-sysbot+gh@w3.org>
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-grid] Spaces in grid-template-areas serialization ==
See https://crbug.com/1005364 regarding

```js
element.style.gridTemplateAreas = '". . a b" ". .a b"';
element.style.gridTemplateAreas; // '". . a b" ". .a b"' in Firefox
                                 // '". . a b" ". . a b"' in Blink, Webkit
```

According to https://drafts.csswg.org/css-grid/#valdef-grid-template-areas-string

> Both the specified value and computed value of a `<string>` value of grid-template-areas serializes each null cell token as a single "." (U+002E FULL STOP) and each sequence of whitespace as a single space (U+0020 SPACE).

And by omission I guess that a lack of whitespace shouldn't be serialized as a space?

However, it seems confusing to me because the resolution in https://github.com/w3c/csswg-drafts/issues/3261 was against preserving the precise string when serializing `grid-template-areas`, and in favour of normalizing it. And according to https://drafts.csswg.org/css-grid/#valdef-grid-template-areas-string,

> A sequence of whitespace, representing nothing (do not produce a token).

So if whitespace doesn't produce tokens when parsing, it doesn't seem unreasonable for me to not track whether some optional space between tokens of different type was specified or not. Then the possibilities are always adding a space separator between tokens like `". . a b" ". . a b"`, or only doing it if necessary (between tokens of the same type) like `". .a b" ". .a b"`.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4335 using your GitHub account
Received on Thursday, 19 September 2019 03:47:00 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:53 UTC