Source code
Revision control
Copy as Markdown
Other Tools
Test Info:
- This WPT test may be referenced by the following Test IDs:
- /css/css-sizing/stretch/stretch-max-inline-size-001.html - WPT Dashboard Interop Dashboard
<!DOCTYPE html>
<link rel="author" title="Daniel Holbert" href="mailto:dholbert@mozilla.com">
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<script src="/resources/check-layout-th.js"></script>
<meta name="assert"
content="max-inline-size:stretch (setting 'max-width' in this case) resolves and clamps as expected (producing similar results as if we had specified the keyword for the inline-size property)">
<style>
.cb {
inline-size: 50px;
block-size: 40px;
/* This margin & border are purely cosmetic and don't impact the sizing
* calculations in this test: */
margin: 5px;
border: 2px solid black;
/* This padding only comes into play for the subtests with absolutely
* positioned children (where our padding-box forms the containing block
* for the abspos child). */
padding-inline: 5px;
padding-block: 3px;
/* We make each containing block an inline-level box, so we can display
* subtests in multiple rows, for easier visualization: */
display: inline-block;
vertical-align: top;
}
.test {
/* We have 2+3 = 5px of margin in the inline axis. This means the stretched
* children should all have a border-box size that's 5px less than the
* containing block's content-box size, i.e. 50 - 5 = 45px. */
margin-inline-start: 2px;
margin-inline-end: 3px;
/* We also have some border/padding that UAs will need to account for
* when computing the stretched children's content-box sizes; but these
* don't reduce our `data-expected-width` expectations, since those
* correspond to the border-box size. */
border: 3px solid blue;
padding: 2px;
/* We expect "max-inline-size:stretch" to cause the used value of
* "inline-size" to be clamped to the resolved "stretch" size. */
max-inline-size: stretch;
/* This is intentionally larger than our containing block's inline-size,
* and we expect it to be clamped by our max-inline-size specified above
* in nearly all of this test's subtests. */
inline-size: 55px;
block-size: 20px;
background: fuchsia;
}
</style>
<script>
function runTests() {
checkLayout('[data-expected-width]');
// Add box-sizing:border-box (which shouldn't impact the actual resolved
// box sizes that 'stretch' produces, aside from one subtest that we skip
// for this pass), and retest:
for (let elem of document.querySelectorAll(".test")) {
if (!elem.hasAttribute("skip-second-pass")) {
elem.style.boxSizing = "border-box";
}
}
checkLayout('[data-expected-width]:not([skip-second-pass])');
}
</script>
<body onload="runTests()">
<!-- 'stretch' on a block box, replaced element, form controls, float: -->
<div class="cb">
<div class="test" data-expected-width="45"></div>
</div>
<div class="cb">
<canvas class="test" data-expected-width="45"></canvas>
</div>
<div class="cb">
<input class="test" data-expected-width="45">
</div>
<div class="cb">
<textarea class="test" data-expected-width="45"></textarea>
</div>
<div class="cb">
<button class="test" data-expected-width="45"></button>
</div>
<div class="cb">
<div class="test" style="float: left" data-expected-width="45"></div>
</div>
<br>
<!-- 'stretch' on various abspos configurations, which use the container's
padding-box as the area-to-fill (which in this case is 10px larger than
the container's content-box, hence the larger 'data-expected-*'
values vs. the previous subtests). -->
<!-- With 0 insets, the child's margin-box fills the CB's padding-box, so
the child's border-box should end being
cb-padding-box-size - child-margin-size = 60px - 5px = 55px -->
<div class="cb" style="position: relative">
<div class="test" style="position: absolute; inset-inline: 0;"
data-expected-width="55"></div>
</div>
<!-- With auto insets, the child is placed at its static position which is
the origin of the CB's content-box, and then 'stretch' makes it extend
to reach the far end of the CB's padding-box. So it should be as large
as the zero-insets case above, minus the CB's inline-start-padding
which is 5px. -->
<div class="cb" style="position: relative">
<div class="test" style="position: absolute" data-expected-width="50"></div>
</div>
<!-- When we specify an inset, the child should be as large as the
zero-insets case above, minus whatever nonzero inset we choose. -->
<div class="cb" style="position: relative">
<div class="test" style="position: absolute; inset-inline-start: 10px"
data-expected-width="45"></div>
</div>
<div class="cb" style="position: relative">
<div class="test" style="position: absolute; inset-inline-end: 10px"
data-expected-width="45"></div>
</div>
<!-- If an inset pushes the child past the edge of the CB, 'stretch' shrinks
to just the 10px needed for the child's border/padding: -->
<div class="cb" style="position: relative">
<div class="test" style="position: absolute; inset-inline-end: 55px"
data-expected-width="10"></div>
</div>
<div class="cb" style="position: relative">
<div class="test" style="position: absolute; inset-inline-start: 55px"
data-expected-width="10"></div>
</div>
<br>
<!-- 'stretch' on various abspos configurations in a grid: similar to
above, but the grid area forms the containing block. -->
<!-- Similar to zero insets case above, but just now in a grid: -->
<div class="cb"
style="display: inline-grid; position: relative">
<div class="test"
style="position: absolute; inset-inline: 0;"
data-expected-width="55"></div>
</div>
<!-- With no insets, we're placed at our static position which is the grid's
padding-box origin, and then we stretch to reach the far end of its
padding-box. So we should be as large as the zero-insets case above. -->
<div class="cb"
style="display: inline-grid; position: relative">
<div class="test"
style="position: absolute"
data-expected-width="55"></div>
</div>
<!-- When we specify an inset, the child should be as large as the
zero-insets case above, minus whatever nonzero inset we choose. -->
<div class="cb"
style="display: inline-grid; position: relative">
<div class="test"
style="position: absolute; inset-inline-start: 10px"
data-expected-width="45"></div>
</div>
<div class="cb"
style="display: inline-grid; position: relative">
<div class="test"
style="position: absolute; inset-inline-end: 10px"
data-expected-width="45"></div>
</div>
<!-- If an inset pushes the child past the edge of the CB, 'stretch' shrinks
to just the 10px needed for the child's border/padding: -->
<div class="cb"
style="display: inline-grid; position: relative">
<div class="test"
style="position: absolute; inset-inline-end: 55px"
data-expected-width="10"></div>
</div>
<div class="cb"
style="display: inline-grid; position: relative">
<div class="test"
style="position: absolute; inset-inline-start: 55px"
data-expected-width="10"></div>
</div>
<br>
<!-- 'stretch' on a flex item: -->
<div class="cb" style="display: inline-flex; flex-direction: row">
<div class="test" data-expected-width="45"></div>
</div>
<div class="cb" style="display: inline-flex; flex-direction: column">
<div class="test" data-expected-width="45"></div>
</div>
<!--...now with an extra-large sibling sharing the child's flex line, to be
sure our 'stretch' sizing value still resolves against the container size
rather than the flex line's size: -->
<div class="cb" style="display: inline-flex; flex-flow: column wrap">
<div class="test" data-expected-width="45"></div>
<div style="inline-size: 60px"></div>
</div>
<!-- 'stretch' on a grid item in a definite-size grid track: -->
<div class="cb" style="display: inline-grid; grid-template-columns: 35px">
<div class="test" data-expected-width="30"></div>
</div>
<!-- 'stretch' on a grid item in an automatically-sized grid track:
Here, the 'max-inline-size:stretch' doesn't get to make a difference,
because it doesn't resolve (and hence doesn't have any clamping effect)
during the column's intrinsic-sizing pass. So the grid column ends up
being sized to exactly fit the *unclamped* 'inline-size'; and that
column then establishes the containing block that we resolve the
"max-inline-size:stretch" keyword against. This ultimately means that
the max-inline-size happens to resolve to our unclamped inline-size,
and hence it trivially has no clamping impact. (This also means that
'box-sizing' *does affect the expected size* in this subtest, unlike the
rest of this test's subtests! So, we use a dummy attribute to opt this
subtest out of this test's second pass, to avoid incorrectly asserting
that our data-expected-width is still the target size when 'box-sizing'
is tweaked.) -->
<div class="cb" style="display: inline-grid">
<div class="test" data-expected-width="65" skip-second-pass></div>
</div>
</body>