- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Sat, 26 Jul 2014 09:38:40 -0700
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: Sylvain Galineau <galineau@adobe.com>, "<www-style@w3.org>" <www-style@w3.org>
On Jul 24, 2014, at 4:58 AM, Håkon Wium Lie <howcome@opera.com> wrote: >> Does it mean: >> >> A) Fragment the content one container (viewport?) width at a time; but scroll one half container >> forward/backward. >> >> ....or does it mean: >> >> B) overflow content shall go to the right (or left); prev/next page gestures move half a container worth >> >> I'm assuming B but I can't tell from the current early stages of those drafts. > > Is the difference between A and B that A fragments while B overflows? The biggest difference in my mind is that with A you are swiping horizontally to see horizontal overflow (note the word "width", and with B you are swiping horizontally to see vertical overflow. At least that's how I read it. With B, it is not clear what happens to horizontal overflow. This reminds me of the Feedly app on the iPhone. Horizontal swipes will expose horizontal overflow, if present (such as from a long headline with no spaces or hyphens), with an additional horizontal swipe necessary to get to the next page (the next article), once the right edge of the page is visible. Vertically, the article can be scrolled to get to the end. I think this would be expressed in CSS as an auto-width, auto-height container, with forced breaks at the end of each article, and 'overflow:paged-x'. But I don't know how you would get something similar if you wanted fixed height pages on the desktop that scrolled normally within each article, with vertical scrollbars as needed when the article was taller than the fixed height page. Is that possible? How would you do that otherwise, where each page was exactly one article? Would that only work with 'article { height: auto; }?
Received on Saturday, 26 July 2014 16:39:11 UTC