Open Bug 1347808 Opened 7 years ago Updated 1 year ago

A long string of hyphens does not wrap in Firefox, but does in other browsers


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




Webcompat Priority P2
Tracking Status
firefox55 --- affected
firefox97 --- affected
firefox98 --- affected
firefox99 --- affected


(Reporter: dholbert, Unassigned)




(2 files)

Attached file testcase 1
(Filing this for )

 1. Load attached testcase.

Hyphens wrap to multiple lines, staying inside of their <div> container.

Hyphens do not wrap, and overflow their <div> container.
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.
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 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.)
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)
See Also: → 1347812
(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.)
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, as noted in the webcompat report.)
Flags: needinfo?(masayuki)
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)
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.
Priority: -- → P3

also stumbled upon this issue - still does not work as expected in Firefox 68.0.2 (64-bit)

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

Webcompat Priority: --- → ?
Webcompat Priority: ? → P2

This can sometimes make the content unusable because of numbers not visible like in

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.