[minutes] Virtual Keyboard Control Breakout - TPAC 2020

minutes online at:
https://www.w3.org/2020/10/30-editing-minutes.html

plain text version:

Virtual Keyboard Control Breakout - TPAC 2020
30 Oct 2020
Attendees
Present
smaug, grisha, BoCupp, tidoust, whsieh, slightlyoff, mustaq, drousso, 
garykac, xiaoqian
Regrets
Chair
Bo Cupp
Scribe
grisha
Contents
Topics
Summary of Action Items
Summary of Resolutions
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

@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]

Received on Monday, 2 November 2020 11:38:59 UTC