-
Notifications
You must be signed in to change notification settings - Fork 674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-text-3] Disambiguation about soft wrap opportunities around replaced elements #9964
Comments
Another place that almost but not quite defines this (in the same direction) may be this:
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:
|
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> fantasai: There's an ambiguity in the spec<TabAtkins> fantasai: we talk about how line-breaking properties affect breaking between characters <TabAtkins> fantasai: and we talk about how line-breaking occurs before/after rpelaced elements <TabAtkins> fantasai: But we don't connect to the idea of line-breaking controlling breaks between replaced elements, or between replaced and characters <TabAtkins> fantasai: So proposal is to repalce references to "between or aroudn characters" with "between or around characters or atomic inlines" <TabAtkins> fantasai: This aligns with Chrome/WebKit behavior, and we think is more expected behavior than what Firefox is doing. <kizu> q+ <Rossen__> ack kizu <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 <TabAtkins> kizu: So if you have this combination of elements, white-space:no-wrap prevents wrapping; if you want wrapping you can remove it <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 <emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=225382 suggests this might be quirks-mode dependent too? <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. <TabAtkins> fantasai: If we had two characters in those spans, wrapping woudl be allowed. But two images, it is ambiguous in the spec. <TabAtkins> fantasai: So I don't think white-space *in* the element should affect wrapping *outside* the element <TabAtkins> fantasai: Controlling the wrapping of images would probably be useful, there's been suggestions for properties controlling that <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. <TabAtkins> fantasai: but that's a seaprate issue. This is just about behavior at element boundaries. <TabAtkins> fantasai: There is one thing I"m not sure is implemented yet, we tweaked the spec, and it might help your use-case <TabAtkins> fantasai: for webcompat we require there's a softwrap before and after each repalced, even if the next char is a nbsp <TabAtkins> fantasai: But we previously said it doesn't matter what it's next to - it just *always* gets a soft-wrap <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. <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. <TabAtkins> fantasai: (In addition to any future property that controls breaking beahvior) <kizu> Sounds good. <TabAtkins> Rossen__: Any feedback? Otherwise we'll resolve <TabAtkins> RESOLVED: Clarify spec about soft-wrap oppos before/after characters to also reference atomic inlines. <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: "正" |
…nes at element boundary, a=testonly Automatic update from web-platform-tests Tests for line breaking around atomic lines at element boundary See w3c/csswg-drafts#9964 -- wpt-commits: 609801f34c3d7098c1799dd131355c3b065322ab wpt-pr: 46489
…nes at element boundary, a=testonly Automatic update from web-platform-tests Tests for line breaking around atomic lines at element boundary See w3c/csswg-drafts#9964 -- wpt-commits: 609801f34c3d7098c1799dd131355c3b065322ab wpt-pr: 46489
…nes at element boundary, a=testonly Automatic update from web-platform-tests Tests for line breaking around atomic lines at element boundary See w3c/csswg-drafts#9964 -- wpt-commits: 609801f34c3d7098c1799dd131355c3b065322ab wpt-pr: 46489
Should there be a soft wrap opporunity in the middle of the following divs?
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:
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:
So I think we should clarify that the Chrome/Webkit behavior is the intended one, and do so with the following two additions:
The text was updated successfully, but these errors were encountered: