Scroll and rendition: flow

[JayPanoz]

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?

[llemeurfr]

I have seen some new implementations of scrolled-doc modes 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]

Oh yeah sure, if you’re used to it (because you use other apps with such navigation), then I guess scroll-doc may feel more natural.

[HadrienGardeur]

The navigator/viewer for AMP is also a mix of scroll and swipe.

IMO scroll-doc will be the only good option for WP, but EPUB might be more natural with scroll-continuous. It all depends how consistent we'd like to make the experience across publication formats.

[JayPanoz]

and therefore (later?) in Readium CSS

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-continuous will be implemented.

AFAICT, CSS adjustments are:

1. scrolled-doc:
   • maybe a little bit of vertical whitespace (margin-top|bottom) for the doc itself so that it doesn’t feel cramped;
   • constraining the height for vertical-writing (scroll on the x-axis there) + horizontal margins so that contents are not displayed edge to edge, etc.
2. scrolled-continuous:
   • vertical whitespace to make it clear to the user when he/she reaches a new document (different values than scrolled-doc);
   • same as scrolled-doc for vertical-writing.
3. both: possible safeguards for min|max-height styles 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]

Vertical writing complication: how must we manage scrolled-doc when 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-continuous anyway.