Steps to reproduce
Serve this minimal page and load it in moli (moli fetch --layout --dump screenshot or any layout-enabled path):
<!DOCTYPE html>
<html>
<head><style>
#c { white-space: nowrap; width: 250px; }
#c span { display: inline-block; width: 100px; height: 20px; background: #ddd; }
</style></head>
<body>
<div id="c"><span>1</span><span>2</span><span>3</span><span>4</span><span>5</span></div>
<!-- control: pure-text nowrap wraps correctly -->
<div style="white-space: nowrap; width: 250px">aaaaaaaaaa bbbbbbbbbb cccccccccc dddddddddd eeeeeeeeee</div>
</body>
</html>Then measure each span's offsetTop via CDP Runtime.evaluate.
Expected (Chrome 154)
white-space: nowrap suppresses all soft wrap opportunities, so the five 100px inline-block spans stay on one line:
offsetTop = [8, 8, 8, 8, 8] (single line, scrollWidth = 500)
Actual (moli 1.1.10, 9b2f86b)
The container wraps between the inline-block spans, as if soft wrap opportunities existed between them:
offsetTop = [8, 8, 28, 28, 48] (three lines, scrollWidth = 250)
Notes
- The control case (pure text under the same
white-space: nowrap) is correct on both engines — the defect is specific to wrap points between inline-block elements.
- Adding
overflow-x: scroll does not change the result; the spurious breaks are real layout breaks, not paint artifacts.
Environment
- moli 1.1.10 (9b2f86b), Linux,
--layout
- Differential baseline: Chrome 154.0.8037.57 (headless=new), same probe
Steps to reproduce
Serve this minimal page and load it in moli (
moli fetch --layout --dump screenshotor any layout-enabled path):Then measure each span's
offsetTopvia CDPRuntime.evaluate.Expected (Chrome 154)
white-space: nowrapsuppresses all soft wrap opportunities, so the five 100pxinline-blockspans stay on one line:Actual (moli 1.1.10, 9b2f86b)
The container wraps between the inline-block spans, as if soft wrap opportunities existed between them:
Notes
white-space: nowrap) is correct on both engines — the defect is specific to wrap points betweeninline-blockelements.overflow-x: scrolldoes not change the result; the spurious breaks are real layout breaks, not paint artifacts.Environment
--layout