Re: [css-grid] row-gap/column-gap issues

Hi,

I think what I had in mind was cases where size ratios didn't necessarily
work out to nicely even fractions (and thus were perhaps more likely to be
expressed with percentages), like in the "multiple grid ratios" example
last in https://lists.w3.org/Archives/Public/www-style/2015Jun/0355.html. I
think that can be safely added to the "edge cases"-column though. :-)

My main point was just that the total size of all tracks would no longer be
defined in one place, which could potentially be confusing, so maybe the
spec should have a note or cross-reference.

//emil





On Fri, Jul 17, 2015 at 12:09 AM, fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 06/23/2015 02:31 PM, Emil Björklund wrote:
>
>> On Tue, Jun 16, 2015 at 3:44 AM, fantasai <fantasai.lists@inkedblade.net
>> <mailto:fantasai.lists@inkedblade.net>> wrote:
>>
>>     We've gotten a fair amount of feedback that authors would find Grid
>> Layout
>>     easier to use and generally less confusing if we added row-gap and
>> column-gap
>>     properties to automatically create gutters.
>>
>>        * It makes track definitions easier to read and write, by
>> eliminating
>>          repetitive "noise".
>>        * It makes repeat() significantly less awkward to use (since we
>> don't
>>          have the trailing-joiner problem).
>>        * It handles gutters for implicit tracks, which is currently not
>> possible.
>>        * It eliminates the problem of auto-placement putting items into
>> tracks
>>          meant to provide gutters.
>>
>>
>> I'm very happy to see this in the spec. My only (very minor) concern is
>> that grid definition now happens in two places. An
>> author defining a grid with non-flexible grid tracks involved may want to
>> tweak the gutters back and forth a bit, which would
>> then potentially warrant going back and redefining percentages etc –
>> especially if all tracks are non-flexible.
>>
>> I realize that having the gutters simply act as fixed-size tracks is
>> probably a very necessary tradeoff compared to changes in
>> the track sizing algorithm (proportionally shrinking either tracks or
>> gutters in the case of overflow...?), but it probably
>> warrants a note or two in the spec.
>>
>
> Hi Emil,
>
> Why wouldn't you use flexible track sizes in that case?
>
> ~fantasai
>