Firstly, I'm well aware that this question has been asked before but there's never been a solution to fix the issue across all devices.
It's been asked at vh / % units and keyboard on mobile devices
, Ignore or disable mobile viewport resize due to keyboard open for text inputs on mobile web?
, and Android Keyboard shrinking the viewport and elements using unit vh in CSS.
I have researched this and tried a few JavaScript & jQuery methods but I can't seem to find a solution that works.
When the keyboard opens in mobile it shrinks the height of the viewport, text and inputs that have been sized with vh all get shorter. I need a way of calculating the initial page viewport height when it loads and then sticking with that height even if the viewport shrinks so that all page items are the same height as if the keyboard wasn't there.
Below is an example of how the inputs look before and after keyboard activation then to the right there's an example of the desired behaviour. I'd like to base vh on the initial height of the viewport for mobile as headers, text, icons and inputs are all sized via vh.
Any help would be appreciated.
EDIT
This question was originally posted on October 30th 2019. This update is being added on July 15th 2020 now that I've had time to look into these briefly after remembering this question a week or so ago. Microsoft's switch to Chromium has been beneficial in many ways but has now caused Chrome to acknowledge this properly with their latest announcement under the heading of Scrolling
How virtual keyboards affect - or don't affect - viewport units in different browsers. (Note recent work from Microsoft Edge on a VirtualKeyboard API that may help here.)
You can read the blog post titled Improving Chromium's browser compatibility in 2020 by clicking it and more about Intent to Prototype: VirtualKeyboard API by clicking that too. Hopefully this helps someone who finds this question in the future.
Related
I am trying out this new implementation where I am updating some div's bottom/top value to emulate fixed position using javascript with scroll event. The problem is while scrolling the div's are getting a fixed position but moving little bit up/down depending on scroll direction. Had to do it this way as I used transform scale. So CSS position fixed doesn't work. Any optimization advice will be very helpful.
the code is here --> Alternative of position fixed using JavaScript shows weird behavior on window resize
If you check my page on desktop/laptop you can experience that. It depends on a lot of variables like how powerful the device is, browser to browser. I am hoping that if anyone has access to MAC OS on safari and chrome or Windows chrome or any desktop/laptop with a decent browser on it may check the user experience and leave a comment about how laggy jittery is it? Is it like okay or bad?
the webpage link --> https://elomymelo.com/soundcore-motion-boom-plus.html
All you need to do is, scroll down half of my page clicking the link above on desktop/laptop. The right side content should get fixed. But may have jittery behavior on scroll. And please leave a comment about how bad is the experience?
Thanks for your time. This will help me a lot to figure out if I should implement it on the other pages or not. Any optimization advice will be very helpful.
I have been searching for the best part of a day in order to try and find a way around this but cant. So here I am.
Basically I am working on a component which is position: fixed; to the bottom of the mobile browser's viewport window. This is trivial in itself.
The issue is that the company's native iOS app has an Apple association file which presents the Apple smart banner to open the native app at the top of the page.
When this is presented to the end user it seems that the browser redefines what it classes as the bottom of the page and, as a result, anything which is fixed to the bottom of the page is overlapped by the navigation toolbar which appears.
The only solution I can think of is to write out a list of all Apple mobile device viewport sizes and then compare the size of the window.innerHeight value on the onresize event -- which seems like absolute overkill and still has some nuance in itself.
I have added some screen shots to illustrate the problem and what I would like to achieve.
Thank you in advance to anyone who can assist with this. I have searched through the answers to other questions but they all seem to be people either trying to surface a smart banner or people trying to redirect to their app.
I have managed to find a solution by leveraging the resize event in the document window and then setting the top attribute of the element to window.innerHeight - element.clientHeight.
If there is a better, more performant way of achieving this I would love to still hear the answer but I will, for all intents and purposes, mark this as answered.
On a side note this does feel like a bug in the Safari browser itself as it seems that Apple are altering what they consider to be the bottom of the document.
Solution:
window.onresize = () => {
const button = document.querySelector(".add-to-bag--sticky");
if (button) {
button.style.top = `${window.innerHeight - button.clientHeight}px`;
}
};
Has anyone had issues with the viewport tag since the iOS7 update? I have a few sites that now have this white margin on the right side. I adjusted the initial scale to 0.1 and it fit the iPhone just fine but on an iPad 3 it was tiny, which makes sense given the low scale.
I didn't have this issue until the update and I can't find any documentation out there regarding any changes to how safari handles the viewport meta tag.
Seems like iOS 7 is a bit buggy using meta description.
I sometimes need to reload me website to be displayed all right.
Maybe Apple will fix that with iOS 7.1. There are a few other bugs as well.
Do you have multiple viewport tags? If so, combine them into a single tag, per this other answer.
I opened the Stack Overflow website on my 47 inch LCD TV (resolution 1920 * 1080, 16:9) and found the text and website right in the middle of a lot of whitespace. The text was unreadable because Stack Overflow, like many other websites, is optimized for standard 1200/1024 viewports.
In order to make the website readable, I pressed 'ctrl' and '+' keys and sort of got the content to occupy more screen width. I am sure this is not "zoom in" because what the browser is actually doing is scale up the content size (i.e. reduces the no. of pixels per character).
Can this 'ctrl +' behavior be achieved using Javascript as a pre-render exercise after detecting the resolution/size parameter of the viewport?
Update: I tried #media-queries which scales font-sizes and other few things, but it doesn't help to scale images and rest of the content (such as padding etc.) in a balanced way. Most importantly, it doesn't satisfy the condition to restrict the size of a given div to say "610px and yet occupy 75%" of the available screen-width.
Which is like a resolution change if we press ctrl + on Gecko/Webkit based browsers. Sorry can't accept the answer below.
Mostly yes.
IE6,7 have zoom and IE8 has -ms-zoom
Everyone else has 2D transforms and scale() so you're covered. see zoom css/javascript
I havent seen anyone apply this sort of effect to the entire document, so things might be buggy. Enjoy!
I'm sure it's possible with javascript, as most things seem to be, but I think that this is the exact kind of problem that CSS Media Queries were specifically designed to solve.
Check out the article on Responsive Web Design over at A List Apart
So, by now we all know that iOS mobile Safari uses viewports (as does Android browser), rather than a 'standard' browser window. And this causes issues with overflow:hidden, and position:fixed.
This unfortunately is the same case with the iPad. I presume this is the case for other Android tablets too.
Rather than browser sniffing each time, is there an easy way to determine if the browser has a viewport or if it is standard?
Unfortunately, there's currently no good fix for mobile browsers' lack of support for position:fixed. The reason position:fixed is "broken" in the first place is because—among other things—no browser vendor knows exactly how to handle what happens when zooming in on the document. If you have some time to do some reading, I highly recommend the following articles, which will explain browser viewports and the problems surrounding fixed positioning on mobile in great, painstaking detail:
A tale of two viewports – part two — how viewports work and the problem of mobile browsers. (If you're not familiar with viewports in desktop browsers or want the background info, see also part one.)
The fifth position value does a fantastic job of explaining the problems surrounding position:fixed in a mobile browser, and suggests we might need a new position value – device-fixed.
Those articles will give you the why, but not the how to fix it. For a truly fixed position, you're mostly out of luck. However, if your goal is to have a fixed toolbar below scrolling content, there are a few ways to hack it. I've had success with iScroll.
Edit: The correct way to determine if you are running on a touch-based device is the following feature detection:
var isTouch = ('ontouchstart' in window);
ontouchstart is an event fired in mobile Safari and the Android browser. It is not present on desktop browsers, where you can just use overflow:auto and have regular scrollbars. If isTouch is true, you can then use iScroll.
Try media queries: you can include stylesheets, or apply parts of a stylesheet conditionally, based on the device and viewport dimensions the browser reports.
This article gives a decent enough introduction: http://www.alistapart.com/articles/responsive-web-design/