Ken: good, sensible idea...

Dan: should we do something different here to #498 - like maybe close this issue off?

Ken: it's a javascript api and you can only opt in via javascript... we have css environmental variables - why can't i do this from CSS? Instead of having to force people to use javascript? Very specific use case...

Sangwhan: why does it have to be solved this way?

Ken: when the keyboard appears it resizes the viewport... working around that is relaly tough.. So you rather just want the keyboard to appear on top of the content and not resize... Plus if you have dual screen you also don't want it to resize on the other screen that makes no sense...

Sangwhan: ok

Ken: they did file issues... filed 3 days ago... They are still working on it. Maybe we should wait for them to ping us when they have an update...

Sangwhan: this does add entropy because of user-installable keyboards. Exposes info that wasn't exposed before.. could be problematic...

Dan: leave for now - let's mark it as pending editor update and bring it up at the plenary

Sangwhan: multiple things that describe a viewport... one is generic .. not enough..

... 2 viewport APIs...

... one or the other should be deprecated ...

... two parties pushing similar things - one by MS and one by Goog - similar technologies...

... visual viewport work hasn't been updated...

... at least one implementer (Apple) has strongly come out against this proposal...

Dan: could we encourage the parties to come together? Maybe reference SMS receive API as a good example of this happening and creating something better and more widely implemented?

Sangwhan: will get in touch with Kenneth as well to discuss...

Ken: [updating explainers in issue]

Ken: they added some content to the explainer. Support for CSS environmental variables that we suggested.

Alice: Sangwhan [had commented] it wasn't using visual viewport. We talked about getting visual viewport and virtual keyboard folks talking to each other. [reviews latest comments] The overlaysContentProperty seems like a good thing to have. Less clear on what the geometry change event is for. With the example of the env variable setting the position of the search box and then the event repositions the search box but why would you bother with the code when you could use the env variable.

Ken: if you're using a canvas based approach then you would need the API. At lot of MS Office for example is using Canvas. That should be clarified.

Alice: Sangwhan's comment is asking for a more general solution - the response has been that they don't expect there to be a general API. This is a suite of features that all work together... Whether there should be a more general solution.. if there's not then an env variable is good to have... They are adding a virtual keyboard event in navigator. virtual keyboard namespace... now also an event target. Any other types of events?

Dan: does this fit together with "events are for notifications"? in design principles

Alice: I think this isn't violating that.

Alice: navigator.virtualkeyboard has one property which is an event listener that gets geometry change events ... why not just have the geometry available on that instead of having to get it from this event? I should be able to get the dimensions every time.

Ken: I think it should have. That is also how we did generic sensor API. The event just notifies that there is new data.

Sangwhan: [demos a virtual keyboard]

Alice: I think the event makes sense but the data should be available without the event.

Alice: Feedback: it would be nice if we could get the bounding rect of the virtual keyboard at any time.

Alice: you've got the virtual keyboard showing and you want to change the search box... you've got to store a copy of the width and height...

Ken: yes - if you want update it in every request animation frame because you're doing something with canvas then those dimensions might have been changed...

Alice: seems like it might be good to have a generic solution but probably shouldn't be their problem. Who's problem is it?

Sangwhan: picture-in-picture has a similar problem. Payment request as well.

Dan: Some browsers have a "scroll to top" button that brings user to the top of a page - which is overlaid on top of content.

Alice: So it's conceivable we need a general solution. Say we were to generalize this- the geometrychange event would make sense to generalize. So that would be a collection of "obstruction" rectangles. For each of those you would want to know when it changes... Then would you also want a CSS environment variable for each one? And would you want to generalize ...

Dan: could we push this to an existing working group?

Sangwhan: CSS might be interested... not sure how to make this work in CSS.

Alice: It's worth noting that there are specific examples that Sangwhan gave - a set of things that all have these properties of occluding the page. We feel like there should be a general solution - which means it's tricky to say "go ahead and ship this".

Sangwhan: my main concern is that there is a bunch of one-off geometry obstruction notifications. Also one last meta question about API surface. Keyboard is a member of navigator but should that be window? If you're in one tab and you switch to another then you won't have keyboard open any more... navigator feels overly global.

Ken: you have it on multiple screens then how's that gonna work? How does this tie together with screen enumeration API?

Alice: in the last example they give - it has 2 window segments - they keyboard pops up and they move the search box without checking which segment the window is on. So even their own example is weird. How could we help them?

Sangwhan: we could suggest - visual viewport.

Ken: with dual screens it's considered one viewport. If you have a different screen..

Sangwhan: or something completely new... Maybe this should be 2 specs rather than one. The obstructions should be a separate spec from keyboard.

Alice: yes - what is keyboard only?

Sangwhan: i think just geometry change should be generalised.

Alice: Not sure I agree. We've got a bunch of CSS variables that give you the same info as the bounding rect on the event that we think should be in it. In any case environment variables are going to be useful. You're going to need to get the bounds and when the geometry has changed. The only thing that doesn't need to be generalised is when the virtual keyboard changes the viewport height?

Dan: Could we just recommend they call it "interface overlay" instead of keyboard?

Ken: that makes it difficult to do with CSS variables... If you just want to position something where the keyboard is ...

Sangwhan: if you have a keyboard and PiP window and another payment request API popping up then the content should know about these. The separating of the keyboard into 2 is less important.

Alice: the nice thing about the API is that it does help with the split keyboard case... for example the map content appearing between keyboard areas... page content can flow behind.

Dan: next steps?

Alice: I think we can say that it does seem this is going to be a general problem. Shipping a specific solution to a general problem could cause problems down the road. They've identified the elements of a general solution. You need ways to know the geometry of the obstruction and you need to know when that changes. We think this will apply in other cases.

Sangwhan: anything that's browser chromish that could obstruct qualify.

Alice: they might want to reach out to visual viewport. Reach out to PiP to generalize this. Only challenge to generalize would be CSS properties. Could be a collection of objects that work the same as virtual keyboard. Final bit of feedback would be to be able to get the bounds at any time without having to save them from the event.

Alice: it's suspect to have it on navigator ... we're talking about generalizing this - could we generalize this as a pattern. For example window.virtualkeyboard.boundingrect window.virtualkeyboard.overlayscontent could we make that a pattern e.g. window.pictureinpicture.boundingrect etc... And get window.obstructions and it returns a list.

Sangwhan: [looks at PiP spec] PiP also has a resize event.

Alice: it's on us to go to the PiP folks and say 'you should give enough info as virtual keyboard does'.

Sangwhan: they don't have this.

Alice: I see they requested an issue for each point of feedback, so I filed a bunch of issues.

Alice: Refreshing memory on the comments...

... Looking at the linked issues, I see they're all closed.

... Relationship with VisualViewport issue

... Argument is that we don't want a general-purpose occlusion API because not every occlusion should be reacted to by the page.

... VisualViewport draft doesn't list any user needs, hard to tell what was intended.

Sangwhan: I explicitly said web application-initiated occlusion, PiP being a good example.

... Putting the occlusion information in the keyboard namespace seems like something we're going to regret later.

Alice: Any other examples of occlusions we might be interested to react to?

Sangwhan: WebPayments - although some may disagree.

Alice: That's the "pay sheet" or whatever it's called, right?

Sangwhan: There's something native in Chrome, and there's content inside it.

... The response on Relationship with VisualViewport issue starts with "... [VisualViewport] is not a general purpose reporter of occlusions and provides no information today about occlusions. ... I wouldn't want web pages updating their layout as I ALT+TAB to another application that overlaps my browser, or have a web page fight me as a drag around a floating keyboard or a picture-in-picture window."

Alice: I don't think they ever replied to the question asking why it couldn't be a live set of bounds... CSS variables are live, but that doesn't help with the canvas case.

Sangwhan: They added an example for the canvas case, but that's listening to geometry change and then requesting the (live) bounds in a rAF().

Alice: Oh, so the bounds are live now?

... Right, I see it's in the Web IDL now. Oh, and we had actually filed an issue on that that they responded to with that change. Bounding rect property - possible to have it live on virtualKeyboard?

... They did have an issue on the navigator question: Is navigator the right place?

... The response there is "Navigator by definition is the place to represent the state of the user agent, and VirtualKeyboard describes whether the user agent is in a state that could shrink the visual viewport when the virtual keyboard comes up."

Sangwhan: They previously implied that VisualViewport was abandoned, but it's shipping in Chrome and Safari.

... Leaving a comment

[bumped to next week

Sangwhan: They came back with a response...

[...working on this one...]

Ken: they seem to have fixed a lot of the things I wanted them to fix... just wondering about API .. getter and setter ... normally when you have an attribute as well it's just a getter.

Sangwhan: tbh I don't think this is satisfactory ... this felt very one off. It's an occlusion but specific to keyboards.

Ken: but keyboards are very special.

Sangwhan: being handled as a special case... I don't think this is enough of a rationale.

Ken: Actually I think that keyboards are very special - especially on mobile devices. I kind of disagree that you should have a generic occlusion api .. i think there are many cases but keyboard is very important. This is a needed feature.

Sangwhan: there is also implementer disagreement. Webkit has disagreed to this API design.

Ken: I thought they objected to the other part? Also webkit they don't have issues ...

Sangwhan: they have the same concerns...

Sangwhan: mozilla also objects... 2 other browsers are objecting.

Ken: 2 individuals from other browsers... They did look at reusing the visual viewport API and it doesn't make sense...

Sangwhan: as is.. and if visual viewport API doesn't work that way for keyboards then it should be fixed... that was the feedback we had.

Ken: you could argue the same with the insert area ... fixed with CSS.. that was one of my solutions here... if you're using CSS then you probably want something else besides a javascript API. For keyboard this is an actual issue... Have you ever seen any native app adjust to picture-in-picture? not even native apps do that. I haven't heard any good use case for having to work on a windown occluding another window... but for keyboard there is definitely a case. This is a bounding rect - i think that's OK.

Sangwhan: I'll set proposed closing...

Ken: I want people to agree..

Sangwhan: the part where viewport doesn't support CSS is a limitation of that spec, it should, but it's not there. It's not even FPWD. Just feels weird. I have the same concerns of the others who raised concerns on the original one.

Ken: I know it was an issue when we worked on browsers at nokia, it's worth solving. It's a big enough issue that I'm okay with it being a specific API for this use case instead of waiting on the holy grail api that might never appear

Sangwhan: we suggested the namespace could be better. That's what my feedback boiled down to. If you can do it somehow with visual viewport that would be nice, but if visual viewport is unusable then the namespace should be unified. Right now its in navigator.keyboard or something.. occlusions are defined there, imgagine another virtual input modality comes out.. navigator.??.occlusions I thought was short sighted

Ken: that's something I would care about, but nitpicking. Unless you have good suggestions

Sangwhan: if you want to enumerate through things that are occluding the content you want to find it in one place

Ken: so something like navigator.occlusions.keyboard

Sangwhan: could be a list, should be in one place. Other parts about implementation details..

Ken: I'm okay with having a different name, I'm afraid of ding a list and people have to query what it is. If there's nothing else but keyboard people are going to hardcode it and when you add something it will break. You can already iterate properties

Sangwhan: you have to enumerate because of support for split keyboard?

Ken: no split keyboard is always overlay, you can move it around. It's only relevant in the case.... maybe I'm wrong.

Sangwhan: split keyboard reqires you to enumerate

Dan: this sounds like feedback we should be giving them in a closing comment and say this is what we think based on our analysis, but it's up to you.. Not design the solution for them. If we can come up with feedback that both of you can get behind we could leave it in the closing comment and close this off.

Ken: yeah

Sangwhan: they don't have support for split keyboard

Ken: i can write some of this feedback now

Sangwhan: every piece of feedback was bounced back.. we don't know how many ways to split a keyboard, we can't define that, what if it's for accessibility reasons... a corner case

Ken: always the question with trying to figure otu the generic solution, a balance..

Sangwhan: it's not that hard, you need a list of recs instead of a rec

Ken: they'll assume it's one and you'll end up with the same issues. Then you need an API to force developers to not ignore it

Sangwhan: if developers are going to ignore the spec, then...

Ken: if it's a corner case people are not even thinking about that case and will write code that doesn't account for it. Unless you make an API that makes it clear you cannot ignore it

Dan: this is feedback we should provide int he closing comment and making it clear that we think they should be accommodating these cases and working with the applicable communities. Sangwhan mentioned accessibility as a case. They should be working with the community who cares about that case and making sure that what they have accommodates that case. I don't know that it's our role to get into that conversation other than pointing them in the right direction.

Sangwhan: we tried multiple things...

Dan: we should point that out. We don't feel that our feedback has been received.

Ken: that doesn't seem t be the case, they have been responsive. Whether they get what we mean.. it's not that they're not listening

Dan: better to provide actionable feedback.

Sangwhan: it was actionable. Split keyboards is actionable, an API change that's actionable... decided that it's not an action they want to take. We were very specific.

Dan: the question becomes do we close it with ambivalent or unsatisfied? I'm hearing more like ambivalent because there are some areas where Ken feels they've been responsive and some where Sangwhan feels they haven't.

Ken: they have taken some feedback. The thing with CSS environmental variables is in the explainer now. Whether they agree or not is different..

Sangwhan: maybe 10%.. the CSS one is the one thing that changed. I would propose closing.

Ken: I'm going to follow up on it.

Dan: finalise and close at the plenary. Come up with feedback that correctly channels the consensus view that we have

Sangwhan: we should mention that two representatives from different implementers have raised concerns and we don't feel that was properly addressed.

Dan: very valid

Ken: do that and link to exactly those comments and summarize what they said.

Dan: we don't have consensus. We have consensus that they haven't listened to feedback from other implementers and should be working to engage more on cases such as split keyboard and that they have listened to some feedback but not the majority of the feedback. I'm happy with that feedback (below) however the one thing I'm concerned about is are we leaving it unsatisfied or ambivalent.. I think we need to take a TAG straw poll on that one. I don't have a strong opinion. I'd rather not leave something as unsatisfied... it seems to be reserved for things that really haven't listened to us at all.

Ken: posted a personal comment

Dan: can we discuss at plenary and don't say unsatisfied.