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

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

From: Julien Chaffraix <julien.chaffraix@gmail.com>
Date: Mon, 11 Mar 2013 11:01:56 -0700
Message-ID: <CAGY_oHJ+n_-yPRMTWreV4opHp6=9FZddJLsScZ1y+3v2C2hYOw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
>> 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.

>From an implementation perspective, starting from the end / after edge
or allowing negative indexes have the same challenges as it allows the
issues I outlined.

I am trying to understand the use case that you are trying to cover
with these. An obvious use case would be inserting a grid item into an
arbitrary grid element and have it span the whole grid, though I would
wonder how prevalent this would be. The other use of negative indexes
or starting from the end / after are less clear to me: e.g. grid-row:
2 / 2 would presumably ignore a row at the start / end of the grid but
it's unclear what would happen if grid-definition-rows defines less
than 3 grid tracks. The authors would definitely have 2 rows (per the
implicit grid track creation) but as this would fit grid-end: 2, there
is no need to grow the grid more in this case, which would violate the
intent.

Thanks,
Julien
Received on Monday, 11 March 2013 18:02:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT