Closed lpd-au closed 2 years ago
@lpd-au There is no change in the behavior if overlaysContent
is not set to true. It will just follow the existing logic for scrolling editable element into view when keyboard shows up, resizing visual or layout viewports etc. If you notice any changes please file a bug in the corresponding Browser's bug repo.
@snianu isn't that rather confusing design/nomenclature, if setting overlaysContent
to false
still allows the virtual keyboard to overlay content on Safari/iOS as per existing logic?
The spec currently describes
overlaysContent
as "A boolean, initiallyfalse
." It is my understanding that Chrome/Firefox and Safari currently have diverging behaviour on whether the on-screen keyboard overlays the visual viewport, and changing this behaviour would involve a significant web compatibility risk. Unless Safari has expressed an intent to take on this risk and change their default behaviour to match Chrome and Firefox, for backwards compatibility reasons I propose the spec should permit user-agents to define an initial value oftrue
.