[css-text-3] Line breaking opportunities at the boundary of a white-space:pre inline element

[frivoal]

Browsers differ in behavior when faced with the following, if the line-end would normally fall between お and か (i.e. at the boundary of the span):

<p>あいうえお<span style="white-space:pre">か</span>きくけこ</p>

Live example here: http://jsbin.com/bedumox/edit?html,css,output

Firefox and Edge (and presto) allow the break between お and か. Safari and Chrome don't. Language tagging and the switching the word-break property between auto and break-all does not make any difference.

I suspect the Firefox / Edge behavior is correct, and the the Chrome / Safari behavior is a side effect of a bug of theirs that suppresses break opportunities at element boundaries [1][2], but I did not manage to find a justification either way in the spec for the case I am discussing here.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=282134
[2] https://bugs.webkit.org/show_bug.cgi?id=158771

[upsuper]

I believe the behavior of Chrome / Safari is definitely wrong. Considering CSS Ruby, by default <rb> has white-space: nowrap. If line breaking is not allowed before a span with white-space: nowrap, then the whole ruby is not breakable.

Basically, I don't think white-space can control the boundary of the span it is set on.

[frivoal]

@upsuper I agree. Next question: do you see something in the spec that already says that? Maybe it is there, but I cannot find it.

[upsuper]

It seems not. I cannot find anything either. Probably the spec should explicitly state that wrapping on boundaries of an inline box is controled by its parent's white-space.

[frivoal]

@upsuper Yes, wrapping on boundaries of an inline box being controlled by its parent's white-space sounds like the right thing to do and the right way to say it.

@fantasai @kojiishi, what do you editors think?

[kojiishi]

I think "it's parent" is correct.

[frivoal]

Agenda+ because we seem to have a start of a consensus, and I'd like to get a resolution so that I can send a pull request and a test or two.

[frivoal]

@r12a @fantasai You should probably discuss whether or not this is i18n related rather than go back and forth on adding the label.

The effects of this bug are not language specific, but it does affect Chinese/Japanese documents (and presumably other non space separated languages) more often that it affects English or other Latin-alphabet languages.

I think it is reasonable to mark as i18n any bug that predominantly English speaking editors / WG members might otherwise dismiss as a corner case because it doesn't affect them much even though speakers of other languages may run into it often.

[r12a]

@frivoal apparently Fantasai deleted all the i18n tags by mistake. I'm reinstating here (and will look for others that need reinstating when i get time). Thanks.