Media Queries
JayPanoz opened this issue · 2 comments
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.
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 (< 35em), all the remaining content of the xhtml file will be styled using the width of the spread (35–65em), except the last one if it happens to be displayed on the left column/page.
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 < 35em (first page) while all the following pages are styled using 35–65em.
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 em value is styling that adapts to both the device and the user setting for font-size e.g. if the user increases font-size up to a critical point, then the type scale is changed.
As you can see in the picture above (two screenshots of iBooks in portrait orientation), when you increase font-size, the width changes accordingly.
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: text-align: left is only declared for body so that all other elements can inherit from it, but when publisher’s styles are enabled, everything gets text-align: center for an unknown reason.
Adobe Digital Editions for iOS
Well, the answer seems to be no, they can’t because the width is not necessarily updated after font-size is changed. For the record, ADE desktop does update in this case.
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 (font-size, margins, etc.) which impact in significant ways the actual width of content.
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:
The ‘width’ media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21]) including the size of a rendered scroll bar (if any). For paged media, this is the width of the page box (as described by CSS2, section 13.2 [CSS21]).
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:
Reading System-induced pagination can interact poorly with style sheets. Pagination is sometimes done using columns, which can result in incorrect values for viewport sizes. Fixed and absolute positioning are likely to be problematic.
Dave