Re: [css-grid] grid-template-areas syntax

On Fri, Nov 22, 2013 at 9:09 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
> 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.

Yeah, double-escaping isn't great.  I'm fine with defining a smaller
ad-hoc syntax.  Let's say:

Four tokens:

1. Run of digits, ASCII letters, or non-ASCII characters.
2. Single ASCII periods.
3. Run of whitespace.
4. Anything else.

Presence of #4 invalidates the property.  Throw away #3.  #1 and #2
constitute the cell names.

This allows you to produce areas with awkward names to write as
idents, but it's nice and simple.

~TJ

Received on Friday, 22 November 2013 20:57:42 UTC