OK so this is a complex issue but I guess it is worth reporting as it will help clarify some technical details and issues.

I don't even know if RS devs can deal with that, given their reliance on web rendering engines + the web specs but hey, as far as I'm concerned, it's been limiting the use of media queries, mainly max- and min-width, two simple features which web designers are now using because they understood pretty quickly that targeting devices would become insane in the long term.

So, I checked the specs beforehand and while it's pretty clear it works for the web, there is a nuance which comes with eBooks: pagination. And as a human being, it becomes difficult to cope with that nuance.

A picture is worth a thousand words so I've taken 3 screenshots.

Just the once will not hurt, Adobe Digital Editions 4.5 gets it right.

And then comes iBooks, which if I'm not mistaken, is using CSS3 columns for pagination.

On iPad

Yeah OK, I get it, the spread width is between 35em and 65em. Problem is the “pseudo-page” a.k.a. column isn't and that makes a huge difference.

Enter iBooks on OS X

I'll let you scream for a minute.

I conceive this last one could be a bug that needs to be fixed but, well, we kind of find ourselves in some sort of limbo between web and paged media anyway, especially when columns are being used.

To sum things up, a very basic media query is so inconsistent that it is unreliable. Then, it comes to this insanity: media queries targeting devices, those MQ being obviously undocumented by the RS involved and width being arbitrarily set so that scroll and paged don't share the same one. Or you can just target iBooks and Kindle like, say, in this primer and call the job done—oh look, an iPad Pro breaking the CSS sizes in use until its release.

And oh yes, should you target iPad in landscape to get iBooks right, you'd better remember a lot of other iOS apps don’t necessarily fake a spread (two columns).

I am by no means trying to push for yet another EPUB exception which would clarify what width should be, especially as this 3.1 is trying to get rid of them. For your information, I'm also a strong believer in and vocal supporter of progressive enhancement. Now, I must confess that having to cope with a width that is technically correct but suddenly backfires hurts a little bit.

If possible, could anybody working on Readium explain me how it is dealing with this and what the reasoning behind this choice was? Thanks.