[css-text] Atomic inlines being equivalent to ID for line breaking is not web-compatible

[kojiishi]

The current CSS Text Line Breaking Details says:

The line breaking behavior of a replaced element or other atomic inline is equivalent to an ideographic character (Unicode linebreaking class ID [UAX14]), and additionally, for Web-compatibility, introduces a soft wrap opportunity between itself and any adjacent U+00A0 NO-BREAK SPACE character.

We've got a report saying this is not web-compatible. Tested that all browsers always break before and after atomic inlines.

Is this an intentional change that all other browsers are willing to match?

@fantasai @litherum @emilio @jfkthame

[frivoal]

My understanding was that "equivalent to ID" is considered the more useful behavior in theory, but that it alone is not be web compatible. However, Equivalent to ID and breaks between adjacent U+00A0 was expected to be web compatible. Have you found cases where the specified behavior would cause breakage?

[kojiishi]

Two cases were reported; atomic inline + ':' U+003A COLON and atomic inline + ';' U+003B SEMICOLON. In both cases, authors expect there's a break opportunity between them.

[kojiishi]

This issue was reported at
https://crbug.com/1025715: No breaking opportunity between SVG and ':' character

[css-meeting-bot]

The CSS Working Group just discussed [css-text] Atomic inlines being equivalent to ID for line breaking is not web-compatible, and agreed to the following:

• RESOLVED: Atomic inlines by default always introduce a break opportunity, regardless of context

The full IRC log of that discussion

<emilio> Topic: [css-text] Atomic inlines being equivalent to ID for line breaking is not web-compatible
<emilio> github: https://github.com//issues/4576
<RossenF2F> github:https://github.com//issues/4576
<emilio> florian: it's specified in CSS text that atomic inlines are equivalent to ideograph
<emilio> ... but apparently authors expect that there would be a break where breaks would usually be forbidden between a break and an ideograph
<emilio> ... (See https://bugs.chromium.org/p/chromium/issues/detail?id=1025715)
<emilio> fantasai: I'm sad about this
<emilio> ... there's a number of cases where images should behave more like characters
<emilio> ... and if we always break stuff like gagii
<fantasai> s/gagii/gaiji/
<emilio> ... will typeset badly
<emilio> hober: if it's possible for authors to write content to do the right thing and we have consistent behavior
<emilio> ... then we should put that on the spec and indicate how to tweak it
<emilio> fantasai: the current spec behavior doesn't match implementations but it's easy to tweak
<emilio> ... into solving all the different use cases
<emilio> florian: if we treat images like ID then you can use standard properties to allow it to break
<RossenF2F> q?
<emilio> ... otherwise we can't
<emilio> myles: well I agree we should solve it but we can't solve this this way because it's not web-compatible
<fremy> q?
<emilio> fantasai: we could reuse the line-break property
<emilio> ... and make the strict value make atomic inlines
<emilio> faceless: so this seems like the breakness depends on the image
<hober> q+
<emilio> ... can we set a property on an image?
<emilio> florian: line-break on the image would tweak this
<koji> q+
<florian> q+
<emilio> fantasai: The `line-break` property is exactly about the interactions between breaks and punctuation so I think it makes sense to reuse the strict value here.
<fantasai> there are wrap-* properties in css-text-4 that allow control over breaking, to forbid or allow unconditionally, but they're not context-dependent on surrounding punctuation, so they're not appropriate for this situation
<RossenF2F> ack hober
<emilio> hober: I like the shape of fantasai's compromise here... I think there are a couple open questions but I think that's the right direction
<emilio> ... I'm still kinda leaning for it to be a different property, but mostly for aesthetic reasons
<fremy> q+
<emilio> ... I'm concerned with the compat effect of reusing strict
<emilio> ... I'd be willing to agree that we should do something like this
<emilio> ... but whether it's the strict keyword or a new keyword should probably have some kind of research
<emilio> fantasai: I think not a lot of pages use line-break strict
<RossenF2F> ack koji
<emilio> ... and they're likely CJK which are more likely to use this behavior
<emilio> koji: I'd like to combine line-break normal with this behavior
<emilio> fantasai: you can have your paragraph with line-break: normal, but the images with line-break: strict
<emilio> koji: what about inline-block? Those are a block inside
<emilio> fantasai: I suspect those are much less likely to want this behavior
<myles> q+
<RossenF2F> ack florian
<emilio> florian: I think we could make the loosey image breaking behavior if we use `line-break` != `auto`
<emilio> ... that way it'd just work... non-default line-break is weird
<RossenF2F> ack fremy
<emilio> ... widening the scope of the issue a bit, is that there's another issue with breaking around images, which is that `&nbsp;` around it behave like normal spaces
<emilio> fremy: when I try to solve this myself is just putting a span on the break elements, but doesn't seem to be interoperable
<emilio> RossenF2F: also there's a lot CJK elements
<RossenF2F> q?
<RossenF2F> ack myles
<emilio> myles: I like that you can select the gaiji with a selector
<emilio> ... koji makes a really good point
<emilio> ... when I think about line-break values I think about text and paragraphs
<emilio> ... not images and inline-blocks
<emilio> fantasai: I think we can go with florian's proposal
<astearns> I'm less enthusiastic about having a text property modify the behavior of images as a side-effect
<emilio> myles: some people may want the break on the left of the image
<emilio> astearns++
<emilio> fantasai: we have controls for that in level 4
<emilio> myles: can this use them instead?
<emilio> fantasai: no you can't, because those are not contextual
<emilio> ... but opting in to treat this as an ideographic character is good
<emilio> ... the level 4 properties are unconditional
<emilio> ... emojis, small kana and such things these images should be treated like this
<emilio> ... which is why it fits with line-break
<emilio> myles: I'd like some more time to think about this
<emilio> ... maybe a way to tell an image which kind of text it wants to be
<emilio> ... I also think it's important to get the default behavior in the spec agreement with implementations
<emilio> RESOLVED: Atomic inlines by default always introduce a break opportunity, regardless of context
<emilio> ACTION: Investigate using the line-break property to tweak this behavior

[litherum]

I guess the question is: Is there a use case for wanting strict line-breaking in a paragraph, but still wanting breaking opportunities on both sides of images? I think yes, these two things are fairly distinct, and it's entirely reasonable for an author to want this combination of behaviors.

[litherum]

I suppose another option is to add a new value to the wrap-before and wrap-after properties. Maybe something like wrap-before: ideograph or something.

[frivoal]

I guess the question is: Is there a use case for wanting strict line-breaking in a paragraph, but still wanting breaking opportunities on both sides of images?

In that case, you could use p { line-break: strict; } img { line-break: auto; }

[frivoal]

I've made the edit corresponding to the resolution, and landed the corresponding test updates. Closing this issue, as that solves the original problem reported.

I've opened #4755 for the remaining part of this discussion, which is about adding a way to opt out of this compat mode and get some more text-like behavior on inline images.

[fantasai]

@frivoal Please open issues, not pull requests, for follow-up issues. I've filed #4949 for discussion.