Re: [css-grid] Summary of Abspos Issues

On Sat, May 9, 2015 at 6:02 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>   We didn't do this for abspos whose containing block is an ancestor of the
>   grid container because if that ancestor was also a grid container, the
>   grid positioning properties on the abspos would have been chosen for that
>   ancestor's grid, and would be inappropriate to this one.
>
>   However, we could alternately always honor the grid-positioning properties
>   for determining the static position. It's only the case where both the
>   parent and the containing block are grid containers, but are not the same
>   grid container, that's weird if we do this.
>
>   Proposals:
>     A) Make static position of case C honor grid-positioning properties
>     B) Make static positions of all cases where the grid container is the
>        static position containing block (i.e. cases A and C) honor the
>        grid-positioning properties
>     C) Make the static position not honor grid-positioning properties
>
>   Thoughts?

As you argue in the paragraph quoted above, case B is terrible and we
can't do it.  Case C is terrible for reasons you explained earlier in
the email (elided here).  Case A is the only one that makes any sense
at all.

> http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-2
>
>   When a grid container is an abspos's containing block, we use the
>   grid-positioning properties to restrain it to a grid area.
>
>   To maintain compatibility with block containers, to avoid problems with
>   auto-placing into non-existent cells (since absposes don't affect layout
>   and therefore can't create new grid rows/columns for themselves) and
>   also to give a useful ability to such abspos boxes, we defined that a
>   grid position of ''auto'' for the start or end edge uses the padding
>   edge of the grid container as that grid line.
>
>   We didn't define the relationship of this special grid line to the rest
>   of the grid, so we added a definition that these lines are just
> before/after
>   the rest of the grid lines.
>
>   Proposal: 'auto' lines for abspos positioning, which correspond to the
>   padding edges, occupy, effectively, the positive 0th and negative 0th
>   positions in the grid.
>
> http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-17
>
>   This issue is about what happens when the index is out-of-range
>   or the named line doesn't exist.
>
>   Options (restricted to abspos positioning):
>
>      A) Create as many new implicit lines as required, and position
>         them all coincident with the grid's last line.
>      B) Create as many new implicit lines as required, and position
>         them all coincident with the 'auto' line at the padding edge.
>      This is the closest analogy to how non-abspos error handling works,
>      but it disrupts the relationship of the last actual grid line to the
>     'auto' line (see previous issue): you can span from the 'auto' line to
>      the other lines by naming (by name or index) a specific line in the
>      grid, but the result of a span from an 'auto' line depends on the
>      implicit lines so created.
>
>      C) Assign all out-of-range indices and missing named lines to
>         the last actual grid line, clamp any spans and positions
>         into the 'auto'-augmented grid.
>      D) Assign all out-of-range indices and missing named lines to
>         the 'auto' grid line, clamp any positions and positions into
>         the 'auto'-augmented grid.
>      Both of these mean items with invalid indices will tend to be
>      positioned into the track between the grid and the end padding edge.
>
>      E) Treat all out-of-range indices and missing named lines as 'auto'.
>      This means missing start lines will be assigned to the start padding
>      edge, and missing end lines will be assigned to the end padding edge.
>
>   Thoughts?
>
>   Note: The ED as of yesterday specifies A, and will need to be fixed.
>
> http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-17

Agree that A is bad, due to the spanning issue. (But it's so elegant
to specify! ;_; )

I'm fine with C.  B/D give weird behavior, imo (you argued this in
person, which is why we went with A rather than B in the current
draft).  E is bad for reasons I explained in person: specifying the
last named line for grid-*-start puts the item on the end side of the
grid; going one past would put it on the start side of the grid. This
is terrible for usability, and doesn't even attempt to preserve author
intent.

>   This issue relates to issue 2: what happens if the ''auto'' line
>   happens to be positioned within the geometric space of the grid?
>   This happens if the grid overflows the grid container: the padding
>   edge occurs before the last grid line. This means the track spanning
>   from the last grid line to the 'auto' padding line will have negative
>   width.

If it overflows *visibly* (overflow:visible), to be clear.  If the
element is scrollable, we use the padding edge of the scrollable area,
which doesn't present any problem.

>   Options:
>     A) Position 'auto' lines at the padding edge or last grid line,
>        whichever is further out.
>          * This gives abspos different behavior than in block containers
>            in cases where the grid overflows the grid container.
>     B) Deal with the negative width by flipping start/end associations.
>          * We don't do this for similar conflicts within the grid itself.
>     C) Honor the non-'auto' line, ignore the 'auto' line: give the
>        abspos a containing block of zero, positioned at that line.
>     D) Something else?

I'm fine with A or C.

~TJ

Received on Friday, 15 May 2015 20:25:26 UTC