- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Oct 2022 09:12:49 +0000
- To: public-css-archive@w3.org
A late remark but I’m seeing some potential confusion between the term “Interactive UI widgets” _(used here)_ and “UA interfaces that are dynamically expanded and retracted” _(used in the definition for [the various Viewports and their associated lengths](https://drafts.csswg.org/css-values-4/#viewport-relative-lengths))_. After all, a Virtual Keyboard is also “an interface that is dynamically expanded and retracted” _(albeit from the OS – not the UA)_. Taking a step back: we approached this from the virtual keyboard and therefore first named the extension `virtual-keyboard` + loaned the value `overlays-content` from the VK API. As it can be more than just the Virtual Keyboard _(can it?)_, it got renamed to `interactive-widgets` and later `interactive-widget` as we continued down that path. Another approach: what if we called it `resize-behavior`? This because it allows you to define the resize behavior of the viewport(s). Values would be `document-viewport`, `visual-viewport`, and `none` _(former `overlays-content`)_. Spec can then later always find a better term for “Interactive UI widgets” should that be confusing to authors _(which I think it will be)_. Using `resize-behavior` would also keep the language consistent: all other allowed options of the viewport meta tag (e.g. `initial-scale`) use the viewport as the subject. With `resize-behavior` this is also the case, whereas with `interactive-widget` it is not. It would also leave the door open for something like `resize-triggers`, should we ever want to allow authors to tweak what exactly can cause a resize. -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/7826#issuecomment-1273015168 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 October 2022 09:12:51 UTC