Virtual Keyboard Control Breakout - TPAC 2020

30 Oct 2020


smaug, grisha, BoCupp, tidoust, whsieh, slightlyoff, mustaq, drousso, garykac, xiaoqian
Bo Cupp


VirtualKeyboard explainer - https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardPolicy/explainer.md

<BoCupp> Slides: https://cuppfamily-my.sharepoint.com/:p:/g/personal/bo_seattlecupps_com/EVoI7Hp5An1HokezOTE3hK0BLMT2UsL1k7-ryO8-8efv6w?e=EplB9S

Zoom meeting info - https://us02web.zoom.us/j/86562820512?pwd=NmlDSnBGbEE3bUtUYis4Q3ZMM00yQT09

VirtualKeyboardAPI explainer - https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md

<BoCupp> the meeting will start at 7:05AM PST

BoCupp: starts the presentation
... objective: to close on outstanding issues, looking for collaborators in spec development.

First, we'll do presentation, demo then issues discussion.

whsieh: few comments: overlayscontent: if the keyboard comes up, there is only so much space on the screen. There will only be few lines of content which may cause the sites pages to be squished.

BoCupp: just to clarify, what we mean by overlaycontent is to prevent for content to be adjusted.
... to second point: there is always concerns that the API will miss use. But I do think we need to give devs control that want to put effort into building best experiences.

whsieh: opt-in req helps. As long as it stays opt-in that should work.

<slightlyoff> smaug: do you have examples of those other overlay types?

smaug: few comments about the API. Seems they are two distinct APIs, one about geometry and another about control. Perhaps, should have a generic view port api or something like that and then some keyboard specific. Might want to keep them separate to avoid building a precedence.

<smaug> slightlyoff: this is about being somewhat futureproof

BoCupp: I would disagree. since this is about for developers to react to the change. I am skeptical that other forms of content should be merged together.

<slightlyoff> sure, and in general we look to see if there's a superclass style thing we can extract in future and if a specific design would preclude it...that is, can we extract layering if we need to?


@smaug: worried about setting the precedence of allowing dangerous pattern in the future.

<slightlyoff> e.g. HTML element subclassing came after many concrete elements; would we be able to extract a superclass here? I think we would be able to

tilgovi: what is the relation to the viewport api? Can this behavior be achieved with visual viewport apis?

BoCupp: we are trying to achieve is giving the ability to allow web devs to opt-out from bad behavior.

<smaug> slightlyoff: that might end up working here, but better to think about other cases beforehand. And usually we try to add low level primitives first. Keyboard specific "geometry API" doesn't feel like very low level.

BoCupp: it is my general belief that object should dispatch events about how it is affecting the content.

<slightlyoff> I helped write the extensible web manifesto, so I'm all in on low-level, but am usually happy to take existence-proof-with-opportunity-to-extract if that's the feature a developer willing to do the work wants to offer = )

kenchris: we discussed about the future cases, But we haven't seen this around picture overlays. So, it seems ok. Also, knowing specifically that this is a keyboard helps authors putting correct content.

whsieh: If the page just makes the keyboard to show up in cases where it is useless. I am worried about cases like that.

BoCupp: this seems like a badly written app.

whsieh: Also cases, where app would block keyboard from showing up.

BoCupp: this can happen with input mode: none on iOS today

<slightlyoff> +1 to returning a promise

<slightlyoff> I think whsieh's suggestion is great

whsieh: ack, I agree that misuses can occur with other api. Just looked at web idl, maybe a promise could help?

BoCupp: yeah, that sounds reasonable

drousso: show can be abused so i think, it must be triggered by user interaction.
... there is another aspect in debugging remote bug. We need to have some kind of confirmation or a message signaling about the success.

<slightlyoff> drousso: are you also arguing for guarding `show()` via user activation?

BoCupp: i think, being the active document should help. Some argue that it needs to be a sticky activation. Also, we could be more specific on what user action is required.

<mustaq> Spec for sticky vs transient user activation: https://html.spec.whatwg.org/multipage/interaction.html#user-activation-gated-apis

BoCupp: currently, we require sticky user activation + having an active document.

slightlyoff: usually, cases like iframes require feature policy or permissions
... second to what @Devin said about user activation.

<drousso> FWIW by "error" i actually meant the page deciding to show a `<dialog>` or something

<drousso> but yeah i agree that "error" is not the right concept

<drousso> also slightlyoff yes i was arguing for user interaction :)

<tidoust> [Another possible reason not to show up the virtual keyboard, even though the app requests it, is if the user just manually closed it]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/10/30 15:02:23 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/tidoust:/kenchris:/
Present: smaug grisha BoCupp tidoust whsieh slightlyoff mustaq drousso garykac xiaoqian
No ScribeNick specified.  Guessing ScribeNick: grisha
Inferring Scribes: grisha

WARNING: No "Topic:" lines found.

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]