- From: Johannes Odland via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Apr 2021 05:58:37 +0000
- To: public-css-archive@w3.org
Adding another use case: scroll-snapping articles Scroll-snapping articles like [NYTimes The Weekender](https://www.nytimes.com/interactive/2021/02/19/briefing/the-weekender.html) and [this article](https://www.nrk.no/hvis-insektene-forsvinner-1.15029017) need both vh and vhc. They would also benefit from a dynamic property as the suggested [lvh](https://github.com/w3c/csswg-drafts/issues/6113). The snapping elements should be able to cover the entire viewport when UA chrome is hidden. Backgrounds can then cover the entire viewport. This can already be done with `height: 100vh`. Content (text++) should never be covered up by UA chrome, and should never be taller than the viewport/icb with UA chrome visible. This would be solved with `height: 100vhc`. Some elements would benefit from having a dynamic value that is updated when UA chrome is shown and hidden. A vertical progress indicator could be updated to fit in the viewport. Text could be translated/shifted to be relative to the bottom of the viewport. These pages are currently using a scroll-container and not the viewport both because of inconsistencies in propagating scroll-snapping values from root to the viewport, but also because reasoning about viewport sizes is error prone and need JS. WebViews are particularly error prone and hard to debug. It's important that applications that use WebViews can configure and update these values somehow. -- GitHub Notification of comment by johannesodland Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-816430393 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 9 April 2021 05:58:39 UTC