- From: jonjohnjohnson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Dec 2018 23:09:18 +0000
- To: public-css-archive@w3.org
Furthermore, today, we have a much more complex state of scroll containers interacting with the `transform`/`perspective`/`sticky` features, where we don't need as much javascript to handle interesting scroll interactions writing to the dom on scroll events at runtime, but to truly take advantage of these features, we often need to manipulate scroll containers in unconventional ways that scrollbars currently don't jive with. Take the interface linked below for example. A pure HTML/CSS "swipeview" with effects that allow parallaxing/revealing/covering horizontally between pages. Works well in blink/webkit/gecko, especially in touch env with overlay scrollbars. But the scroll container needs to be outset far from the viewport, then "clipped" back into match it for these effects and then the scrollbar track is far from useful. - http://output.jsbin.com/gedurer/quiet Click the blue header to cycle different "swipeview" styles, and scroll horizontally across the main content to see their behaviors. If you change the `--bottomScrollOffset` on the `.pager` element to `0px` you'll see the horizontal scrollbar track come into view and once scrolling, you'll notice the ludicrous behavior it offers when needing to manipulate the scroll container in this way. If we had a way to inset the scrollbar/track, this example could easily be remedied by a declaration of `scrollbar-inset: 0 var(--pageWidth)`? @upsuper After working on geckos `scrollbar-width/`scrollbar-color` features what would you think about insetting scrollbars from the edge of their scroll containers? Or at least inset in the direction of their scrolling axis? -- GitHub Notification of comment by jonjohnjohnson Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3428#issuecomment-446397918 using your GitHub account
Received on Tuesday, 11 December 2018 23:09:19 UTC