- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Fri, 22 Nov 2013 17:09:55 +0000
- To: www-style <www-style@w3.org>
Hi, The definition for <string> values in the grid-template-areas property is currently: > <string>+ > > A row is created for every separate string listed for the > grid-template-areas property, and a column is created for each > identifier or period ("." U+002E) in the string, when the string’s > contents are parsed as CSS. > > * A period represents an unnamed area in the grid container. > > * An identifier creates a named grid area with the identifier as its > name. Multiple identical identifiers create a single named grid area > that spans the corresponding grid cells. > > All strings must have the same number of columns, or else the > declaration is invalid. If a named grid area spans multiple grid > cells, but those cells do not form a single filled-in rectangle, the > declaration is invalid. If a string’s contents, when parsed as CSS, > contain anything other than whitespace, identifiers, or periods, the > declaration is invalid. The part I’m interested in is "string’s content parsed as CSS". A <string> value typically comes from a string token, whose value has had CSS backslash-escapes resolved by the tokenizer. As I understand it, we’re running the same tokenizer again here, with that value as the input, with full handling of CSS comments and escaping, resulting in potential double-escaping. The following valid and only defines one area: grid-template-areas: "foo foo" "foo\2F **/f\5C 6F o"; Is this what we want? Is it what IE does? (I don’t have it available to test right now, sorry.) If it’s still possible to change, I would rather define a simple ad-hoc syntax. -- Simon Sapin
Received on Friday, 22 November 2013 17:10:24 UTC