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

Re: [css-grid] Capping the size of grids?

From: Sergio Villar Senin <svillar@igalia.com>
Date: Thu, 28 Aug 2014 12:08:18 +0200
Message-ID: <53FEFF92.8040908@igalia.com>
To: www-style@w3.org
On 22/08/14 02:36, Tab Atkins Jr. wrote:
> On Thu, Aug 21, 2014 at 2:34 AM, Sergio Villar Senin <svillar@igalia.com> wrote:
>> The current spec allows implementors to cap the number of repetitions
>> allowed for the repeat() function[1]. I'd like to propose to extend this
>> to the values accepted by the grid positioning properties. The rationale
>> behind this is that those positioning properties might act as grid
>> definition properties (by creating implicit grid tracks), allowing
>> authors to do things like: "grid-row-start: ARBITRARY_HUGE_NUMBER;"
>>
>> So my proposal would be to remove the special case of repeat() in the
>> specs and replace it by a more general statement allowing implementors
>> to cap the number of tracks, no matter if they're explicitly or
>> implicitly defined.
>>
>> WDYT?
> 
> Yes, this is an oversight in the spec; we didn't think of the fact
> that positioning might create an overly-large implicit grid.  I've
> generalized the allowance to limit the size of the grid to apply to
> the explicit and implicit grids in general.

Thanks Tab for considering this. So now that I'm implementing it I'd
like to be sure that we're on the same page, because I personally find
the current wording a bit confusing (for example "Attempting to size an
item to a span past the maximum size must instead size it with a span
equal to the maximum size").

Basically I fail to understand if we prefer to preserve positions or
spans. Provided we have an item that is placed either partially or
completely out of the grid limits should we:

a) respect positioning, narrowing the item (reducing span) as needed
b) respect span, moving the item as needed

(in both cases the corresponding edge is placed at the maximum index)

BR
Received on Thursday, 28 August 2014 10:08:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:24 UTC