Hi, Since I supported approach 1, let me respond to your "cons" points about that approach. > On Jun 20, 2018, at 16:55, Hadrien Gardeur <hadrien.gardeur@feedbooks.com> wrote: > > A single HTML version, rendition:layout=reflowable, rendition:flow=scrolled-doc > [...] > Cons > Can be very heavy to load all images in memory In practice, this is indeed true. At the same time, I don't think UAs are strictly required to hold all images in memory all the time. They typically do, but a UA optimized for low footprint could flush them to disk when out of the viewport, and load them on demand when needed. > Since it's reflowable, it's not clear how the viewport will be set (for example, will the images fit in width?) The fact that the viewport is unpredictable is a feature, not a bug: it is the natural consequence of allowing people to read on any device they want. The question is what can an author do in response to viewport size changes, and CSS gives quite a lot of flexibility. It is possible to use: * the width, height, max-width, max-height, min-width, min-height either on the image container, or on the images individually, to control their size * the px, %, vh (viewport height) or vw (viewport width) units when doing so * the object-fit property to decide what to do if the image's size or aspect ratio does not match the size or aspect ratio imposed by the width/heigh/etc properties https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit * media queries to switch layout at different sizes * CSS Grid to provide different non-linear, possibly overlapping, arrangement as desired, for example at large screen sizes. * css scroll snap to force the UA to scroll step-by-step / image-by-image if desired. Here is a very basic demo that uses some of these features: http://files.florian.rivoal.net/dbz/ Please try resizing the window. —Florian
Received on Wednesday, 20 June 2018 08:41:15 UTC