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
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.
Yeah OK, I get it, the spread width is between
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
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
If possible, could anybody working on Readium explain me how it is dealing with this and what the reasoning behind this choice was? Thanks.
The text was updated successfully, but these errors were encountered:
For the sake of completeness, I will take the liberty to update my original comment. Indeed, I’ve tested those media features in other iOS apps and can now report new issues.
But first and foremost, some further details about iBooks iOS, which makes it even more unreliable.
In this screenshot, as you can see, iBooks report a different width than the second one in the previous comment. It doesn’t mean I’ve solved my problem, it actually means iBooks reports different widths for xhtml files which are less than one column/page or, even worse, start on the right column/page.
For the latter, only the first column/page of the xhtml gets this width (
In case it’s unclear, this picture is made of 4 consecutive pages and illustrates the problem.
This can lead to epic failures, like content not displayed/missing at the end of the xhtml file because the pagination algorithm has to deal with contradictory data: it computes using
My understanding is that it’s kind of spec-compliant though, given CSS columns are used to paginate contents. In other words, it might apply to other apps using CSS columns and following MQ specs to the letter; we might have found an edge case which just happens to be part of our “standard”.
Now, the reason behind the
As you can see in the picture above (two screenshots of iBooks in portrait orientation), when you increase
So, at least iBooks can deal with that in portrait orientation. But, can all other apps?
Kobo for iOS
Please note the centered content is a bug:
Adobe Digital Editions for iOS
Well, the answer seems to be no, they can’t because the width is not necessarily updated after
To sum things up, those two simple features are even more unreliable than I previously thought. And that’s an issue considering users are very likely to change settings (
As far as I’m concerned, Media Queries are broken.
And as noted by @rdeltour, this could have a significant impact on the minimal default stylesheet + “css overrides” meta.
The spec says:
So we mostly seem to be looking at reading system bugs here. But it may be worth adding to the note in the css section of the spec, perhaps changing to: