W3C home > Mailing lists > Public > www-style@w3.org > November 2013

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

From: Simon Sapin <simon.sapin@exyr.org>
Date: Fri, 22 Nov 2013 21:20:30 +0000
Message-ID: <528FCA9E.1040302@exyr.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style <www-style@w3.org>
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":


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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC