Re: [csswg-drafts] [css-text-3] Disambiguation about soft wrap opportunities around replaced elements (#9964)

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: There's an ambiguity in the spec<br>
&lt;TabAtkins> fantasai: we talk about how line-breaking properties affect breaking between characters<br>
&lt;TabAtkins> fantasai: and we talk about how line-breaking occurs before/after rpelaced elements<br>
&lt;TabAtkins> fantasai: But we don't connect to the idea of line-breaking controlling breaks between replaced elements, or between replaced and characters<br>
&lt;TabAtkins> fantasai: So proposal is to repalce references to "between or aroudn characters" with "between or around characters or atomic inlines"<br>
&lt;TabAtkins> fantasai: This aligns with Chrome/WebKit behavior, and we think is more expected behavior than what Firefox is doing.<br>
&lt;kizu> q+<br>
&lt;Rossen__> ack kizu<br>
&lt;TabAtkins> 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<br>
&lt;TabAtkins> kizu: So if you have this combination of elements, white-space:no-wrap prevents wrapping; if you want wrapping you can remove it<br>
&lt;TabAtkins> 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<br>
&lt;emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=225382 suggests this might be quirks-mode dependent too?<br>
&lt;TabAtkins> 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.<br>
&lt;TabAtkins> fantasai: If we had two characters in those spans, wrapping woudl be allowed. But two images, it is ambiguous in the spec.<br>
&lt;TabAtkins> fantasai: So I don't think white-space *in* the element should affect wrapping *outside* the element<br>
&lt;TabAtkins> fantasai: Controlling the wrapping of images would probably be useful, there's been suggestions for properties controlling that<br>
&lt;TabAtkins> 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.<br>
&lt;TabAtkins> fantasai: but that's a seaprate issue. This is just about behavior at element boundaries.<br>
&lt;TabAtkins> fantasai: There is one thing I"m not sure is implemented yet, we tweaked the spec, and it might help your use-case<br>
&lt;TabAtkins> fantasai: for webcompat we require there's a softwrap before and after each repalced, even if the next char is a nbsp<br>
&lt;TabAtkins> fantasai: But we previously said it doesn't matter what it's next to - it just *always* gets a soft-wrap<br>
&lt;TabAtkins> 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.<br>
&lt;TabAtkins> 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.<br>
&lt;TabAtkins> fantasai: (In addition to any future property that controls breaking beahvior)<br>
&lt;kizu> Sounds good.<br>
&lt;TabAtkins> Rossen__: Any feedback? Otherwise we'll resolve<br>
&lt;TabAtkins> RESOLVED: Clarify spec about soft-wrap oppos before/after characters to also reference atomic inlines.<br>
&lt;dbaron> 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: "正"<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9964#issuecomment-2048011354 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 10 April 2024 16:36:23 UTC