Repository navigation
[css-grid] Spaces in grid-template-areas serialization #4335
Description
See https://crbug.com/1005364 regarding
element.style.gridTemplateAreas = '". . a b" ". .a b"';
element.style.gridTemplateAreas; // '". . a b" ". .a b"' in Firefox
// '". . a b" ". . a b"' in Blink, WebkitAccording 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 #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".
Activity
mrego commentedon Sep 19, 2019
I don't have a strong opinion, but something like
". . a b" ". . a b"looks less confusing to me than". .a b" ". .a b".Loirooriol commentedon Sep 20, 2019
So I think the spec should say that each list of tokens is serialized into a
<string>as follows:.tabatkins commentedon Nov 1, 2019
Yes, I think all cells should be space-separated; relying on parsing quirks (the fact that
.fooandfoo.will always tokenize as two separate tokens) in serialization is generally bad.fantasai commentedon Nov 1, 2019
OK, we've specified the serialization of template strings more precisely:
Agenda+ to confirm.
css-meeting-bot commentedon Nov 13, 2019
The CSS Working Group just discussed
Spaces in grid-template-areas serialization, and agreed to the following:RESOLVED: Specify serialization as proposed in https://github.com/w3c/csswg-drafts/issues/4335#issuecomment-548962309The full IRC log of that discussion
<dael> Topic: Spaces in grid-template-areas serialization<dael> github: https://github.com//issues/4335
<fantasai> https://github.com//issues/4335
<TabAtkins> emilio, I'd love to with with you and jensimmons or anyone interested in this to figure out what devtools is using and how we could expose that to users.
<dael> fantasai: Want to clarify how spaces are handled. There's not compat. We said serialize between tokens we do a single space no matter if it's needed
<dael> fantasai: Want to confirm with WG
<dael> astearns: Makes sense to me
<dael> emilio: Seems weird to change string b/c we don't change string in other places
<dael> TabAtkins: You do change the string somewhat. Youd on't if parsing splits tokens correctly. But you trim spaces at end and collapse many to one
<dael> oriol: In issue #3261 we resolved against preserving percise string in favor of normalizing. Just wasn't clear on what to do with spaces
<dael> TabAtkins: Thanks
<dael> astearns: emilio?
<dael> emilio: No objections
<emilio> TabAtkins: fwiw, this is the API exposed to devtools: https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl, via https://searchfox.org/mozilla-central/source/dom/webidl/Element.webidl#322
<dael> astearns: Other concerns?
<dael> astearns: fantasai has comment at end with proposal
<dael> astearns: Objections to this?
<dael> RESOLVED: Specify serialization as proposed in https://github.com//issues/4335#issuecomment-548962309
[css-grid] Remove now-disallowed variant results. Fixes w3c/csswg-dra…