Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 5 commits into from Oct 11, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
80 changes: 80 additions & 0 deletions css-viewport/Overview.bs
Expand Up @@ -125,6 +125,7 @@ The recognized properties in the viewport
<li><code class="index">minimum-scale</code></li>
<li><code class="index">maximum-scale</code></li>
<li><code class="index">user-scalable</code></li>
<li><code class="index">interactive-widgets</code></li>
</ul>

<h3 id="parsing-algorithm">
Expand Down Expand Up @@ -260,6 +261,85 @@ as follows:

Issue: Specify extend-to-zoom behavior by the viewport meta tag

<h3 id="interactive-widgets-section">''interactive-widgets''</h3>

Issue: Move the definition of ''visual viewport'' from CSSOM-View to this spec.

The <dfn><code>interactive-widgets</code></dfn> property specifies the effect that interactive UI
widgets have on the page's viewports. It defines whether widgets overlay a given viewport or whether
the viewport is shrunken so that it remains fully visible while the widget is showing. Interactive
UI widgets are transient user agent or operating system UI through which a user can provide input.

<div class="note">The most common such UI widget is a virtual keyboard.</div>

The following is a list of valid values for [=interactive-widgets=] and the associated
viewport-resizing behavior:

<dl>
<dt><dfn><code>overlays-content</code></dfn></dt>
<dd>
Interactive UI widgets MUST NOT [=resize=] the [=initial viewport=] nor
the the <a spec="CSSOM-VIEW">visual viewport</a>. The user agent must perform the same steps
bokand marked this conversation as resolved.
Show resolved Hide resolved
<!--TODO I can't seem to autolink to overlaysContent, help?-->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tabatkins can you help with this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can i follow!!

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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@bokand bokand Oct 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

<dd>
Interactive UI widgets MUST [=resize=] the [=initial viewport=].
bokand marked this conversation as resolved.
Show resolved Hide resolved
</dd>
<div class="note">
Since the <a spec="CSSOM-VIEW">visual viewport</a>'s size is derived from the
[=initial viewport=], [=resize-layout=] will cause a resize of both the initial and visual
viewports.
</div>
<dt><dfn><code>resize-visual</code></dfn></dt>
<dd>
Interactive UI widgets MUST [=resize=] the <a spec="CSSOM-VIEW">visual viewport</a> but MUST
NOT [=resize=] the <a spec="CSS-VIEWPORT">initial viewport</a>.
</dd>
</dl>

If no value, or an invalid value, is set for [=interactive-widgets=], the behavior implied by
[=resize-visual=] is used as the default.

To <dfn lt="resize">resize a viewport by an interactive widget</dfn>, subtract from it the
intersection of the viewport rect with the widget's OS reported bounding rect. In cases where this
would result in a non-rectangular viewport, the behavior is user agent defined.

<div class="note">
Some examples where the result would non rectangular: a
<a href="https://support.apple.com/en-ca/HT207521">floating or split keyboard</a>, a keyboard that
bokand marked this conversation as resolved.
Show resolved Hide resolved
<a href="https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md#motivation">
occupies only part</a> of the viewport.
</div>

<h4 id="interaction-with-virtualkeyboard-overlayscontent">
Interaction with virtualKeyboard.overlaysContent
</h4>

The virtual-keyboard API provides an imperitive API to apply the [=overlays-content=] behavior via
the <a href="https://www.w3.org/TR/virtual-keyboard/#dom-virtualkeyboard-overlayscontent">
virtualKeyboard.overlaysContent</a> attribute. This attribute shadows the value set to
[=interactive-widgets=], namely:

When <code>virtualKeyboard.overlaysContent</code> is set to <code>true</code>, the UA MUST ignore
emilio marked this conversation as resolved.
Show resolved Hide resolved
any value set to [=interactive-widgets=] when determining the resizing behavior of interactive
widgets.

When <code>virtualKeyboard.overlaysContent</code> is set to <code>false</code>, the UA MUST use the
value set to [=interactive-widgets=], or the default behavior if a value is not set, when
determining the resizing behavior of interactive widgets.

Getting value of <code>virtualKeyboard.overlaysContent</code> MUST return only the value previously
bokand marked this conversation as resolved.
Show resolved Hide resolved
set to it.

<div class="note">
That is, unless previously set, <code>virtualKeyboard.overlaysContent</code> returns false
even if <code>interactive-widgets=overlays-content</code> is set via the <code>&ltmeta&gt</code>
tag.
</div>

<pre class=biblio>
{
"Algorithms": {
Expand Down