- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 09 May 2015 18:02:45 -0700
- To: "www-style@w3.org" <www-style@w3.org>, Mats Palmgren <matspal@gmail.com>, Manuel Rego Casasnovas <rego@igalia.com>
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