Repository navigation
[css-line-breaking] Soft-break vs. <br>, inside embedded opposiate directional run #5121
Description
section-5 (https://drafts.csswg.org/css-text-3/#line-breaking) talks about soft and forced line break but says nothing about the effect, i.e. the rendering. Is it the same in both cases? That is, if a line is wrapped at some place, should the resulting lines appear as if it was a forced break at the same place?
As for bidi texts, if a line break occurs inside a phrase that is progressing in opposite direction, wrt the surrounding context, the break (rightfully) does not end the "embedded" base direction, unlike HTML <br>.
As a consequence, if the next line begins with a directionally ambiguous character, the rest of the phrase takes the global opposite base direction.
Example (in RTL context):
The 1st two lines result from a text wrapped (soft-break) before the number 2. The whole Latin string flows LTR. Then the same text with forced-break at the same position. In the last line, the rest of the Latin string flows RTL.
Looks odd to me.
Source:
<div dir="rtl" style="width: 50%;">
<p>
تحدثنا وقالت في لغتها:
« I should be living at 2, Atlas street</span> »
ثم ذهبت.
</p>
<p>
تحدثنا وقالت في لغتها:
« I should be living at<br> 2, Atlas street</span> »
ثم ذهبت.
</p>
</div>
note <br> before 2 in the second <p>.
Can CSS line breaking spec/rules consider such case (or similar)? I didn't see that in the document.
Or simply indicate in the first para of section-5 (https://drafts.csswg.org/css-text-3/#line-breaking), that forced break and soft break occurring at the same point, may have differences in rendering for some scripts (or something like).
Activity
fantasai commentedon May 27, 2020
Soft wraps have LS behavior, whereas forced breaks have PS behavior. The rendering should otherwise be the same. I think Writing Modes is pretty clear about the latter point (https://www.w3.org/TR/css-writing-modes-3/#bidi-algo) but maybe css-text-3 need to be clearer about the former.
ntounsi commentedon Jun 11, 2020
My point was: is this difference in rendering something that needs to be resolved? (OK, it is a very special case).
For example
line-breakproperty could have one of its values :<br>.kojiishi commentedon Jun 11, 2020
Using
<div>instead of<br>shows the same result.Test: https://output.jsbin.com/lofidec
The bidi algorithm is defined by Unicode UAX #9 UNICODE BIDIRECTIONAL ALGORITHM. It resolves the bidi level for each paragraph, so if a paragraph is split into two, the algorithm may compute different results.
In the "Status" section of the UAX#9, there's a link to the feedback form. If you feel there's a room to improve the algorithm, please feedback to Unicode.
ntounsi commentedon Jun 17, 2020
Yes okay,
<br>acts as a paragraph separator, hence the result.However, since there is linebreaking processing model being discussed in CSS (§5), why not take this opportunity to try to do something for this specific problem.
fantasai commentedon Jul 1, 2020
@ntounsi
line-breakcontrols soft wrap opportunities. And none of these create a bidi paragraph break. So I don't understand your comment #5121 (comment)ntounsi commentedon Jul 1, 2020
@fantasai Sorry, I may have misspoke. Forget about Bidi paragraph break.
I was asking if it would be possible that
line-breakalso controls whether soft wrap opportunity will create a difference in rendering (compared to hard break).fantasai commentedon Jul 2, 2020
@ntounsi No,
line-breakis only about where break opportunities occur. It shouldn't be redefining what<br>means.fantasai commentedon Jul 2, 2020
Note: The application of bidi to CSS paragraph rendering is defined in https://www.w3.org/TR/css-writing-modes-3/#bidi-algo
[css-text-3] Cross-reference to where bidi line breaking interactions…
fantasai commentedon Jul 2, 2020
@ntounsi Added some cross-references to the relevant sections of Writing Modes and UAX9. Is there something else you wanted here, or should we close the issue?
ntounsi commentedon Jul 2, 2020
My question was also to know roughly if a break opportunity should not occur before a bidi-ambiguous character for example.
ntounsi commentedon Jul 2, 2020
@fantasai Thank you for clarifications and the editorial change.