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