- From: Sergio Villar Senin <svillar@igalia.com>
- Date: Tue, 04 Nov 2014 16:52:59 +0100
- 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 > Ping?
Received on Tuesday, 4 November 2014 15:53:27 UTC