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

Re: [css3-grid-layout] grid-end / grid-after with <integer>

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 8 Mar 2013 15:24:44 -0800
Message-ID: <CAAWBYDD5MzkSAJG9qNe-f6jWnUtJy0WtrJKwvPGiRoneGxRA5A@mail.gmail.com>
To: Julien Chaffraix <julien.chaffraix@gmail.com>
Cc: www-style list <www-style@w3.org>
On Fri, Mar 8, 2013 at 1:59 PM, Julien Chaffraix
<julien.chaffraix@gmail.com> wrote:
> I am extremely concerned about the change that was made to the
> specification to have grid-end (resp. grid-after) be resolved against
> the grid element's end edge (resp. grid element's after edge) in the
> <integer> case.
> It is this confusing for people (grid-row: 1 / 1 is a grid item
> spanning the whole grid) and it took me a while to understand why the
> example 15 is correct [1]. This issue was already mentioned during
> some previous meeting's minutes [2].

We've already got an issue for this in the draft.  I agree, I think
I'd prefer that integers always count from the before/start side.

> Mostly it opens us to a slew of complexity for the auto-placement
> algorithm as we would need to re-resolve our grid positions if the
> grid grows (which removes the current algorithm's guaranteed linear
> time). The other alternative is to ignore the author's intent and
> don't recompute which is equally bad.

If we do change to always counting from before/start, we then want to
allow negative indexes to indicate counting from the after/end side.
We really can't avoid this - it's necessary for lots of things (such
as, for example, having an area span the entire grid).  So, this
complexity is unavoidable.

Received on Friday, 8 March 2013 23:25:36 UTC

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