Closed
Bug 959735
Opened 10 years ago
Closed 10 years ago
Wired.com is not word wrapping properly for Firefox Android
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: adamopenweb, Assigned: adamopenweb)
References
()
Details
(Whiteboard: [mobile-compat-form][country-all][sitewait])
Attachments
(4 files, 4 obsolete files)
Site: http://www.wired.com/design/2014/01/super-detailed-photos-of-snowflakes-shot-with-hacked-camera/ Wired.com is not word wrapping properly for Firefox Android :: Steps To Reproduce 1. Open Firefox Android browser 2. Go to Wired.com and pick an article (example: http://www.wired.com/design/2014/01/super-detailed-photos-of-snowflakes-shot-with-hacked-camera/) :: Expected Result Words to be wrapped properly at the end of a line, keeping the word intact :: Actual Result Words being split into two, part of the word wrapping :: Additional Information Software Version: 26.0.1 Device Information: User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 4 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.59 Mobile Safari/537.36 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Reporter's User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0
Assignee | ||
Comment 1•10 years ago
|
||
Spoofing the UA on desktop will reproduce the issue.
Comment 2•10 years ago
|
||
Here's the relevant CSS, from http://cdn.mobify.com/sites/wired/production/stylesheet.css?1386878557514 (perhaps elsewhere for other parts of the page). .x-article #x-test #article-wrap .entry p,.x-article #x-test #article-wrap .entry li{ -ms-word-break:break-all; word-break:break-all; word-break:break-word; -webkit-hyphens:auto; -moz-hyphens:auto; hyphens:auto; ... } The reason that Chrome/WebKit doesn't break all the words in the same way that we do is because of the (formerly non-standard? aliased?*) word-break: break-word. Removing that results in the same experience that we get. I suppose when we implement 955857 word-break: break-word should just work™. Now, as to why -moz-hyphens isn't working is not clear to me. MDN says "Automatic hyphenation only works for languages whose hyphenation dictionaries are integrated in Gecko." But I'm using "en-US". * spec says "For legacy reasons, UAs must treat ‘word-wrap’ as an alternate name for the ‘overflow-wrap’ property, as if it were a shorthand of ‘overflow-wrap’."
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•10 years ago
|
||
Testcase for -moz-hypens not working as (I) expected.
Comment 4•10 years ago
|
||
Attaching screenshot of testcase working in Safari.
Comment 5•10 years ago
|
||
David, would you mind looking at the attached hyphens.html testcase to confirm that I'm not missing something (or making incorrect assumptions about -moz-hyphen)?
Comment 6•10 years ago
|
||
(Apparently it's very hard for me to type "hyphen" correctly - though not in the testcase CSS)
http://dev.w3.org/csswg/css-text/#word-break-property defines 'break-all' as: In addition to ‘normal’ soft wrap opportunities, lines may break between any two letters (except where forbidden by the ‘line-break’ property). Hyphenation is not applied. This option is used mostly in a context where the text is predominantly using CJK characters with few non-CJK excerpts and it is desired that the text be better distributed on each line. So given that the test includes 'word-break: break-all', our behavior of breaking anywhere and not hyphenating seems correct.
Flags: needinfo?(dbaron)
(I'm not sure where the discussion of word-wrap and overflow-wrap came from; word-break and word-wrap are different properties.)
Comment 9•10 years ago
|
||
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #8) > (I'm not sure where the discussion of word-wrap and overflow-wrap came from; > word-break and word-wrap are different properties.) In the rule, word-break:break-all; word-break:break-word; word-wrap: word-break is what is applied to Chrome on wired.com, hence it doesn't appear to the user that anything is broken on the page -- even with them not supporting hyphens. (iOS supports both word-break:break-word and -webkit-hyphens, which is likely what this site was tested in/designed for.) (In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #7) > http://dev.w3.org/csswg/css-text/#word-break-property defines 'break-all' as: > > In addition to ‘normal’ soft wrap opportunities, lines may break between > any two letters (except where forbidden by the ‘line-break’ property). > Hyphenation is not applied. This option is used mostly in a context where > the text is predominantly using CJK characters with few non-CJK excerpts and > it is desired that the text be better distributed on each line. > > So given that the test includes 'word-break: break-all', our behavior of > breaking anywhere and not hyphenating seems correct. The "correct" behavior here is not useful for our users reading non-CJK wired.com though :(. Here's a screenshot that shows the difference between Firefox for Android and Chrome: https://cloudup.com/c2dYBfAqmhB It's not very easy to read in our browser. That said, if there's nothing that can be done from a core perspective, perhaps we can just recommend ditching the word-break and going with something like "text-align: justify".
Comment 10•10 years ago
|
||
Of course by "word-wrap: word-break" I mean "word-break: break-word", which is apparently a non-standard thing that WebKit supports. I think I've confused myself at this point, so it probably is irrelevant to overflow-wrap.
So what does word-break: break-word do, and why is the site using it? Maybe the site should just omit the word-break property entirely? Or is it something that ought to be spec'd and supported?
Flags: needinfo?(dbaron)
Comment 12•10 years ago
|
||
Comment on attachment 8360521 [details]
hypens.html
Was missing -ms-hyphens: auto;
Attachment #8360521 -
Attachment is obsolete: true
Comment 13•10 years ago
|
||
Comment 14•10 years ago
|
||
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #11) > So what does word-break: break-word do, and why is the site using it? Maybe > the site should just omit the word-break property entirely? Or is it > something that ought to be spec'd and supported? It appears that in WebKit/Blink, word-break: break-word is a synonym for word-wrap: break-word (according to my tests and [1]. [2] suggests that they did this for IE compat? [1] https://github.com/WebKit/webkit/blob/e7207313fed4b7a2140c39f65d45e0f441731735/LayoutTests/fast/text/word-break.html#L17-L29. [2] https://github.com/WebKit/webkit/blob/e887e1aa1b7be17a8d160e869790c320b08f7ae0/Source/WebCore/rendering/style/RenderStyleConstants.h#L219-L223 I wonder if this should be noted in the CSS3 Text spec. Unsure how widely it's used right now. As for this issue, word-break: break-all is really intended for predominantly CJK scripts (from what I gather), and word-wrap: break-word for non-CJK scripts. Even though Chrome doesn't support CSS hyphens, it understands word-break: break-word and treats it like word-wrap: break-word. Safari does the same, but it supports hyphens so it looks a little nicer. They already have a rule on body that declares word-wrap: break-word, so if they remove the "-ms-word-break:break-all;word-break:break-all;word-break:break-word;" from the selector mentioned in Comment 2, this should work nicely in all browsers.
Whiteboard: [mobile-compat-form] → [mobile-compat-form][country-all][contactready]
Comment 15•10 years ago
|
||
Updated test case showing break-word: word-break behaves the same in WebKit/Blink as word-wrap: break-word.
Attachment #8361881 -
Attachment is obsolete: true
Comment 16•10 years ago
|
||
Attaching IE11 screenshot which suggests that IE treats word-break: break-word the same as word-wrap: break-word.
Comment 17•10 years ago
|
||
Attachment #8361943 -
Attachment is obsolete: true
Comment 18•10 years ago
|
||
I realize I had written my test incorrectly. This screenshot shows that IE11 (in IE7 document mode) treats word-break: break-word as a synonym to word-wrap: break-word, but the IE8 and above document modes ignore it/don't understand it.
Attachment #8361945 -
Attachment is obsolete: true
Assignee | ||
Comment 19•10 years ago
|
||
Trying to contact using the site fix form: http://www.wired.com/about/sitefix/
Assignee: nobody → astevenson
Status: NEW → ASSIGNED
Whiteboard: [mobile-compat-form][country-all][contactready] → [mobile-compat-form][country-all][sitewait]
Assignee | ||
Comment 20•10 years ago
|
||
This seems to be working for me now. :) Mike - can you confirm please?
Flags: needinfo?(miket)
Comment 21•10 years ago
|
||
Yay! Fixed over here too.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 22•9 years ago
|
||
(In reply to Mike Taylor [:miketaylr] from comment #14) > (In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #11) > > So what does word-break: break-word do, and why is the site using it? Maybe > > the site should just omit the word-break property entirely? Or is it > > something that ought to be spec'd and supported? > > It appears that in WebKit/Blink, word-break: break-word is a synonym for > word-wrap: break-word Just to set the record straight on this -- this isn't quite true. In particular, it looks like "word-break: break-word" influences how intrinsic widths are created -- it influences the minimum width and preferred width -- whereas "word-wrap: break-word" *does not* influence these things. Attached testcase demonstrates this difference, when loaded in Chrome. It's got auto-sized floats, in a 100px-wide div. The first one, with "word-wrap", overflows the parent, but the second does not (I think because it's reporting a smaller min-content width -- possibly the width of the widest character, or something).
Comment 23•9 years ago
|
||
Thanks for the re-education Daniel. :)
Updated•5 years ago
|
Product: Tech Evangelism → Web Compatibility
Updated•1 month ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•