Bug 41103 – Consider matching either Firefox or IE better in the characters that allow a linewrap

• Status: NEW
• Component: Layout and Rendering

[Tab Atkins]

Firefox 3.6 (and possibly earlier) treats the forward slash "/" as creating a linebreak opportunity for the linewrap algorithm.  IE8 (and possibly earlier) treats the open square bracket "[" as creating a linebreak opportunity for the linewrap algorithm.  Webkit does neither.  This causes the PCWorld page at http://www.pcworld.com/article/168658/seven_reasons_microsofts_profits_are_tanking.html to break, as a comment at the bottom of the page contains a very long line with no spaces, but several forward slashes and square brackets.

We should match either Firefox or IE here, or perhaps both, in their linebreak-opportunity seeking.

Minimal test case:
data:text/html,%3C!DOCTYPE%20html%3E%3Cdiv%20style%3D%22width%3A%20800px%3B%20margin%3A%200%20auto%3B%22%3E%3Cdiv%20style%3D%22float%3A%20left%3B%20width%3A%20600px%3B%22%3Efoooooooooooooooooooooo%2Fooooooooooooooooooooooooooooo%2Foooooooooooooooooooooooooooo%2Fooooooooooooooooooooooooooo%2Fooooooooooooooooooooooo%3C%2Fdiv%3E%3Cdiv%20style%3D%22float%3A%20right%3B%20width%3A%20200px%3B%20height%3A%20600px%3B%20background%3A%20gray%3B%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3E

Expected Result: The long line breaks before the second and fourth forward slashes, and doesn't stretch the left float.  (This works as expected in Firefox.  Replace the / with [ for it to work as expected in IE.)
Actual Result: The long line doesn't break at all, stretching the left float underneath the right float and off the side of the monitor for most people.

[Aryeh Gregor]

This is covered by Unicode TR14:

http://unicode.org/reports/tr14/

I don't think any browser fully implements that (why not?).  It appears to say that breaks are prohibited before class SY, which contains U+002F SOLIDUS (LB13), and prohibited after SY if it's followed by a digit (LB25), but otherwise permitted (LB31).  Breaks between alphanumerics (AL and NU) and opening punctuation like [ (OP) are prohibited by LB30, contradicting IE's behavior.

It would be cool if the full algorithm were implemented.  It contains a lot of useful advice, like "don't break before '!', even after a space" (common in French).  It doesn't seem complicated at all to implement -- does it have major problems?

[Eric Seidel (no email)]

bug 25638 may also be related.

[Eric Seidel (no email)]

Simple reduction:
<div style="width: 10px">
a/a/a/a/a/a/a/a/a/a/a/a/a/a/a
</div>

[Eric Seidel (no email)]

Several dups in Chromium:
http://code.google.com/p/chromium/issues/detail?id=57052

Hi. Another report here: https://issues.chromium.org/issues/40073909. Just to note this affects us: https://github.com/guardian/dotcom-rendering/pull/14331, so backing Aryeh Gregor’s comment.

[Ahmad Saleem]

(In reply to mateusz.karpow from comment #5)
> Hi. Another report here: https://issues.chromium.org/issues/40073909. Just
> to note this affects us:
> https://github.com/guardian/dotcom-rendering/pull/14331, so backing Aryeh
> Gregor’s comment.

Has `guardian.com` workaround the issue on live website? Since 'https://www.theguardian.com/music/classical-music-and-opera#live-reviews' seems to look same on Chrome and Safari to me.

(In reply to Ahmad Saleem from comment #6)
> Has `guardian.com` workaround the issue on live website? Since
> 'https://www.theguardian.com/music/classical-music-and-opera#live-reviews'
> seems to look same on Chrome and Safari to me.

No workaround yet, linked PR may become one. Chrome and Safari both look incorrect (closest Chromium bug I could found is linked above). Only Firefox seems to be respecting SY: Symbols Allowing Break After rule.

[Radar WebKit Bug Importer]

<rdar://problem/158904757>