Re: [css-grid] Summary of Abspos Issues

Hi,

thanks for all the work on this, I's a though topic.

On 10/05/15 03:02, fantasai wrote:
> http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-1
> 
>   There are types cases of abspos boxes associated with a grid container:
> 
>     a) Boxes whose parent is the grid container, but whose containing block
>        is an ancestor of the grid container:
>           <grid-container>
>             <abspos/>
>           </grid-container>
>        For these boxes, the grid container determines their static
> position,
>        but not their size or offset-based position.
> 
>     b) Boxes whose containing block is the grid container, but who are
>        descendants (not children) of the grid container:
>            <grid-container position: relative>
>              <grid-item>
>                <abspos/>
>              </grid-item>
>            </grid-container>
>        For these boxes, the grid container determines their size (and
> offsets),
>        but not their static position.
> 
>     c) Boxes whose parent and containing block is the grid container:
>            <grid-container position: relative>
>              <abspos/>
>            </grid>
>        For these boxes, the grid container determines both their size
>        and their static position.
> [...]
>   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?

I'd go for A), where only the case C will honor grid-positioning
properties for the static position and the sizes. I'd ignore it in the
other cases.

> http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-2
> [...]
>   Proposal: 'auto' lines for abspos positioning, which correspond to the
>   padding edges, occupy, effectively, the positive 0th and negative 0th
>   positions in the grid.

Yeah I think it makes sense.

> 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?

I agree that A) and B) seem a bad idea, due to the previous issue.

On a first thought, D) could be a good option and in some cases somehow
similar to what happens with non-abspos elements (e.g. "grid-column: foo
/ bar;").
Also, E) might be interesting as they user might easily detect the
mistake in some cases (e.g. "grid-column: foo / bar;" will take the
whole width between the padding edges).

> http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-17
> 
>   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.
> 
>   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?
> 
>   Comments? Suggestions? Preferences?

I don't have a clear opinion on this one. I tend to option A), but I
understand it has problems too. But I don't have a better suggestion
right now.

My 2 cents,
  Rego

Received on Tuesday, 12 May 2015 11:57:04 UTC