1837706 - Line break before closing paren

Status: RESOLVED INVALID

(Core :: Layout: Block and Inline, defect)

Description

[asmus]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

There are a series of websites that use "(" followed by <span display="inline-block">some very short text</span> and then a ")". I set the width of the containing element so that it excluded the trailing ")".

I also set the width a little narrower than that and observed what happens.

Example file: https://www.icann.org/sites/default/files/lgr/rz-lgr-5-myanmar-script-26may22-en.html, for example on line 648 (and several others).

Actual results:

The line was broken with the ")" starting the next line. After narrowing the window, the line was broken with the "(" ending the first line.

Expected results:

A ")" should never start the next line after an automatic line break, except in the most unusual emergencies. The presence of a very short span, even if it is "inline block" should not result in the line breaking before the ")".

(Nor should the line have been broken after the "(" for the slightly narrower line width).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Block and Inline' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Screenshot on Google Chrome 115.png

I can reproduce a similar behavior on Google Chrome. The "(" or ")" can be on its own line in a very narrow container.

Asmus, are your expected results based on some rules in UAX #14?

Comment 3

[asmus]

The narrow column really shows the effect, but I see this also at the end of rather normal line lengths; meaning that this happens even in cases where there's no interference from any form of emergency line break.

UAX #14 contains rules for line break of OP and CL line break classes in LB13 and LB14. The opening paren should be treated like OP and the closing one like CL.

I suspect that the presence of the <span> element somehow interferes with the linebreaking, but for LB13 or LB14 it does not matter if OP are next to letters or next to an image (or anything else that flows with the line).

UAX #14 is not unique in this, being based in these cases, on widely accepted and widely implemented line breaking behaviors.

Comment 4

[asmus]

Meant to write "OP and CL are next to"

Comment 5

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I suspect that the presence of the <span> element somehow interferes with the linebreaking, but for LB13 or LB14 it does not matter if OP are next to letters or next to an image (or anything else that flows with the line).

As far as I know, gecko only sends a string to line breaking API, so it is possible the <span> element creates line breaking opportunity around it.

For line breaking in general, we are working on integrating ICU4X segmenter in bug 1719535. Hope it will help a bit.

Comment 6

[Jonathan Kew [:jfkthame]]

The behavior here is due to the presence of display: inline-block on the <span>. This means the contents of the span is no longer part of the text run to which line-breaking rules are applied; instead, the span as a whole is an "atomic inline" object, and the question is what happens at the boundaries between this atomic inline and the surrounding text.

The CSS Text spec says that

For Web-compatibility there is a soft wrap opportunity before and after each replaced element or other atomic inline, even when adjacent to a character that would normally suppress them, such as U+00A0 NO-BREAK SPACE.

So AFAICT this is expected according to the spec, and apparently this behavior is required for web compatibility.

Was there a particular reason for using display: inline-block there? Would white-space: nowrap perhaps have been a better choice, if the intent was to avoid line breaking within it?

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Daniel Holbert [:dholbert]]

Triaging as S3 to take this out of the triage queue, but this might be not-a-bug based on comment 6.

(In reply to Jonathan Kew [:jfkthame] from comment #6)

Was there a particular reason for using display: inline-block there? Would white-space: nowrap perhaps have been a better choice, if the intent was to avoid line breaking within it?

Ticking needinfo=reporter for this^ question.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #9)

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

I think the needinfo'd info here was just informational, not crucial to the reported bug itself. So: not INCOMPLETE.

TYLin, do you think we can close this as INVALID given comment 2 / comment 4 / comment 6?

Comment 11

[asmus]

The choice of inline span is not predicated on wrapping behavior inside the span, but necessitated by the need for preventing combining marks overhanging the opening paren. The contents of the ( ) would (potentially) be every character in Unicode plus some selected character sequences, as can be seen from the sample. The span seems to do a good job of containing all such strings inside the () without the need for adding random padding characters.

Comment 12

[Jonathan Kew [:jfkthame]]

(In reply to asmus from comment #11)

The choice of inline span is not predicated on wrapping behavior inside the span, but necessitated by the need for preventing combining marks overhanging the opening paren. The contents of the ( ) would (potentially) be every character in Unicode plus some selected character sequences, as can be seen from the sample. The span seems to do a good job of containing all such strings inside the () without the need for adding random padding characters.

Hmm, I see. Perhaps the most robust solution, then, would be to wrap the entire sequence of opening-paren, inline-block span containing the Unicode character(s), and closing-paren in a further span, also with display:inline-block. That will ensure that the entire unit including the surrounding parens stays together during line wrapping.

Alternatively, have you considered generating the parens as pseudo-elements around the inline-block? So instead of, for example,

<li>CMM5, a set of consonants that can be followed by medial sequence U+103D U+103E (<span style="display:inline-block">&nbsp;ွှ</span>) </li>

where the parens are part of the surrounding text, but (as CSS Text specifies) a line-break may occur immediately before or after the inline-block element, you could use

<li>CMM5, a set of consonants that can be followed by medial sequence U+103D U+103E <span class="parens">&nbsp;ွှ</span></li>

with style rules

.parens { display: inline-block }
.parens::before { content: '(' }
.parens::after { content: ')' }

to get the desired presentation.

Comment 13

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Re comment 10:

TYLin, do you think we can close this as INVALID given comment 2 / comment 4 / comment 6?

I don't feel we'd want to change how we break lines around inline blocks given our behavior is similar to other browsers per comment 2. Shipping ICU4X line segmenter (bug 1854032) doesn't help in this case.

Comment 12 has some ideas to get the desired behavior, so I'm inclined to close this.

Comment 14

[asmus]

The workaround in the comment is not a drop-in replacement, unfortunately. Because the actual example used inline styles, where pseudo elements are not available. Just wanted to note that for the record.