word-break:break-all does not apply to some characters that should be affected (e.g, U+3D EQUALS SIGN)
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox72 | --- | fixed |
People
(Reporter: dapsdh, Assigned: jfkthame)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Steps to reproduce:
- Open the attached break_all.html in FireFox.
- 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.
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.
(If we agree it's Chrome's bug, we should make sure there's a Chromium bug report filed before closing this.)
Assignee | ||
Comment 3•4 years ago
•
|
||
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.]
Assignee | ||
Comment 4•4 years ago
|
||
(Or perhaps the author really wants line-break: anywhere
, although I'm not sure that's implemented in Safari yet.)
Assignee | ||
Comment 5•4 years ago
•
|
||
Hmm, it looks like we do actually have a bug here. I checked in https://www.unicode.org/Public/UCD/latest/ucd/LineBreak.txt 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.)
Assignee | ||
Comment 6•4 years ago
|
||
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.
Assignee | ||
Comment 7•4 years ago
|
||
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1ff83b67e453 Add support for characters with CLASS_CLOSE_LIKE_CHARACTER missed in implementation of word-break:break-all. r=m_kato
Comment 9•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Description
•