NEW 265374
Preserved trailing whitespace on white-space: normal lines should always hang
https://bugs.webkit.org/show_bug.cgi?id=265374
Summary Preserved trailing whitespace on white-space: normal lines should always hang
Andreu Botella
Reported 2023-11-27 06:06:44 PST
Created attachment 468764 [details] Sample In the attached sample, you have two divs with `white-space: normal` applied to the div, but the first line has regular spaces (U+0020) which are preserved because of being inside a `white-space: pre-wrap` inline; while the second line has ideographic spaces (U+3000), which don't collapse with `white-space: normal`. Neither of those have the non-space text appear centered. In CSS-TEXT-3 section 4.1.2 (https://drafts.csswg.org/css-text-3/#white-space-phase-2), step 4 says that on lines with `white-space: normal`, any preserved white space, other separators and tabs at the end of the line should hang unconditionally; i.e. the line should be aligned as if they weren't there. Ideographic spaces are "other separators", and therefore the second div should have the non-space text look centered in the line. Note also that the whole of section 4.1.2 talks about transformations that apply to a line, rather than to characters in the line. In particular, I think step 4 talks about which of those values of the `white-space` property applies to the line box, rather than to any characters in it. (Note that if a line has ideographic spaces with `white-space: normal` followed by spaces with `white-space: break-spaces`, the normal space run would have to somehow hang without the other hanging, even though only sequences at the start or end of a line can hang.) Therefore, since the line box in the first div has `white-space: none` (despite the trailing whitespace having `white-space: pre-wrap`), it should hang unconditionally, and the non-space text should look centered. (See also https://crbug.com/1504335 for a bug report on Chromium after we implemented conditional hanging, because in this case Chromium's presumably correct implementation was different from Gecko's and Webkit's behavior.)
Attachments
Sample (380 bytes, text/html)
2023-11-27 06:06 PST, Andreu Botella
no flags
Radar WebKit Bug Importer
Comment 1 2023-12-04 06:07:15 PST
Andreu Botella
Comment 2 2023-12-19 02:07:40 PST
I also opened this issue on Firefox, and there Jonathan Kew pointed out that the specs don't have a concept of a line box's styles. This is a concept in Blink (which I believe is also shared by Webkit), and I didn't realize it was not present in the specs at the time of implementing this in Blink. I opened https://github.com/w3c/csswg-drafts/issues/9724 on the CSSWG repo to clarify this.
Note You need to log in before you can comment on or make changes to this bug.