Re: [csswg-drafts] [css-media-queries] Orientation does not respect soft keyboard on mobile devices (#3587)

The CSS Working Group just discussed `Orientation does not respect soft keyboard on mobile devices`.

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: Orientation does not respect soft keyboard on mobile devices<br>
&lt;heycam> github: https://github.com/w3c/csswg-drafts/issues/3587<br>
&lt;heycam> florian: the problem here is as the title says, when the soft keyboard pops up, the screen effectively switches from portrait to landscape<br>
&lt;heycam> ... but that is not reflected by the orientation media feature<br>
&lt;heycam> ... two ways to look at this<br>
&lt;heycam> ... one is to think first if the soft keyboard is more of an overal, or if it changes the size of the viewport<br>
&lt;heycam> .... currently per spec the width/height media features, aspect-ratio, orientation, as well as vw/vh units or the position of fixed pos elements, all of this is supposed to be in sync with the viewport<br>
&lt;heycam> ... if the keyboard is an overaly none changes, if it changes the viewport, then all should change<br>
&lt;heycam> ... so I think it's clear, the UA can choose if it's an overlay or not<br>
&lt;heycam> ... but maybe orientation maybe could be different<br>
&lt;heycam> ... if the author wants to query the orientation of the device itself<br>
&lt;heycam> ... we have some device-related features that are deprecated<br>
&lt;heycam> ... but we don't have one for device-orientation, it sounds like it might be useful on mobile, unclear on desktop<br>
&lt;heycam> ... whether it's useful I'm worried about changing the definitino of orientation<br>
&lt;heycam> ... since it's in sync with the other ones<br>
&lt;heycam> fantasai: I don't think we should change the definition<br>
&lt;heycam> Rossen: definition of screen orientation should not be changed for sure<br>
&lt;heycam> ... based on size<br>
&lt;heycam> ... either platform specific settings which could apply to any shape of output device regardless of width/height being greater than 1 or the other<br>
&lt;heycam> florian: in general I agree but I wonder what we should do if you're on a phone and the keyboard resizes the screen from portrait to landscape, in a way it's not really a landscape orientation, it's a squished portrait<br>
&lt;heycam> ... but if you have a different design for landscape you don't necessarily want to change to it<br>
&lt;heycam> ... but it's a bit fuzzy<br>
&lt;heycam> Rossen: so you're saying by changing the visual viewport you'll reeval the MQ and it's now landscape?<br>
&lt;heycam> florian: yes per spec<br>
&lt;heycam> ... comparing the width/height of the viewport<br>
&lt;heycam> ... if you choose to have a soft keyboard that goes over the viewport and doesn't resize it that 's fine too<br>
&lt;bkardell_> but does anyone do that?<br>
&lt;heycam> bkardell_: does anyone do a keyboard overlay? on my Android devices it seems to resize the viewport<br>
&lt;heycam> florian: I think everyone does resize. it's a UA choice<br>
&lt;heycam> ... the only thing the spec mandates is taht all these things go together<br>
&lt;heycam> ... no way to distinguish units from the MQs or something like that<br>
&lt;heycam> bkardell_: so it does resize the viewport but it doesn't reclaculate?<br>
&lt;heycam> florian: it should recalculate<br>
&lt;heycam> tantek: I just tried doing this on Safari. a popup select chooser did not resize the viewport<br>
&lt;heycam> florian: did you check if it does different things for MQs and vw/vh units?<br>
&lt;heycam> tantek: no, just trying on some websites<br>
&lt;heycam> ... it seems to overlay the user entry portion on top of the page, doesn't resize the page at all<br>
&lt;heycam> ??: ...<br>
&lt;heycam> jensimmons: this issue will only come up if the site has some CSS to adapt to the viewport size<br>
&lt;heycam> tantek: I wouldn't trust FB as an example, they might have some crazy JS in there<br>
&lt;heycam> jensimmons: would be helpful to have some examples to open up on different phones to test this<br>
&lt;heycam> ... what do we want? consistency in following the spec?<br>
&lt;bkardell_> I mean, they have to know where the viewport is right? the same on twitter btw<br>
&lt;tantek> I tried the popup select on https://www.purpleair.com/<br>
&lt;heycam> ... the issue about the device being portrait/landscape, but what about min-height max-height<br>
&lt;heycam> ... do we need to give authors the choice of whether the keyboard is overlaid? or maybe it doesn't come up enough for us to care?<br>
&lt;heycam> tantek: I just tried a simple textarea on a mediawiki page<br>
&lt;heycam> ... the viewport is also maintined, the keyboard comes up just overlaying<br>
&lt;heycam> ... iOS Safari<br>
&lt;heycam> florian: so the page has something that would resize vertically?<br>
&lt;heycam> ... or it's transparent?<br>
&lt;heycam> tantek: the latter<br>
&lt;jensimmons> We need something that resizes in the vertical direction like this: https://labs.jensimmons.com/2017/01-008C.html  **PLUS** a text input<br>
&lt;heycam> florian: this doesn't necessarily give us the answer<br>
&lt;heycam> tantek: for a file input control, it does an overlay of its own UI stuff on top of the page, it doesn't resize anything<br>
&lt;heycam> ... feels like iOS is being consistent<br>
&lt;heycam> florian: unless you have something that is sizing to the veritcal axis, you will not be able to tell between resizing the viewport and not<br>
&lt;heycam> tantek: if we can have a test file<br>
&lt;heycam> jensimmons: I just dropped a demo<br>
&lt;heycam> ... no textarea, but you can see that's an example where if you resize in the vertical direction the layout changes drastically<br>
&lt;heycam> ... the combo of that plus something that triggers the keyboard<br>
&lt;heycam> florian: the test tantek suggested is worth writing<br>
&lt;heycam> ... the other thing: if people have MQs that react to orientation, what are they doing with these?<br>
&lt;heycam> ... so that we can evaluate a bit more whether that is indeed the right thing to do, keeping everything in sync<br>
&lt;heycam> ... or if there is something valid to do that doesn't keep them in sync<br>
&lt;heycam> ... I;m a bit confused what the exact use case is<br>
&lt;heycam> ... I would be uncomfortable with these things getting out of sync, I don't understand what the need is currently<br>
&lt;bkardell_> if you were in a twitter dm and clicked to add text, couldn't the field you were typing in disappear if it overlaid, since it is locked to the bottom of the viewport?<br>
&lt;heycam> myles: if you tap the input do you want the page to relayout?<br>
&lt;heycam> jensimmons: answer is usually no<br>
&lt;heycam> ... but right now it depends on the OS<br>
&lt;heycam> florian: giving the author a choice doesn't sound insane<br>
&lt;heycam> ... what does the MQ evaluate to is a different isuse<br>
&lt;heycam> jensimmons: there are not many people who are making changes to vertical height<br>
&lt;heycam> ... apple is loading different images<br>
&lt;heycam> ... I think this is an issue though<br>
&lt;heycam> ... I'm trying to push designers into understanding<br>
&lt;heycam> ... we'll see in 10 years if I or someone succeeds<br>
&lt;heycam> ... I think this is a case authors should care about<br>
&lt;heycam> florian: responding to the vertical dimension, definitely<br>
&lt;heycam> ... should or should not respond to the screen being shrunk due to the keyboard is harder<br>
&lt;heycam> ... in response to the window resizing to be shorter, and expecitng it not to be relaying out to a different reason (the keyboard) ...<br>
&lt;heycam> Rossen: in all this discussion we've only been considering vertical viewport and not the visual viewport<br>
&lt;heycam> ... if you look atthe last comment, that was added by Matt Rakow<br>
&lt;heycam> ... he has a strong case for taking the visual viewport api spec into consideration with this proposal<br>
&lt;heycam> ... and highlighting the fact that if we start changing what is being proposed here, then windowed / multitasking will start to break<br>
&lt;heycam> ... so we can't really make this to be a device thing<br>
&lt;heycam> florian: is there a right thing to do then?<br>
&lt;heycam> jensimmons: I think it's about visual viewport<br>
&lt;heycam> ... authors think about that<br>
&lt;heycam> florian: there are two points to investigate. one is tantek raised, checking to see that all these things are synchronised<br>
&lt;heycam> ... the other is understanding use cases better<br>
&lt;heycam> ... maybe I can ask Jen to do some homework on the use cases?<br>
&lt;heycam> jensimmons: the use cases [...] if we want to know if we wanted to add something we don't have here, we should think about app use cases<br>
&lt;heycam> florian: I see more of a need for overlay/resizing keyboard, and having the MQs respond to that<br>
&lt;heycam> ... rather than a bunch of MQs that some respond to the viewport and some don't<br>
&lt;tantek> From what I can tell, all input element activations on iOS browser (Safari, Firefox) are overlays, and the page does not resize / reflow / reformat at all. https://www.purpleair.com/map is one example of a page that reflows/reformats to fit the viewport<br>
&lt;myles> can you guys hear me when I talk?<br>
&lt;heycam> Rossen: action item here for jen and ideally others to identify use cases<br>
&lt;tantek> That is, there is no resizing of the viewport on iOS when a soft keyboard, soft popup select, soft file upload UIs are activated by the user<br>
&lt;heycam> ... also we'll hear what Kevin Cook (the issue raiser)<br>
&lt;myles> the iOS keyboard is designed to work in a particular way. There are platform conventions that browsers are designed to obey<br>
&lt;heycam> ... then based on this we might continue the discussion, see what we can do<br>
&lt;heycam> ... sound reasonable?<br>
&lt;heycam> florian: yes<br>
&lt;jensimmons> +1<br>
&lt;heycam> ... I can write a test case and check on Android<br>
&lt;myles> Giving the choice to web authors would be something that would be incompatible with the design of iOS<br>
&lt;heycam> Rossen: I'm more interested in if we can identiy use cases<br>
&lt;heycam> ... not just a test case<br>
&lt;heycam> florian: me too<br>
&lt;heycam> Rossen: but if there is a design pattern blocked/broken by this<br>
&lt;heycam> ... that would gibve a lot more weight to consider this<br>
&lt;tantek> agreed with Rossen's prioritization<br>
&lt;heycam> florian: also understanding what browsers do today is useful<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3587#issuecomment-461248975 using your GitHub account

Received on Thursday, 7 February 2019 00:54:05 UTC