W3C home > Mailing lists > Public > www-style@w3.org > May 2015

Re: [css-grid] Absolutely positioned items and static position

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 08 May 2015 16:11:00 -0700
Message-ID: <554D4284.7030502@inkedblade.net>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC