Re: [csswg-drafts] [css-position-3] Reinterpret viewport positioned (fixed, sticky) elements wrt virtual keyboard (#7475)

Forgive me for jumping in with a comment without having read the full thread above, but @bramus asked me to add a use-case I have for honouring both the visual viewport and layout viewport on a single page.

I’ve pinned a cookie/marketing consent banner to the bottom of the viewport, it’s a non-modal dialog (could probably replace with popover now) that allows the user to interact with the rest of the page without being forced to interact with it (because I’m nice like that).

Then I have other elements that I need to keep above the soft keyboard, for example a ‘view all results’ button for a typeahead search – I want this pinned to the bottom of the visual viewport at all times, whereas the cookie banner can be hidden behind the keyboard as it would get in the way of typeahead (and thus defeat my objective to keep it unobtrusive).

This currently seems impossible with Chrome’s meta tag implementation as you can only choose one behaviour at a document-level. My suggestion on Mastodon was that we could do this if there were a ‘vvh’ CSS unit (‘visual viewport height’), then it would be up to the CSS author to decide where to apply this unit to make adjustments, rather than something layout-based living outside in HTML (meta) or JS events.

I’m currently relying on the visual viewport resize event which is less than ideal for a whole bunch of reasons I’m sure everyone here is aware of.

-- 
GitHub Notification of comment by ryantownsend
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7475#issuecomment-2091089243 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 May 2024 17:09:05 UTC