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

Re: [css3-grid-layout] Negative numbers for <grid-line>

From: Julien Chaffraix <julien.chaffraix@gmail.com>
Date: Mon, 25 Mar 2013 16:22:33 -0700
Message-ID: <CAGY_oHL3yxSODWZLXm-9e_C0TCXETR4jpk3W0S1xVUDq3Eu+8Q@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
>>>> 1) Which negative range is allowed for <integer>?
>>>> There are several options:
>>>> * Match Python which allows negative integers up to -len(array),
>>>> something below is in error and resolves to 'auto'. This has the
>>>> downside of allowing the auto-placement algorithm to run in some
>>>> cases.
>>>> * Allow arbitrary values, knowing that they would be brought back into
>>>> the appropriate range (e.g. using modulo).
>>>> * Match what the specification does for numbered named grid line and
>>>> clamp the value to - (size of the grid) thus resolving in the first
>>>> grid line.
>>> I'd do option 3, clamping them to the first grid line.
>>> The -1 grid line is the last line defined by grid-definition-*.
>> I guess you meant to also include grid-template and any explicitly
>> positioned items or else this is not compatible with the grid
>> auto-placement sizing algorithm (which is btw what we use in WebKit to
>> size the grid regardless of whether we have auto placed grid items).
> Yes, including grid-template.  Basically, any explicit declaration of the size.
> Making it depend on explicitly-positioned items doesn't work, because
> placing any item at "grid-start: -1;" will extend the grid (as it
> spans at least one column), unless you explicitly ignore negative
> items for the purpose of sizing the grid here (but you need to allow
> them for auto-placement).

It's unfortunate that -1 refers to the very last grid line, forcing us
to extend the grid in the common case and not matching what authors
will expect. This is not really an issue with considering negative
grid lines and more with the grid lines numbering failing us in this
case. It's not the only case where this could happen btw as named grid
lines can end up doing the same already. Using grid tracks would solve
this issue but it probably will open its own can of worms.

Also I don't think we should have 2 ways of computing the grid sizes
as it's more cognitive load for anyone trying to understand their
layout (not to mention the unneeded complexity).

>>>> 2) Interaction with the Automatic Grid Item Placement Algorithm (section 6.3.1)
>>>> Currently the specification allows "the position and size of any
>>>> explicitly-defined grid items" which would cover negative positions. I
>>>> would propose to ignore them for the purpose of sizing the grid based
>>>> on what the resolution above.
>>> I don't understand.  The negative value resolves to an equivalent
>>> positive value from the other edge, at which point it's identical to a
>>> normal explicit position.  Why would you ignore them?
>> That's a fair point, I just thought it would be weird to let a
>> negative number impact the grid sizing but that's a convenient way to
>> resolve the issue (we don't even need option 3 as the grid is sized so
>> that the grid item falls naturally into the first grid line).
>> Something like the following would be nice to have in the specification:
>> "Explicitly positioned items with negative grid lines are treated as
>> if they had their absolute grid-line value for the purpose of sizing
>> the grid."
>> (the wording can be improved but you get the idea)
> Our wording needs to be improved, but that's the intent already -
> every item should resolve either into a pair of lines (indicating
> explicit positioning) or just a span (indicating auto positioning).
> In the former case, the lines are just the actual lines, not the
> notational things we refer to them with.


Received on Monday, 25 March 2013 23:23:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:09 UTC