Scroll and rendition: flow #11
Description
I know scroll mode is still super rough around the edges in the app and work on scroll is planned for October but I’d like to point out this issue in advance (so that I don’t forget about it).
The rendition: flow values dedicated to scroll are scrolled-continuous and scrolled-doc. And it will obviously impact both @camill-a and I (again it’s not urgent at all, just recording my thoughts).
My understanding is that we currently have something like scrolled-doc: swipe left/right to navigate between documents and scroll to read them. Reminds me of the first digital magazines on tablets a little bit (and I know a lot of users were kinda confused with this navigation pattern, which is why this pattern dropped in popularity/usage over time).
It looks like Readium 1 and iBooks’ scroll modes, for instance, are more like scrolled-continuous but I may be wrong there – especially as the expected behavior is not very clear, cf. note in the spec. Well, I guess that at least it can be defined as web views on top/bottom of one another (except for vertical writing).
I don’t know if you want to support both but if this is the case, I can already tell we’ll have to create a flag for each one so that we can make adjustments in Readium CSS: if continuous, we’d better add top/bottom margins so that the reader knows it’s a new html file for instance, and we may also have to sanitize viewport height values depending on the implementation.
Since work on the test app and Readium CSS overlap there, I assume we’d better deal with this issue in the R2-testapp first then put the recommendations in the readium-css repo. Does this feel OK to you?
Activity
llemeurfr commentedon Sep 21, 2017
I have seen some new implementations of
scrolled-docmodes recently, especially in La Matinale du Monde where articles are scrolled in a natural way and moving from one articles to the other is done via swipe left/right. With proper indications (arrows) in the footer, it could be adopted by users IMO.But Adobe Acrobat users will instead prefer a continuous scroll.
Therefore I would be in favor of supporting both in the R2 testapp and therefore (later?) in Readium CSS if both are indeed useful.
JayPanoz commentedon Sep 21, 2017
Oh yeah sure, if you’re used to it (because you use other apps with such navigation), then I guess
scroll-docmay feel more natural.HadrienGardeur commentedon Sep 21, 2017
The navigator/viewer for AMP is also a mix of scroll and swipe.
IMO
scroll-docwill be the only good option for WP, but EPUB might be more natural withscroll-continuous. It all depends how consistent we'd like to make the experience across publication formats.JayPanoz commentedon Sep 21, 2017
Sorry I somehow missed this part. At first sight it doesn’t imply huge changes but very few adjustments at the Readium CSS level. The heavier work will probably be at the app level, depending on how
scrolled-continuouswill be implemented.AFAICT, CSS adjustments are:
scrolled-doc:margin-top|bottom) for the doc itself so that it doesn’t feel cramped;scrolled-continuous:scrolled-doc);scrolled-docfor vertical-writing.min|max-heightstyles so that authors are not impacted with implementations’ side effects (but I can’t tell for sure at the moment, maybe we won’t even have to).On a related note, there are some issues with vertical-writing but they out-scope the R2 test app (some are related to other rendering engines) so I’ll create one in Readium CSS to anticipate that.
JayPanoz commentedon Dec 2, 2017
Vertical writing complication: how must we manage
scrolled-docwhen vertical-writing is set (basically, as if the tryptic view was rotated 90 deg)?It would indeed feel weird to swipe up/down to navigate the publication’s documents – and I guess this is not what would be expected. In other words, it would behave as
scrolled-continuousanyway.