[css-viewport-1] Add 'interactive-widgets' to viewport meta #7826

bokand · 2022-10-04T18:46:39Z

[css-viewport-1] Add 'interactive-widgets' to viewport meta

This describes the proposed interactive-widgets property of the viewport meta tag for describing the expected behavior when a virtual-keyboard-like widget is shown.

bokand · 2022-10-04T18:52:12Z

@emilio here's a first crack, WDYT?

One question on naming: "interactive-widgets" is plural so implies "resize-visual" rather than "resizes-visual" but the virtual keyboard API has overlaysContent which I wanted to keep consistent. Perhaps interactive-widget=resizes-visual would be preferable?

I also had some issues linking to defs in the virtual-keyboard spec, I'll keep looking at that but if you can spot the issue help would be appreciated.

bokand · 2022-10-04T18:54:29Z

Also, unrelated to this specific PR but if no one's signed up for it, I can try and find some time before end of year to specify viewport meta more generally. PLMK

css-viewport/Overview.bs

Co-authored-by: Chris Harrelson <3453258+chrishtr@users.noreply.github.com>

emilio

Let's fix the links before landing.

It seems reasonable. I'm not a fan of the naming but this is much better than virtual-keyboard, and I don't have any better suggestions off the top of my head. One question on the naming of resize-layout tho.

emilio · 2022-10-06T23:10:03Z

css-viewport/Overview.bs

+	<dd>
+		Interactive UI widgets MUST NOT [=resize=] the [=initial viewport=] nor
+		the <a spec="CSSOM-VIEW">visual viewport</a>. The user agent must perform the same steps
+		<!--TODO I can't seem to autolink to overlaysContent, help?-->


@tabatkins can you help with this?

Got some help with this internally - added an anchors block at the top so autolinks to overlaysContent are working now.

Can i follow!!

css-viewport/Overview.bs

emilio · 2022-10-06T23:17:14Z

css-viewport/Overview.bs

+		as when <a href="https://www.w3.org/TR/virtual-keyboard/#dom-virtualkeyboard-overlayscontent">
+		VirtualKeyboard.overlaysContent</a> is set to <code>true</code>.
+	</dd>
+	<dt><dfn><code>resize-layout</code></dfn></dt>


So web-platform-tests/interop-2022-viewport#25 is a discussion about whether the "layout viewport" should be called something else... Maybe we can give it a bit more thought and figure out whether we want to change that? If we do want to change that, it seems using here the layout term would be unfortunate...

Hmm, how about "resize-initial"? Since that's what the spec text refers to and that's what the layout/fixed/whatever viewport is derived from?

resize-initial seems weird to me, as that reminds me of the initial in ICB, whereas this targets the LVP. Just commented on web-platform-tests/interop-2022-viewport#25 and suggested “Document Viewport” to further specify it without introducing a new ambiguous term. Should suggestion make it in, maybe resize-document could be considered?

Well, it does resize the ICB which I think is the most salient part of its behavior (it also happens to resize the fixed viewport).

That said, "Document Viewport" actually sgtm, will reply on that issue.

There was a good counter point to "document viewport" on that issue but I also realized that this really does resize more than just this viewport. In skobe's example page on web-platform-tests/interop-2022-viewport#25, this mode will resize both LV and ICB. This really does resize the "initial viewport", though I agree it's not a great author-facing name.

How about we don't make it "viewport" specific and describe it in less precise but terms more understandable to authors? Some other ideas:

resizes-content works well as a contrast to overlays-content I think

resizes-container

resizes-window

No hard feelings about resizes-content, although technically your content does not get resized. I mean, your content will still have the same size when the OSK gets shown, unless you have them sized to specific viewport units.

Definitely not a fan of resizes-container given we have Container Queries in CSS. This would lead to confusion.

Not a huge fan of resizes-window as it does not actually resize the app’s window, right? I would think an app (on mobile) to still run at the same size as on launch when the OSK gets shown. Is this the case? By the looks of it, this is also the behavior on Windows (at least for Chrome).

Good points about container and window.

I mean, your content will still have the same size when the OSK gets shown, unless you have them sized to specific viewport units.

I'd say it has the potential to resize content since it resizes the initial containing block.

@emilio WDYT?

resizes-content works for me... It might be worth raising this in the next meeting to get wider feedback tho.

bokand · 2022-10-07T00:39:47Z

One question on naming: "interactive-widgets" is plural so implies "resize-visual" rather than "resizes-visual" but the virtual keyboard API has overlaysContent which I wanted to keep consistent. Perhaps interactive-widget=resizes-visual would be preferable?

@emilio Thoughts on this? Or do you think it's ok as-is?

emilio · 2022-10-07T08:55:43Z

One question on naming: "interactive-widgets" is plural so implies "resize-visual" rather than "resizes-visual" but the virtual keyboard API has overlaysContent which I wanted to keep consistent. Perhaps interactive-widget=resizes-visual would be preferable?

@emilio Thoughts on this? Or do you think it's ok as-is?

I don't feel strongly either way. If you think resizes- is more consistent that works for me.

bramus · 2022-10-10T09:12:47Z

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). 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.

bokand · 2022-10-10T21:09:56Z

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.

This is intended to apply only to virtual-keyboard and virtual-keyboard-like UI - I'm not sure if any exists today but something that's similar to today's keyboards but not necessarily exactly a keyboard (e.g. voice interpreter, handwriting panel, etc. that behave equivalently to the "regular" virtual keyboard).

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)

My main push back is that this property isn't a general resizing mechanism, it applies only to virtual-keyboards. i.e. none of URL bar, bottom bars, split screen, etc. will respect this property so I think resize-behavior will be somewhat misleading.

This addition is mainly intended to pave a path to an interoperable behavior for virtual-keyboards. I think if we want to design a more complete and general API later we can (and should!) still do that.

bokand · 2022-10-11T15:21:29Z

Thanks all, I think that's everything resolved.

This CL updates the names of some properties in the `interactive-widgets` property of the viewport meta tag to reflect updated spec text[1]: "interactive-widgets" --> "interactive-widget" "resize-layout" --> "resizes-content" "resize-visual" --> "resizes-visual" [1] w3c/csswg-drafts#7826 Bug: 1353728 Change-Id: I6a07dd9d8e2c018a107ab045a3c181946129b033 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3940786 Reviewed-by: Ken Buchanan <kenrb@chromium.org> Commit-Queue: David Bokan <bokan@chromium.org> Reviewed-by: Ted Choc <tedchoc@chromium.org> Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#1057574}

This commit updates the names of some properties in the `interactive-widgets` property of the viewport meta tag to reflect updated spec text[1]: "interactive-widgets" --> "interactive-widget" "resize-layout" --> "resizes-content" "resize-visual" --> "resizes-visual" [1] w3c/csswg-drafts#7826

This CL adds a pref and accompanying enterprise policy which sets the default virtual keyboard resize behavior to "resize-layout". If the preference is set, the OSKResizesVisualViewportByDefault flag has no effect on the default resize behavior. Note however that it's only the *default* resize behavior that's affected by the pref. If the author specifies a non-default behavior with the Virtual Keyboard API or a <meta> tag, that behavior will apply. Further, the pref has no effect on whether or not the <meta>/interactive-widget functionality [1] is exposed. [1] w3c/csswg-drafts#7826 Bug: 1353728 Change-Id: I2b9fd26d080e75c2d94a1b7021f43a3722fc7cae Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3934281 Reviewed-by: Pavol Marko <pmarko@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Reviewed-by: Ted Choc <tedchoc@chromium.org> Cr-Commit-Position: refs/heads/main@{#1058060}

[css-viewport] Add viewport meta 'interactive-widgets'

1704113

bokand requested a review from emilio October 4, 2022 18:46

bokand mentioned this pull request Oct 4, 2022

Add viewport meta 'interactive-widgets' whatwg/compat#212

Closed

3 tasks

bramus mentioned this pull request Oct 5, 2022

ICB/LVP vs Virtual Keyboard, and the effect on Viewport Units web-platform-tests/interop-2022-viewport#11

Closed

chrishtr reviewed Oct 6, 2022

View reviewed changes

css-viewport/Overview.bs Outdated Show resolved Hide resolved

css-viewport/Overview.bs Outdated Show resolved Hide resolved

css-viewport/Overview.bs Outdated Show resolved Hide resolved

css-viewport/Overview.bs Outdated Show resolved Hide resolved

Apply suggestions from chrishtr review

a938038

Co-authored-by: Chris Harrelson <3453258+chrishtr@users.noreply.github.com>

emilio approved these changes Oct 6, 2022

View reviewed changes

bokand added 2 commits October 7, 2022 14:46

Rename resize-layout to resizes-document

1ded60c

Fix virtual-keyboard linking

69d97bf

'resizes-document' -> 'resizes-content'

70626a6

bokand merged commit c0dd898 into w3c:main Oct 11, 2022

theres-waldo mentioned this pull request Mar 19, 2024

[css-viewport] Add a meta viewport parameter to control ICB layout behavior for interactive overlays #7767

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-viewport-1] Add 'interactive-widgets' to viewport meta #7826

[css-viewport-1] Add 'interactive-widgets' to viewport meta #7826

bokand commented Oct 4, 2022

bokand commented Oct 4, 2022

bokand commented Oct 4, 2022

emilio left a comment

emilio Oct 6, 2022

bokand Oct 7, 2022

nongaum2112 Oct 25, 2022

emilio Oct 6, 2022

bokand Oct 7, 2022 •

edited

Loading

bramus Oct 7, 2022

bokand Oct 7, 2022

bokand Oct 7, 2022

bramus Oct 8, 2022

bokand Oct 9, 2022

emilio Oct 10, 2022

bokand commented Oct 7, 2022

emilio commented Oct 7, 2022

bramus commented Oct 10, 2022

bokand commented Oct 10, 2022

bokand commented Oct 11, 2022

[css-viewport-1] Add 'interactive-widgets' to viewport meta #7826

[css-viewport-1] Add 'interactive-widgets' to viewport meta #7826

Conversation

bokand commented Oct 4, 2022

bokand commented Oct 4, 2022

bokand commented Oct 4, 2022

emilio left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bokand Oct 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bokand commented Oct 7, 2022

emilio commented Oct 7, 2022

bramus commented Oct 10, 2022

bokand commented Oct 10, 2022

bokand commented Oct 11, 2022

bokand Oct 7, 2022 •

edited

Loading