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

Re: [css-grid] On cells occupied by named grid areas and auto-placement algorithm

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 4 Mar 2016 11:24:03 -0800
Message-ID: <CAAWBYDBf8V4aregRkMQggJFgPBuN7pPHD+-AyMX2Om=owEiAEQ@mail.gmail.com>
To: Sergio Villar Senin <svillar@igalia.com>
Cc: www-style list <www-style@w3.org>
On Fri, Mar 4, 2016 at 4:32 AM, Sergio Villar Senin <svillar@igalia.com> wrote:
> Hi,
>
> the grid item placement algorithm has been recently changed so that it
> considers that a grid cell belonging to a named grid area is an occupied
> cell. This means that auto-placed items won't occupy those cells covered
> by a named grid area.

That's actually from Sep 2014 ^_^
<https://github.com/w3c/csswg-drafts/commit/dc00d0899df224495ee1795f3d54ea0c2a0ce3c4>

> A couple of questions arose while implementing it.
>
> 1- Which "named grid areas" should be considered?
>
> A named grid area can be explicitly defined by using
> grid-template-areas, that's fine. We could also implicitly define one by
> providing a pair of [*-start,*-end] lines for each axis. Both notations
> should be equivalent, no problem so far.
>
> The problem appears whenever we define [*-start,*-end] for just one
> axis. It's perhaps easier to understand with one example.
>
>    grid-template-columns: 100px [a-start] 100px [a-end] 100px;
>
> A definition like this allows us to "fix" the position of an item in the
> second column by just doing "grid-column: a;" (we just need to
> automatically select the row).
>
> The thing is, from the auto-placement algorithm POV, and for the example
> shown above, should we consider that there is an area which spans all
> the rows long in the second column, meaning that items will only be
> auto-placed in columns 1 and 3?
>
> Or should we consider on the contrary that there is no area there? After
> all the spec says "If a named grid area spans multiple grid cells, but
> those cells do not form a single filled-in rectangle, the declaration is
> invalid." when defining grid-template-areas.
>
> IMHO we should only consider rectangle areas, meaning that those only
> defined in one axis should not be taken into account when deciding about
> the occupied/unoccupied status of a cell.

Good questions. I've pinged fantasai for her opinions, but as I see
it, we have three reasonable options:

1. Only pay attention to areas defined in grid-template-areas. (This
isn't great, because it breaks our "areas aren't special, lines are
what exists" rule.)

2. Pay attention to any rectangular area defined by foo-start/end in
both axises, found the same way that "grid-area: foo" would (so
there's a well-defined answer for what to do in the presence of
multiple foo-start/end lines). (This sounds kinda complicated, tho.)

3. Drop this line, so only explicitly placed things matter. (Generally
you're going to place things everywhere in the grid, so maybe this'll
work? This also means you can actually name the auto-placement area,
rather than being required to mark it out with null cells.)

> 2- Which grid items should be considered?
>
> It seems pretty clear that fully auto-placed items should be clearly not
> positioned inside those named grid areas (whatever they are depending on
> the answer to question 1).
>
> Now we need to decide what to do with items locked to just a given track
> (i.e. "grid-row: a; grid-column: auto;") meaning that for a declaration
> like:
>
>    grid-template-areas: ". a ."
>                         ". a ."
>                         ". b .";
>
> What should happen with an item placed in "grid-column: a;"? IMO we
> should consider that we just want to lock the column, so we ignore the
> cells occupied by areas "a" and "b" -> item will be placed in row 4. It
> could be argued that we could place it inside area "a" but in that case
> I think it's fair to expect the author to directly use "grid-area: a"

Answer here depends on what we choose above.

~TJ
Received on Friday, 4 March 2016 19:24:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC