[css-text-3] Reconsider atomic inlines overriding GL/WJ classes

See #4576 for some previous history...

For Web-compatibility, we needed to make atomic inlines provide a break opportunity even next to NBSP, but we had considered having it be a little more restrictive than creating a forced break opportunity everywhere. Originally we had hoped treating it as ID (plus an exception for NBSP) would work, but Chrome found that people filed bugs about their expectation that they would create break opportunities adjacent to punctuation (see #4576) so we went back to providing a blanket opportunity for all characters.

However, this doesn't give authors any control over breaking adjacent to atomic inlines, because even explicit characters like U+2060 WORD JOINER or U+FEFF ZERO WIDTH NO-BREAK SPACE cannot suppress the break opportunity.

My proposal is that we allow the explicit, non-tailorable Unicode line breaking controls other than NBSP to take precedence over our rule about atomic inlines. See http://unicode.org/reports/tr14/#Table1

nobr (or the equivalent CSS) seems to work for this case already? (At least, in Chrome it does.) Is this a Chrome spec violation?

@tabatkins

@tabatkins I tried this with <nobr> in Chrome as well before reporting the issue via Twitter.

Here is a similar example to my original example which uses <nobr>:
https://codepen.io/brandonmcconnell/pen/xxQZMZG/40fa8f6cfefe11ad24a200af0d3a4028

The div still wraps without the contents to the left of the <nobr>

Right, marked up like that it just suppressed a break between the two icons. If you want to suppress a break between the icons and the preceding word you need to include the preceding word in the nobr as well.

@tabatkins

@tabatkins Ah, so when dealing with markup generated by JS, would we need to do some sort of splitting abstraction like this? (REPL)

<script>
	const allText = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla sollicitudin magna a iaculis maximus. Proin eleifend ligula enim, suscipit semper est condimentum ac. Donec semper scelerisque neque sed ultricies. Aliquam ut scelerisque orci. Nullam et orci nec massa gravida porttitor. Maecenas dui dui, eleifend at fringilla quis, convallis eget elit. Mauris volutpat felis a magna finibus, quis venenatis ex laoreet. Nulla ac nisi urna. Mauris ut sapien sit amet mi sollicitudin mattis. Nulla finibus efficitur placerat. Morbi fringilla aliquet quam non posuere. Nullam sodales nisl ut ipsum varius, sit amet iaculis elit fringilla. Phasellus sit amet sem auctor ex ullamcorper.';
	
	const words = allText.split(' ');
	const lastWord = words.slice(-1)[0];
	const textBeforeNoBreak = words.slice(0, -1).join(' ');
</script>

{textBeforeNoBreak}
<nobr>
	{lastWord}
	<div class="attachment">
		<div class="icon">🌴</div>
		<div class="icon">🍫</div>
	</div>
</nobr>

<style>
	.attachment {
		display: inline-block;
		white-space: nowrap;
		padding-left: 1ch;
	}

	.icon {
		display: inline-flex;
		align-items: center;
		justify-content: center;
		width: 32px;
		aspect-ratio: 1;
		background: #eee;
		border-radius: 50%;
	}
</style>

It'd be great to not have to reply on JS to attach some elements like this to the text to ensure it doesn't get orphaned, similarly to how we can currently can do the same for text using  

@tabatkins

@tabatkins Making <nobr> work doesn't solve the problem of “these unicode characters that are explicitly supposed to control breaking aren't”. It might solve some use cases for it, but it doesn't change the fact that our behavior is stupid.

@brandonmcconnell The correct answer to that use case is to use wrap-before: avoid on the icon. But you'll have to convince implementers to implement it first. https://www.w3.org/TR/css-text-4/#wrap-before

The CSS Working Group just discussed [css-text-3] Reconsider atomic inlines overriding GL/WJ classes, and agreed to the following:

RESOLVED: accept proposal

The full IRC log of that discussion

<florian> fantasai: we have a problem that line breaking around images is weird
<florian> fantasai: people expect images to introduced a line breaking opportunity
<florian> [fantasai summarizes the issue]
<Rossen_> q?
<florian> fantasai: the proposal is that for Unicode characters with non tailorable line breaking properties, other than NBSP, should be honored and and take precedence
<florian> +1
<florian> florian: +1
<florian> iank_: not too familiar with the implementation details, will sync with Koji before a definite answer
<florian> iank_: seems ok
<florian> fantasai: main concern is probably not implementation complexity, but web compat, but it seems ok here
<florian> iank_: is there any complexity with ?
<florian> s/with ?/with reordering controls/
<florian> fantasai: there's only a handful of characters
<florian> fantasai: should not have any effect on bidi
<florian> q+
<florian> iank_: seems fine, just want to check with Koji
<florian> q-
<florian> Rossen_: can we resolve on it, and you bring it back if there's an issue
<hober> q+
<florian> hober: similar to Ian, I want to talk internally, like with the books people
<Rossen_> ack hober
<florian> hober: can bring it back later if we have additional feedback
<florian> RESOLVED: accept proposal

[css-text] non-tailorable Unicode line breaking controls other than N…

[css-text] Reduce ambiguity in spec text