[css-text-3] line breaks and ideographic space

[frivoal]

(reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1450228)

Browsers differ in how they handle line breaks for IDEOGRAPHIC SPACE (U+3000):

• Firefox allows break before and after
• Chrome and Safari forbid a break before, and allow a break after
• Edge forbids a break before and allow a break after, but also allows hanging overflow

try it here

Quoting @MurakamiShinyu

This is important because IDEOGRAPHIC SPACE is normally used after "！" or "？" in the middle of a paragraph to keep 1em space after such punctuation marks as explained in JLREQ 3.1.6 Positioning of Dividing Punctuation Marks (Question Mark and Exclamation Mark) and Hyphens

That logic would favor Edge's behavior.

UAX-14 says that IDEOGRAPHIC SPACE (U+3000) has class BA (for break after), which would support the behavior of Chrome/Safari/Edge over Firefox's, but:

• I cannot I cannot find any reference in css-text-3 to UAX-14's BA class
• The line-break property does not mention IDEOGRAPHIC SPACE (U+3000)

Should we reference the BA class somehow?
Should we directly list DEOGRAPHIC SPACE (U+3000) in some level of line-break?
Should we say something about allowing/requiring it to hang?

[fantasai]

CSS Text Level 3 does not normatively define the line breaking behavior of every character. Nor does it normatively reference UAX14's tables, because while they are a good start, they do not represent the ideal breaking behavior of every language.

We could add specific rules for ideographic space. Allowing it to hang seems reasonable: if @MurakamiShinyu agrees we should specify that I'm happy to do it. Note that if it hangs, it effectively is BA because it's effectively zero-width when occurring at the end of the line. ;)

[MurakamiShinyu]

Yes, I agree the behavior allowing hanging is preferable.

[frivoal]

I wonder what we should do about runs of IDEOGRAPHIC SPACEs should the whole thing hang? Only the last one? Hopefully we can just treat that as an edge case that's not really how people should write web pages, and spec whatever is simplest.

[frivoal]

@MurakamiShinyu Do you have a suggestion about whether to hang multiple ideographic spaces? Or maybe we should hang one and wrap the rest?

[frivoal]

f55dc74 hangs the whole sequence of ideographic spaces at the end of the line, let us know if that's fine.

[frivoal]

Tests: web-platform-tests/wpt#13338

[macnmm]

I know, not web, but InDesign allows the treatment of U+3000 to wrap like other non-space characters, depending on the paragraph composer chosen: Roman composer treats U+3000 like ideographic characters (they wrap); Japanese composer treats as white space (allowing them to hang). I think there are use cases where strings of U+3000 would be expected to wrap the line, so having a selector may be desirable. For me, I like that there is also the U+2003 for when you want the space to hang, so I prefer treating U+3000 as wrapping and U+2003 as hanging.

[frivoal]

@macnmm
Either of the following two comments should become new issues if you want to continue discussing them. I'm responding here for now, but if you think the case isn't closed, I'd appreciate if you could file them separately

---

I don't think we define U+2003 as hanging. Should we, for reasons other than CJK? currently, we only hang U+0020 and U+3000. Should that be generalized to all sorts of spaces? Many-but-not-all sorts of spaces?

---

As for having a switch, we effectively have one: white-space: break-spaces disallows spaces from hanging / being removed, and requires them to wrap instead. It does not allow (by itself) wrapping before U+3000, since that still has the UAX14 line breaking class of BA, but if there's a series of U+3000, the subsequent ones will wrap, and if the first one doesn't fit, it will bring the preceding character together with it to the next line.

white-space: break-spaces isn't a switch that only does that, though. It also stops sequences of U+0020 from collapsing, and preserves line breaks from the source, just like white-space: pre-wrap would.

Whether that's acceptable or not, I am not sure, it depends on the use case. Which brings me to: what is the need that drives wrapping U+3000 in the InDesign roman paragraph composer? Is that because of a particular need, or does it just falls out of not handling CJK characters specially, but isn't particularly need driven?

[macnmm]

The need was an edge case when converting old file formats in which the user used U+3000 to indent or place text on embox boundaries on the page, expecting them to wrap like other CJK characters would.
My memory of this is that both composers had this behavior; I was surprised there is a difference when I just checked, but have not dug into why the J composers now hang U+3000, when my memory was that they wrap in both.

[frivoal]

That use case doesn't really seem to apply to the web.