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

On 22/11/2013 20:56, Tab Atkins Jr. wrote:
> 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.

Sounds good, though I would add dash and underscore (U+002D and U+005F) 
to 1, making it match "name code point":

http://dev.w3.org/csswg/css-syntax/#name-code-point

-- 
Simon Sapin

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