Skip to content

Commit c3fbd3a

Browse files
committed
[css-grid-3] Remove outdated performance notes
1 parent 8520640 commit c3fbd3a

File tree

1 file changed

+0
-24
lines changed

1 file changed

+0
-24
lines changed

css-grid-3/Overview.bs

-24
Original file line numberDiff line numberDiff line change
@@ -1419,30 +1419,6 @@ Absolute Positioning</h2>
14191419
Maybe it could defined as the max (or min?) current [=running position=]
14201420
of the [=grid-axis=] tracks at that point? Or the end of the item before it?
14211421

1422-
<h2 id="performance-notes">
1423-
Performance Notes</h2>
1424-
1425-
In general, masonry layout should have significantly better performance
1426-
than the equivalent regular (2-axis) grid layout,
1427-
particularly when the [=stacking axis=] is the [=block axis=]
1428-
since the intrinsic sizing of grid rows is typically quite expensive.
1429-
Any intrinsic track sizing in the [=grid axis=] should be cheaper too,
1430-
because, typically, only a subset of items contribute to the intrinsic sizing in a masonry layout,
1431-
contrary to a 2-axis grid where all items spanning an intrinsically-sized track contribute.
1432-
Stretched items do a second layout with the new size (when it actually changed)
1433-
so this can be costly if there are a huge amount of stretched items
1434-
that each contains a lot of content.
1435-
Especially nested stretched masonry layouts should be avoided
1436-
unless they are small/trivial.
1437-
1438-
Advisement: This can be ameliorated by the author
1439-
by opting out from the stretching on most items though,
1440-
e.g. specifying ''justify/align-items:start''
1441-
and then opting in for just a few items with ''justify/align-self:stretch''
1442-
to let those items fill the [=stacking axis=].
1443-
(This performance analysis is from a Gecko perspective,
1444-
but I suspect there's some truth to it for other layout engines as well.)
1445-
14461422
<h2 id="graceful-degradation">
14471423
Graceful Degradation</h2>
14481424

0 commit comments

Comments
 (0)