[css-grid] Summary of Abspos Issues

Tab and I just finished going through the abspos issues raised by Manuel and Mats.
This is a summary of what they were, and what we're proposing to do about them.
We welcome feedback, preferences, and sanity-checking. :)

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.

   When a block container is the containing block of an abspos, its padding
   edges form the abspos containing block. For grid containers, we honor the
   grid positioning properties, reducing the size of the grid container to
   the chosen grid area. (The offset properties then operate inside this
   containing block.)

   Manuel pointed out that in case C), the abspos's static position is set
   to the entire content box of the grid container, whereas its size and
   offsets are relative to the box's grid area (a much smaller region).

   This seemed weird: there are no non-overflow cases in CSS where the
   static position containing block is larger than the abspos containing bock.
   So Tab and I think that in case C), the static position should also respect
   the grid positioning properties and constrain the static position to the
   chosen grid area.

   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?

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

   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?

~fantasai

Received on Sunday, 10 May 2015 01:03:17 UTC