Open
Bug 1347808
Opened 6 years ago
Updated 8 months ago
A long string of hyphens does not wrap in Firefox, but does in other browsers
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Core
Layout: Text and Fonts
Tracking
()
NEW
Webcompat Priority | P2 |
People
(Reporter: dholbert, Unassigned)
References
Details
Attachments
(2 files)
(Filing this for https://github.com/webcompat/web-bugs/issues/5080 ) STR: 1. Load attached testcase. EXPECTED RESULTS: Hyphens wrap to multiple lines, staying inside of their <div> container. ACTUAL RESULTS: Hyphens do not wrap, and overflow their <div> container.
Reporter | ||
Comment 1•6 years ago
|
||
Chrome 55, Edge 14, Safari, and Opera all give EXPECTED RESULTS. (The latter two I didn't test myself, but I'm going off of reports on the webcompat issue & Blink/WebKit family ties.) Firefox gives ACTUAL RESULTS. So, we're the odd one out on this behavior.
Reporter | ||
Comment 2•6 years ago
|
||
I think other browsers are treating each hyphen as a "soft wrap opportunity", and this is special behavior for hyphens and not for other characters. (karlcow discovered https://www.w3.org/TR/css-text-3/#soft-wrap-opportunity which has some spec text about this, including "CSS does not fully define where soft wrap opportunities occur". So this is a bit under-specified, and we should probably align with other browsers on this case for interop.)
Reporter | ||
Comment 3•6 years ago
|
||
Reporter | ||
Comment 4•6 years ago
|
||
testcase 2 (viewed in other browsers) shows that hyphens are a special case. Edge and Chrome don't break the other long strings in that testcase (with an assortment of other punctuation characters)
Reporter | ||
Comment 5•6 years ago
|
||
(While other browsers treat hyphens as special, we seem to treat percent signs as special in a much weirder way -- I filed bug 1347812 on that.)
Reporter | ||
Comment 6•6 years ago
|
||
masayuki, perhaps you'd be interested in taking this? I see dbaron CC'd you & you added some insight on related bug 1347812. (This bug here is apparently responsible for breaking mobile layout on modemarine.fr, as noted in the webcompat report.)
Flags: needinfo?(masayuki)
Comment 7•6 years ago
|
||
Yep, hyphen-minus is a really difficult character to break around it. If it's used as "hyphen", we can relax around it, however, it can be used as "minus" or special character especially for command lines and similar cases. E.g., there is a line |ac_add_options --enable-debug|, the "--enable" shouldn't be broken because if it's broken to 2 or more lines, it's really difficult to understand what it means. But I guess, "-" not followed by other characters can be broken.
Flags: needinfo?(masayuki)
Comment 8•6 years ago
|
||
Example where Chrome's behavior of treating every hyphen as a break opportunity gives poorer results: data:text/html,<div style="font-family:monospace;width:28ch;">double hyphens may be used -- like this -- to stand in for em-dashes Firefox keeps the hyphens together.
Updated•6 years ago
|
Priority: -- → P3
Comment 9•4 years ago
|
||
also stumbled upon this issue - still does not work as expected in Firefox 68.0.2 (64-bit)
Comment 10•4 years ago
|
||
also stumbled upon this issue - still does not work as expected in Firefox 68.0.2 (64-bit)
a workaround is to use the wbr tag
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr
![]() |
||
Updated•2 years ago
|
Webcompat Priority: --- → ?
![]() |
||
Updated•1 year ago
|
Webcompat Priority: ? → P2
![]() |
||
Comment 11•1 year ago
|
||
This can sometimes make the content unusable because of numbers not visible like in https://github.com/webcompat/web-bugs/issues/99714
Updated•8 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•