Open JayPanoz opened 6 years ago
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.
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.
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.
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:
scrolled-doc
:
margin-top|bottom
) for the doc itself so that it doesn’t feel cramped;scrolled-continuous
:
scrolled-doc
);scrolled-doc
for vertical-writing.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.
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.
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 arescrolled-continuous
andscrolled-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?