Re: [w3ctag/design-reviews] Virtual Keyboard API - boundaries of docked overlay keyboard (#507)

So, @alice and I took a look at this during our VF2F and there is a huge meta-question about this in general - aside from the declarative bit noted by Alice above.

The proposal notifies web applications when something (in this case, a keyboard) obstructs the content, and communicates that through two scalar values (width/height). The meta-question is - this is simply something that defines content obstruction through a non-content entity, so why is namespaced in the virtual keyboard? There are multiple cases where such things can happen (e.g. picture-in-picture, browser chrome dialogs, etc) which could benefit from communicating this information back to the content.

Further questions:

1. The geometry model assumes that the origin is fixed, and only has a single obstruction. How would it work for something like this? https://help.apple.com/assets/5E989062094622C539A9FD75/5E989065094622C539A9FD8A/en_US/d92415de0336bf743eb7c4b6d4540999.png
2. Were multiple obstructions considered but insignificant or was that missed in the design?
3. What would be a better namespace, if this is no longer scoped to virtual keyboards?

I might be digging the rabbit hole deeper than necessary, but would like to hear your thoughts on this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/507#issuecomment-635016277