Honor the linebreak generated by atomic inline at the edge of a `white-space:nowrap` container
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome, parity-safari, webcompat:platform-bug)
Attachments
(1 file)
722 bytes,
text/html
|
Details |
[This is the underlying platform bug for webcompat site-report bug 1923272.]
STR:
- Load attached testcase.
EXPECTED RESULTS:
The first chunk should have a linebreak after "First span" (and the rest should have no linebreaks)
ACTUAL RESULTS:
The first chunk does not have a linebreak (but it should). (The rest don't have linebreaks, which is correct for them.)
Chromium/WebKit give EXPECTED RESULTS. Firefox gives ACTUAL RESULTS.
I'm using Firefox Nightly 133.0a1 (2024-10-26) (64-bit) on Ubuntu 24.10.
As discussed in bug 1923272, I think the expected-results do seem to be what the spec calls for. Specifically:
- Per https://drafts.csswg.org/css-text-4/#line-break-details : an atomic inline generates a soft wrap opportunity before and after itself.
- Per a later bullet point in that same section: a soft wrap opportunity before the first character of a box (or after the last), the break would occur outside the box. (I'm not sure whether the wrap opportunity itself is considered to be outside of the box, but the resulting break is, at least.)
- When we specify "white-space:nowrap", it controls "whether lines may wrap at unforced soft wrap opportunities".
- In the first part of the testcase, the generated break (and maybe the soft wrap opportunity itself) is considered to be outside of the box that has
white-space:nowrap
applied to it, sonowrap
does not suppress the break.
Notably: if there's another layer of wrapper that imposeswhite-space:nowrap
at the spot where the break has been propagated to, then it should be suppressed (and Chromium/WebKit do suppress it). That's what the second part of this testcase tests.
Reporter | ||
Updated•4 months ago
|
Description
•