Re: [w3c/editing] inputPanelPolicy as a way to control software keyboard (#225)

It totally makes sense for some of those capabilities to be separate. But the viewport-related ones seem misplaced or duplicative. Visual Viewport API is not required to react to browser resizes. Legacy APIs cover that case ok. The only new use cases it enables are adapting to onscreen keyboards and to adapt to auto-hiding browser UI (since that often doesn't trigger resize events).

If we conclude that Visual Viewport API is not good enough for web content to adapt to onscreen keyboards, and can't be enhanced to provide content authors what they need, then perhaps we should deprecate it, or limit its scope to autohiding UI. But I think that would be a bad outcome. I think Visual Viewport API could be enhanced to report individual overlay rects. That way, authors who want to adapt to available screen space won't have to juggle two different APIs. And we won't need to invent still other new APIs for other forms of onscreen overlays, like PIP, or the iPadOS Universal Callout Bar which appears even with a hardware keyboard attached.

In brief, we should inventing a whole new API each time there is major new work to communicate available screen space to web content. That is an anti-pattern. Instead, let's try to enhance existing APIs.

On the other hand, it seems totally reasonable to me for API to explicitly show or hide the keyboard and the like to be in a different place.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/225#issuecomment-614917371