This change is forced by Firefox 12: https://bugzilla.mozilla.org/show_bug.cgi?id=725485 Which has been updated: http://hg.mozilla.org/mozilla-central/rev/93b804e5f3f5 To follow the W3C css-multicol specification for column-fill: http://www.w3.org/TR/css3-multicol/#column-fill I'm sure there's a good reason why the default value for column-fill is 'balance', not 'auto', but it eludes me. Anyway, Monocle was broken in Firefox alpha releases -- this fixes it.
References #56 - "improve the touch/pointer coordinates calculations".
Huge thanks to @aronwoost for tracking down the cause of the problem, which was that apparently the order in which the CSS is applied is important. If an element has break-word, but the container doesn't have a width (and an absolute position), it does not apply. It still doesn't apply if the container later gets a width/position. The fix was to apply all the CSS at the same time.
If it is, register the callback as usual to fire when transition completes. If it isn't, simply defer the callback. This fixes a pernicious little bug where slowly cancelling a page turn in the Slider would "lock" the page -- you couldn't turn it again without a jump.
Firefox (recently?) does not pick up changes to href in the click event.
This fixes the problem of Firefox issuing requests for 'undefined', so we can close #75. There is a question about whether this is the right approach -- it's faster, but if tests modify the dom/styles of the test frame, things get unpredictable...
This is handy in a number of places, including search functionality.
Firstly, a bit more resilience against these views having weird UA strings. This has been tested in the Facebook iOS apps, where Monocle was breaking because it wasn't recognised as a WebKit browser. Secondly, UIWebKit apparently doesn't recognised the "about:blank" URL, so it was choking during the priming of frames. The little workaround is to direct UIWebKit frames to "blank.html" instead, which should just non-fatally 404 if there's nothing there. You could always put something there in this case. Refs #51.
I've always hated it. Now should only appear if the next page is actually taking a while to set (because it has a slight transition on the opacity, so near-zero setPage times shouldn't ever let the opacity reach 1). Need to test this on slower devices.
There's no point stacking the various style changes successively -- all of them will be applied on the next defer. So, just ensure there is a single defer before announcing the page change. Also, we can make the slide faster if there's been another slide very recently -- the user is obviously paging through the book quickly; let's not get in their way.