- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 15 May 2015 13:24:39 -0700
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>, Mats Palmgren <matspal@gmail.com>, Manuel Rego Casasnovas <rego@igalia.com>
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