@@ -1012,7 +1012,7 @@ Placement Precision: the 'masonry-slack' property</h3>
10121012
10131013 <pre class=propdef>
10141014 Name : masonry-slack
1015- Value : <<length-percentage>>
1015+ Value : <<length-percentage>> | infinite
10161016 Initial : 1em
10171017 Percentages : relative to the [=grid-axis=] [=content box=] size of the [=masonry container=]
10181018 Inherited : no
@@ -1035,7 +1035,7 @@ Placement Precision: the 'masonry-slack' property</h3>
10351035 causing them to fill in order.
10361036
10371037 <dl dfn-type=value dfn-for=masonry-slack>
1038- : <dfn><<length>></dfn>
1038+ : <dfn><<length-percentage >></dfn>
10391039 :: Specifies the <dfn dfn for=masonry>tie threshold</dfn>
10401040 for the [=masonry container=] .
10411041 Placement positions are considered to be equally good (“tied”)
@@ -1044,6 +1044,19 @@ Placement Precision: the 'masonry-slack' property</h3>
10441044
10451045 Note: The initial value is a “small” distance (''1em'' )
10461046 that is probably appropriate to represent “close enough”.
1047+
1048+ : <dfn>infinite</dfn>
1049+ :: Specifies an infinite [=tie threshold=] .
1050+ This makes items distribute themselves strictly in order,
1051+ without considering the length of the tracks at all.
1052+
1053+ Note: This value can result in consecutive items being placed
1054+ in dramatically different positions in the [=stacking axis=] ,
1055+ which can be confusing to readers.
1056+ If the initial value (`1em`) is too small,
1057+ consider a larger value (such as `10em` or `50vh`)
1058+ instead of `infinite`.
1059+
10471060 </dl>
10481061
10491062 Issue: Is ''1em'' the right default?
0 commit comments