Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Not at all. Issues related with smartphone try to artificially alter the behavior based on observation of the outer picture.
I mean, the browser UI is not part of the DOM, hence it will look the same in any website.
While altering your site based on browser+device makes your webApp consistent across-devices, usually an individual who's used to a given browser or a given device will expect that things to happen.
Moreover converting your WebApp into a PWA or making a native webview for iOS and/or Android, will behave different than opening it in the browser.
So each approach has pros and cons, just need to define whad do you really need for that specific use-case. 😊
Last but not least, let me introduce you to @supports feature query: spec, in which you can add vendor prefixed conditions to know which browser rendered your webApp and thus apply a calc on it like that:
@supports(-moz-appearance:meterbar){/* We're on Mozilla! */min-height:calc(100vh-20px);}
Fun fact: I'm actually the guy who came up with the msie10+ detection hack you mention in your last example.
Unfortunately, since the wrongful handling of 100vh in mobile browsers is not by a fixed height, you can only using the maximum deviation to fix the issue, which then results in large parts of the screen being unused.
Also, reading innerHeight and writing it to a CSS variable won't take too much time and CPU cycles; detecting scroll movements that should trigger the issue and removing the listener if it doesn't arise will be much more involved.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Sure that last paragraph is what solves any situation I can think off, there's no point of discussion here.
I'm trying to define in my head all the situations in which that makes a real difference and not just a "some pixels extra-scroll" thingy, and asking me "is there any alternative way?" Just because linking information is the way I can remember something for years plus I usualy learn something else while trying to answer the question 😅.
@joelbonetr I don't support IE too but we have a new IE on the block called Safari which is the worst in implementing standards and compatible APIs. They are literally thinking browsers are not needed anymore and in a few years they are gone and everything is an app...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Hahaha I know, they have implemented better flex compat in the last 2 years at least, it was a pain in the ass before that but yes, Safari is the new IE.
I work with Windows 11 + WSLg in my personal desktop and Windows 10 + WSL2 in company's laptop so I bought an iPad mini just to test things in Safari as reference (or in any browser because in iPad OS or iOS all browsers rely on Safari 😐).
When using SSR you can not pre-render window/document API-related stuff. So you need to defer this to the client, which usually deals to CLS (Cumulative Layout Shifting) and thus a worse user-experience and a worse score in core web vitals, which lowers your SEO
Just embed the script before the content like so:
<script>
function calcVh() { document.style.setProperty("--100vh", `${window.innerHeight}px`); }
calcVh();
</script>
No issues with SSR and SEO at all.
You need to observe a given identifier to know when it exists, otherwise you can get a "Can't get innerHeight of undefined", which means you add an extra event-listener i.e. resize event.
A drop in the sea. Just add to the script above the following:
window.addEventListener("resize", calcVh);
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not at all. Issues related with smartphone try to artificially alter the behavior based on observation of the outer picture.
I mean, the browser UI is not part of the DOM, hence it will look the same in any website.
While altering your site based on browser+device makes your webApp consistent across-devices, usually an individual who's used to a given browser or a given device will expect that things to happen.
Moreover converting your WebApp into a PWA or making a native webview for iOS and/or Android, will behave different than opening it in the browser.
So each approach has pros and cons, just need to define whad do you really need for that specific use-case. 😊
Last but not least, let me introduce you to
@supports
feature query: spec, in which you can add vendor prefixed conditions to know which browser rendered your webApp and thus apply a calc on it like that:Or using Browser Hacks:
Hope it helps somehow
Fun fact: I'm actually the guy who came up with the msie10+ detection hack you mention in your last example.
Unfortunately, since the wrongful handling of 100vh in mobile browsers is not by a fixed height, you can only using the maximum deviation to fix the issue, which then results in large parts of the screen being unused.
Also, reading innerHeight and writing it to a CSS variable won't take too much time and CPU cycles; detecting scroll movements that should trigger the issue and removing the listener if it doesn't arise will be much more involved.
Sure that last paragraph is what solves any situation I can think off, there's no point of discussion here.
I'm trying to define in my head all the situations in which that makes a real difference and not just a "some pixels extra-scroll" thingy, and asking me "is there any alternative way?" Just because linking information is the way I can remember something for years plus I usualy learn something else while trying to answer the question 😅.
@joelbonetr I don't support IE too but we have a new IE on the block called Safari which is the worst in implementing standards and compatible APIs. They are literally thinking browsers are not needed anymore and in a few years they are gone and everything is an app...
Hahaha I know, they have implemented better flex compat in the last 2 years at least, it was a pain in the ass before that but yes, Safari is the new IE.
I work with Windows 11 + WSLg in my personal desktop and Windows 10 + WSL2 in company's laptop so I bought an iPad mini just to test things in Safari as reference (or in any browser because in iPad OS or iOS all browsers rely on Safari 😐).
@joelbonetr
Just embed the script before the content like so:
No issues with SSR and SEO at all.
A drop in the sea. Just add to the script above the following: