[Webkit-unassigned] [Bug 171855] grid layout negative row-end bug

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 12 00:17:07 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=171855

Sergio Villar Senin <svillar at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Sergio Villar Senin <svillar at igalia.com> ---
This is not a bug, as grid is behaving as it should according to the grid placement algorithm described in the specs https://drafts.csswg.org/css-grid/#auto-placement-algo.

The reason is a bit technical but I'll try to explain why. The problem of the "broken" grid is the "aside" item which has a specified grid-row: 2/-2. That item is the only one with a definite position, both grid-row and grid-column are specified and do not require automatic placement (the other items only specify grid-column). This means that the "aside" grid item will be the first one to be placed. 

At the very begining the grid has 2 columns but no rows (grid-template-rows:auto). So in order to place that item we create 1 row. That row defines rows 1 and 2, which at the same time represent rows -2 and -1. At that moment we can place the item because we have indexes 2 and -2 which correspond to rows 2 and 1. In those cases, when start > end the specs mandate to exchange those indexes so the item is placed between 1 and 2 in the first row.

Once that item is inserted then we proceed to add the other ones which will create new rows as required.

It's true that you could use both positive or negative indexes but as you can see they are not totally equivalent when you need to automatically create new tracks. In this case if you know that you need 5 columns, just add grid-template-rows: repeat(5, auto) and you'd get the results you want.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170512/8f89b203/attachment.html>


More information about the webkit-unassigned mailing list