W3C home > Mailing lists > Public > www-style@w3.org > November 2014

Re: [css-grid] Sizing of grid item elements

From: Sergio Villar Senin <svillar@igalia.com>
Date: Tue, 04 Nov 2014 16:52:59 +0100
Message-ID: <5458F65B.304@igalia.com>
To: www-style@w3.org
On 21/10/14 12:55, Sergio Villar Senin wrote:
> On 17/10/14 00:43, Tab Atkins Jr. wrote:
>> On Thu, Oct 16, 2014 at 2:46 PM, Manuel Rego Casasnovas <rego@igalia.com> wrote:
>>> On 22/08/14 17:08, Emil Björklund wrote:
>>>>>> The second thing that struck me as counter-intuitive is that columns
>>>>> sized
>>>>>> with percentages on a grid container without an explicitly declared width
>>>>>> won't get sizes according to a percentage of the grid container width,
>>>>> but
>>>>>> compute to "auto" width. In my example, I used the <body> element as the
>>>>>> grid container, and wanted empty "spacer" columns on the side of the
>>>>> actual
>>>>>> contents, but they collapsed (to nothing, as they had no items/content).
>>>>> I
>>>>>> had to set "width: 100%" on the <body> element for them to get rendered,
>>>>>> which felt superflous.
>>>>> I suspect another bug.  Percentages generally are able to resolve
>>>>> against a "fill" width on blocks; there's no good reason they
>>>>> shouldn't work as you expect here.  (In some cases they can't resolve,
>>>>> when the size of the element depends on the size of the content, but
>>>>> that's not the case for widths in "block" contexts by default.)
>>>> Good to know, I'll make sure to file that one.
>>> I was taking a look to this bug [1] and I think that current behavior
>>> matches the spec [2]:
>>> "If the inline or block size of the grid container is indefinite,
>>> <percentage> values relative to that size are treated as 'auto'"
>>> In that case we're talking about a "grid container without an explicitly
>>> declared width" which seems indefinite.
>>> So, current behavior would be right, and you would need to set the width
>>> of the grid container to get the expected behavior.
>>> Am I missing something?
>> "auto" is not always indefinite; in particular, in block contexts,
>> width:auto is definite as long as its containing block is definite,
>> since it's filling its containing block.  You can use "width: 50%;" on
>> a display:block element whose parent is "width:auto", and grids are
>> defined to auto-size the same as a block container.
>> So a width:auto grid container has a definite width in all the same
>> situations that a width:auto block container does, and columns with
>> percentage sizes should be resolveable in the same cases that a block
>> child with a percentage width is resolveable.
> So in one of the previous drafts[1] there was this definition of
> RemainingSpace:
> "The max of zero and the AvailableSpace less the sum of all Grid track
> UsedBreadth values. This is undefined if AvailableSpace is undefined
> (i.e. the Grid element is shrink-to-fit or the height is auto.)"
> So if I understood you correctly, does it mean that we should consider
> what is inside the parenthesis as incorrect from now on?
>>From the current specs[2], free space is defined as "If available space
> is indefinite, the free space is indefinite as well". Then according to
> [3] "An indefinite available size is essentially infinite". What I
> understand is that in those cases we could just grow all the tracks to
> their maximums and that's it.
> BR
> [1] http://www.w3.org/TR/2013/WD-css3-grid-layout-20130402/
> [2] http://dev.w3.org/csswg/css-grid/#available-space
> [3] http://dev.w3.org/csswg/css-sizing-3/#terms

Received on Tuesday, 4 November 2014 15:53:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:48 UTC