Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Very long strings break columns on iOS (4+5) #70

aronwoost opened this Issue Nov 1, 2011 · 7 comments


None yet
2 participants

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.


joseph commented Nov 4, 2011

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.

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).

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 Jan 5, 2012

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 Jan 5, 2012

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.

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 joseph closed this in 6a1276f Jan 20, 2012


joseph commented Jan 20, 2012

Thanks heaps for digging into this. I've just pushed your fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment