Closed aronwoost closed 12 years ago
joseph
commented
12 years ago Interesting that it does break the word, but it introduces a few extra pixels. Looks like it would be a good candidate for a webkit/radar bug. Is it happening in the latest version of Monocle? I introduced a ~20px column gap with 2.3.
aronwoost
commented
12 years ago Just updated monocle to 2.3. Now we see the gap. And the bug :)
Yes, I was also thinking of a webkit bug. Would be interesting if this also happens in other webkit builds (Android).
aronwoost
commented
12 years ago After hours and hours of diggin I found the problem. Or better: I found a fix.
The problem was, that word-wrap: break-word (set here) wasn't working correctly. In order to make word-wrap work a width needs to be set (at least in <body>). However, when Monocle.Reader.DEFAULT_STYLE_RULES are applied, no width rules are present.
This happens later, here. At least in this case that does not revalidates the text flow in terms of setting/update linebreaks. They remain unchanged, the columns are broke, the hole chapter (component) is messed up.
This fixes it for me. Since we support columns-only and the properties are set later anyway it hurts nobody (god knows why position:absolut also needs to be set).
@joseph You might wonna have a look at it. I can provide you with an "real life" book, where columns are broke because of long string. This - of course - only happens on (very) small resulutions (~320px width).
joseph
commented
12 years ago Thanks Aron, this is great. The absolute worries me a little, as pos on the body has been the cause of numerous obscure problems in the past. But perhaps we can dig a little further. Are you able to isolate it down it a test perhaps? If we popped it in test/bugs, we could be alert to regression.
joseph
commented
12 years ago Er, I'm on the road, and forgot that you provided a test case originally. I'll create a branch for this with the test and the proposed fix when I have a moment.
aronwoost
commented
12 years ago Yeah, but the test case above includes the hole monocle enchilada. I gave up on a more "agnostic" test case when I found the following behavior:
Using a single html file, word-wrap works as expected (view with mobile safari on iPhone, simulator ok): Single html w/o word-wrap Single html with word-wrap
However, when using an iframe (with the html "injection" javascript:) the viewport gets upscaled like hell:
iframe w/o word-wrap
iframe with word-wrap
The longer you make the string, the bigger the upscale is. WTF!? I'm not too deep in the iOS viewport handling. So at this point I decided to leave it with the simple fix... :)
Although I don't think, that this has something to do with the issue here.
joseph
commented
12 years ago Thanks heaps for digging into this. I've just pushed your fix.
Check this out (find the source here)
When you view this on the iPhone you'll see, that the columns are wider then the available vertical space. This sums up the a pretty decent offset the further you go in the component.
I already experimented with strategies to force wrap without success.
Can someone confirm this behavior on other mobile webkits (Android)?
This does not happen on dektop browsers no matter how long the string is.