Closed Bug 1386932 Opened 7 years ago Closed 6 years ago

[css-grid] DOM order is incorrectly being taken into account when sizing grid tracks

Categories

(Core :: Layout, defect, P3)

57 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox57 --- wontfix

People

(Reporter: me, Unassigned)

Details

(Keywords: DevAdvocacy, Whiteboard: [devRel:P1])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36

Steps to reproduce:

Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1386921
Test case: https://codepen.io/rachelandrew/pen/aymLmq?editors=1100#0
Discussion: https://github.com/rachelandrew/gridbugs/issues/2#issuecomment-319823340

In the test case above there are two grids, these are identical other than the order of the child divs has been switched.


Actual results:

Firefox changes the track sizing based on the order of content in the DOM.


Expected results:

Track sizing should be independent of content order. The example behaves as expected in Chrome.

https://drafts.csswg.org/css-grid/#distribute-extra-space
Component: Untriaged → Layout
Product: Firefox → Core
So as I mentioned in the original discussion, the problem is that the track sizing algorithm in Firefox is not respecting bullet 1. in https://drafts.csswg.org/css-grid/#distribute-extra-space which says:

" Maintain separately for each affected base size or growth limit an amount of planned increase. (This prevents the size increases from becoming order-dependent.) "

This means that when sizing intrinsic size tracks, the order in which you select items with the same span should be totally irrelevant to the final sizing of the tracks, that's why implementations need to keep temptative sizes while evaluating all the items with the same span before actually updating the track sizes.
Keywords: DevAdvocacy
Whiteboard: [devRel:P1]
Priority: -- → P3
Testing in FF 61 & 62 with CSS Grid dev tool Firefox renders the grid tracks with the same dimensions in both examples now for me (10/10/60/7/6). Closing as WFM
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.