- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 08 May 2015 16:11:00 -0700
- To: www-style@w3.org, Manuel Rego Casasnovas <rego@igalia.com>, Mats Palmgren <matspal@gmail.com>
On 01/08/2015 02:00 PM, fantasai wrote: > On 12/23/2014 01:40 AM, Manuel Rego Casasnovas wrote: >> On 18/12/14 21:00, Tab Atkins Jr. wrote: >>> This was all defined in the spec already: >>> http://dev.w3.org/csswg/css-grid/#static-position >>> >>> tl;dr: We don't care about the grid-placement properties when >>> determining the static position. >> >> Yeah, the definition of the static position was already there, just that >> I wasn't sure if it should care about the grid-placement properties or >> not. Thanks for the clarification. >> >> Now, my question is if the grid-placement properties are ignored or not >> to calculate the containing block of the abspos children when they don't >> have offsets. In that case we'd use the static position to place them, >> but I'm not sure about what would be their size if they use width/height >> 100%. >> [...] >> [1] http://dev.w3.org/csswg/css-grid/#abspos-items >> [2] http://dev.w3.org/csswg/css-grid/#static-position > > So, I think the spec is pretty clear on how the width/height are calculated: > they're calculated wrt the containing block, which defined to be the grid area. > However, it is kindof weird: the static position is determined based on > a larger rectangle (the grid container) while the containing block is > a smaller rectangle (the grid area). I'm not sure that's a great definition. > It might make sense for static positioning to honor grid positioning as well. Okay, so, our current suggestion is that if the grid container is both the parent and the containing block of the absolutely-positioned element, then the grid area used for its static position is the grid area used for placement. We've updated the spec accordingly, but would appreciate your opinion and review. This is http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-1 > Another issue you bring up is, if one of the grid lines is the padding edge > (which is what an 'auto' grid position indicates for abspos elements contained > by the grid container), and the second grid line is a span, where does it span > to? The padding edge doesn't have a defined relationship to the other grid lines. We've defined that the 'auto' grid lines at the padding edge are before/after the entirety of the grid, i.e. at the positive 0th and negative 0th indices, respectively. That issue is tracked as http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-2 However, this does bring up the issue of what happens when the grid overflows its container and the padding edge is within the outer bounds of the grid. For scrollable boxes the answer is easy: use the padding edge attached to the scrollable area. But for non-scrollable boxes, we're not sure. This corresponds to Mats' issue: https://lists.w3.org/Archives/Public/www-style/2015Mar/0470.html http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-17 Let's discuss it there. > A third issue is, what if there aren't enough lines for the abspos? Some possible > answers: > * attach to the padding edge instead > * attach to the last available grid line (if any) > * create "invisible" grid lines to attach to -- that don't affect layout of the > grid container's in-flow contents Tab and I discussed this and we're thinking to add implicit grid tracks at the edges of the grid until there are enough implicit lines for the abspos to attach to. This handles both named lines that don't exist and lines whose index is out-of-range. (They're explicitly exempted from the grid-auto-* sizing, so they don't change the layout of the grid.) Thoughts? ( This is http://dev.w3.org/csswg/css-grid-1/issues-wd-20150108#issue-3 ) ~fantasai and TJ
Received on Friday, 8 May 2015 23:11:28 UTC