Closed Bug 1595645 Opened 5 months ago Closed 5 months ago

word-break:break-all does not apply to some characters that should be affected (e.g, U+3D EQUALS SIGN)


(Core :: Layout: Text and Fonts, defect, P3)

70 Branch



Tracking Status
firefox72 --- fixed


(Reporter: dapsdh, Assigned: jfkthame)




(2 files)

Attached file break_all.html

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

  1. Open the attached break_all.html in FireFox.
  2. Compare with the results from other browsers.

Actual results:

Double hyphens are displayed as a line beyond the block area.

Expected results:

Special symbols should be displayed on several lines like other letters.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core

The spec's definition is:

Breaking is allowed within “words”: specifically, in addition to soft wrap opportunities allowed for normal, any typographic character units resolving to the NU (“numeric”), AL (“alphabetic”), or SA (“Southeast Asian”) line breaking classes [UAX14] are instead treated as ID (“ideographic characters”) for the purpose of line-breaking. Hyphenation is not applied. This option is used mostly in a context where the text consists predominantly of CJK characters with only short non-CJK excerpts, and it is desired that the text be better distributed on each line.

I'm not 100% sure (since I didn't look up what line breaking class equals is), but I suspect that means that our behavior is correct and Chrome's is wrong.

There's also some relevant discussion in w3c/csswg-drafts#1171.

I couldn't find a Chromium bug.

Summary: Break-all does not apply to special characters. → word-break:break-all does not apply to special characters (e.g, U+3D EQUALS SIGN)

(If we agree it's Chrome's bug, we should make sure there's a Chromium bug report filed before closing this.)

Yes, I believe this is a Chromium bug, as word-break is specifically about break opportunities within words where they wouldn't normally be allowed. A long string of = characters is not a "word". (I haven't re-read all the old discussion yet, though.)

Basically, I think word-break is the wrong property for an author to use an example like this; the desired behavior is available (more interoperably) using overflow-wrap:break-word.

[edited: I originally wrote word-wrap here where I meant to refer to word-break, making the comment rather confusing.]

(Or perhaps the author really wants line-break: anywhere, although I'm not sure that's implemented in Safari yet.)

Hmm, it looks like we do actually have a bug here. I checked in and (somewhat surprisingly, at least to me) the equals sign U+003D is assigned to line-breaking class AL.

Therefore, it would be expected that word-break: break-all does affect a string of = characters.

(Though I still think overflow-wrap or line-break are better properties to use in this case.)

OK, this was an oversight in the implementation of word-break: break-all, and we should just fix it: according to the spec description of break-all, in conjunction with the Unicode line-break class of EQUALS, this example should indeed break within the "=====" the sequences.

Nevertheless, I believe there are still some interop issues in this area, partly because the CSS specs explicitly don't define exactly where line-break opportunities occur (and neither does Unicode: it provides some default properties and rules, but many of them are explicitly tailorable). And in general examples like the one here would be better using one of the other break-controlling properties; word-break was designed primarily for certain CJK use cases.

Ever confirmed: true
Priority: -- → P3
Summary: word-break:break-all does not apply to special characters (e.g, U+3D EQUALS SIGN) → word-break:break-all does not apply to some characters that should be affected (e.g, U+3D EQUALS SIGN)
Pushed by
Add support for characters with CLASS_CLOSE_LIKE_CHARACTER missed in implementation of word-break:break-all. r=m_kato
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Assignee: nobody → jfkthame
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.