[css-text-3] Disambiguation about soft wrap opportunities around replaced elements

[frivoal]

Should there be a soft wrap opporunity in the middle of the following divs?

<style>
div {
  width: 0px;
  white-space: normal;
}
span {
  white-space: nowrap;
}
img {  width: 30px;  height: 30px; }

style>
<div><span><img>span><span><img>span>div>

<div><span>稲span><span><img>span>div>

<div><span><img>span><span>稲span>div>

Currently, we don't have interop, with Chrome and Safari allowing a break, and Firefox not.

I believe that the spec is not clear. The parts that seem relevant but don't actually spell it out clearly would be the following two points from https://drafts.csswg.org/css-text-4/#line-break-details:

• For Web-compatibility there is a soft wrap opportunity before and after each replaced element or other atomic inline, even when adjacent to a character that would normally suppress them, including U+00A0 NO-BREAK SPACE. However, with the exception of U+00A0 NO-BREAK SPACE, there must be no soft wrap opportunity between atomic inlines and adjacent characters belonging to the Unicode GL, WJ, or ZWJ line breaking classes. [UAX14]
  Tests
• For soft wrap opportunities created by characters that disappear at the line break (e.g. U+0020 SPACE), properties on the box directly containing that character control the line breaking at that opportunity. For soft wrap opportunities defined by the boundary between two characters, the white-space property on the nearest common ancestor of the two characters controls breaking; which elements’ line-break, word-break, and overflow-wrap properties control the determination of soft wrap opportunities at such boundaries is undefined in this level.

The goal of the first rule quoted above is to make replaced elements / atomic inlines break more than other things. The Firefox implementation makes then break less than ideographs, which goes against that expectation.

But I think a literal interpretation of the spec falls short of saying what to do, because:

1. the second rule talks about the boundary between two characters, and replaced elements or other atomic inlines are not characters
2. the first rule says that there's a wrap opportunity before and after, which is similar but not identical to making it defined by the boundary between two things.

So I think we should clarify that the Chrome/Webkit behavior is the intended one, and do so with the following two additions:

For soft wrap opportunities defined by the boundary between two characters, replaced element, or other atomic inlines, […]

there is a soft wrap opportunity at the boundary before and after each replaced element or other atomic inline

[frivoal]

Another place that almost but not quite defines this (in the same direction) may be this:

For soft wrap opportunities before the first or after the last character of a box, the break occurs immediately before/after the box (at its margin edge) rather than breaking the box between its content edge and the content.

Here, the soft wrap opportunity before and after each replaced element is the first or last thing in a box, but not the first/last character in a box.

So we could also fix this with the following addition:

For soft wrap opportunities before the first or after the last character, replaced element, or atomic inline of a box […]

[css-meeting-bot]

The CSS Working Group just discussed [css-text-3] Disambiguation about soft wrap opportunities around replaced elements, and agreed to the following:

• RESOLVED: Clarify spec about soft-wrap oppos before/after characters to also reference atomic inlines.

The full IRC log of that discussion

fantasai: There's an ambiguity in the spec
fantasai: we talk about how line-breaking properties affect breaking between characters
fantasai: and we talk about how line-breaking occurs before/after rpelaced elements
fantasai: But we don't connect to the idea of line-breaking controlling breaks between replaced elements, or between replaced and characters
fantasai: So proposal is to repalce references to "between or aroudn characters" with "between or around characters or atomic inlines"
fantasai: This aligns with Chrome/WebKit behavior, and we think is more expected behavior than what Firefox is doing.
q+
ack kizu
kizu: I encountered this recently. I remember wanting to not allow breaks, aligning with firefox, because otherwise i don't think there's a way for an author to disallow the wrapping
kizu: So if you have this combination of elements, white-space:no-wrap prevents wrapping; if you want wrapping you can remove it
kizu: If you want it to work differently, it would be nice to add another way to avoid introducing soft-wrap opportunities between replaced or replaced and text
https://bugzilla.mozilla.org/show_bug.cgi?id=225382 suggests this might be quirks-mode dependent too?
fantasai: This is specifically cases where there's a span around an image, and another span around an image, and they're adjoining. Between those two spans, the white-space property allows wrapping.
fantasai: If we had two characters in those spans, wrapping woudl be allowed. But two images, it is ambiguous in the spec.
fantasai: So I don't think white-space *in* the element should affect wrapping *outside* the element
fantasai: Controlling the wrapping of images would probably be useful, there's been suggestions for properties controlling that
fantasai: Web-compat behavior, which allows more breaks, or like an Enlgihs letter, or like a Japanese character. Those are the common ways you'd want it to behave.
fantasai: but that's a seaprate issue. This is just about behavior at element boundaries.
fantasai: There is one thing I"m not sure is implemented yet, we tweaked the spec, and it might help your use-case
fantasai: for webcompat we require there's a softwrap before and after each repalced, even if the next char is a nbsp
fantasai: But we previously said it doesn't matter what it's next to - it just *always* gets a soft-wrap
fantasai: But there are some other gluey characters in Unicode that are less commonly used, so we recently updated the spec to not break between an image and *those* characters.
fantasai: we probably don't ahve interop on that yet, it's a recent change. But that would allow you more control over breaking if you use those characters.
fantasai: (In addition to any future property that controls breaking beahvior)
Sounds good.
Rossen__: Any feedback? Otherwise we'll resolve
RESOLVED: Clarify spec about soft-wrap oppos before/after characters to also reference atomic inlines.
One off-topic thought is that a property for controlling the breaking behavior of an image could take a string that means "have the breaking behavior of this text", e.g., replaced-break-as: "A" or replaced-break-as: "正"