Issue metadata
Sign in to add a comment
|
100vh height is wrong in standalone mode
Reported by
ppec...@gmail.com,
Mar 23 2017
|
||||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: In standalone mode, but NOT in full screen API mode, if you use 100vh height the page takes the entire device screen height, as if the Android System Bar were hidden when its in fact still showing. You need to scroll up vertivally to see the bottom of the page. This is related to Issue 428132 . I understand the new 100vh vs 100% height behavior, but then 100vh is wrong in standalone mode. Its correct in other situations, including in Full Screen API. What is the expected behavior? 100vh should take all available space just as in windowed mode when the Address Bar is hidden, not causing scroll. In other words, the height taken by the Android System Bar should be subtracted from the available device screen space. What went wrong? The way it is now, if you use 100vh in standalone mode you get a scroll bar. Then, if you enter Full Screen API, it now works correctly since the Android System Bar is hidden and we really have the entire device screen height available. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: 6.0.1 Flash Version:
,
Mar 24 2017
Would you be able to provide screenshots to illustrate the things you're referring to?
,
Mar 24 2017
I'll try to explain better. If you use height: 100vh; in normal mode, you get all the available space that exists when the Address Bar is hidden, right? That means if you make your <html> element height: 100vh; and scroll down so the Address Bar hides, you get a perfect fit, with no scroll bars. All that with the Android System Bar taking its normal space at the top. When you enter Standalone mode, there is no Address Bar (always hidden), but there is still the Android System Bar on the screen, right? But that same <html> with height: 100vh now tries to take ALL the physical screen height as if the Android System Bar were not there, but it is... This makes it too big to fit, and causes scroll. In that scenario, the 100vh should mean all the physical screen height MINUS the Android System Bar height, you see? Only in true FullScreenAPI mode, when the Android System Bar is also hidden, then 100vh can take all the physical screen height. And that is working ok, btw. That's it: in Standalone mode with the Address Bar always hidden, 100vh should consider that the Android System Bar is still taking up space, but it its not being considered. Got it?
,
Mar 24 2017
Thank you for providing more feedback. Adding requester "alancutter@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 24 2017
,
Mar 24 2017
Yes... I updated my Beta 57 to the latest and its working ok now. Sorry guys! BUT, on a related question... Forget Standalone Mode, I'm now talking about normal mode, with the Address Bar that auto hides and everything. What if I want to make a page that takes all height, and therefore aligns itself with the bottom of the screen with no scrolling possible. But there is a catch, it has to take at least a given minimum height so show the content, and if the device physical screen is smaller to accommodate this minimal height, then its ok to have scroll. But whenever the screen height is bigger, we want the page filling all the space with no scroll, aligned to the bottom. I think that is IMPOSSIBLE now with the new 100vh vs 100% height behavior, since v56. It was possible before in v55. Any idea on how I can achieve this with HTML/CSS, with no events hooked to javascript changing the page height dynamically? Many thanks!
,
Mar 24 2017
Yeah, this is a dup of issue 688738 , the fix didn't make it in time for 56. WRT the question, I'm not sure I understand, isn't that the default behavior if you don't specify any heights? That is, if your content doesn't overflow the screen, there'll be no scrolling. If you're trying to align something to the bottom of the screen (but if there's scrolling align it to the bottom of content), I think you can do that by making the box that contains your content `min-height: 100%; position: absolute` (pos: abs makes absolute children use this box as the container for their position) . Then you can make your bottom footer `position: absolute; bottom: 0` If I'm misunderstanding, feel free to post a more specific example.
,
Mar 24 2017
Yes, that this exactly what I did: - Made <html> height: 100% - Made <body> min-height: 100% - Aligned some content to absolute bottom: 0 BUT, doing that, when the Address Bar auto hides, the total height of the page becomes LESS than the height of the available space, and that makes the content with bottom: 0 NOT aligned with the end of the screen. Understand?
,
Mar 24 2017
Yes, but the address bar can only auto-hide if there's content that overflows the viewport, right? I'm assuming then you're issue is when the content is taller than the viewport. So the solution here it to attach the footer to the bottom of your content's container (because that's logically what you want) and make the content's container min-height: 100%; Here's a quick demo I made: https://bokand.github.io/footer.html is this what you're trying to achieve? Using position absolute has some consequences on how you arrange the rest of your content, but I'm not a CSS pro so there's likely better ways.
,
Mar 24 2017
My content is dynamic, it can be either taller or shorter than the viewport. AND the worst case scenario if when the content height is something in between the available height when the Address Bar is showing and when its not. In this scenario, there is a little content (lets say 15 pixels) that falls below the end of the screen when you open the page and the Address Bar is showing. That makes a scroll possible, and when you scroll, the Address Bar hides and now the 100% height is LESS than the viewport height, and then we get an unusable space at the bottom, and my content no longer aligns with the bottom of the screen since the screen is BIGGER than 100%. I my humble opinion, the new 100% vs 100vh behavior is very annoying. You can't really make anything that is exactly the size of the viewport since it keeps changing when the Address Bar hides, but the corresponding 100% is fixed to some height that is simply wrong when the Bar is hidden...
,
Mar 24 2017
Yes, that is an unfortunate edge case but the alternative is worse on many other cases. It's the trade-off we've chosen. Does putting your content inside a position: fixed container work? Position: fixed still resizes 100% with the URL bar. The other alternative is to use a bit of JS to handle resize events from the URL bar and explicitly size the container element to window.innerHeight. Note: I think there's a missing API here that might help - a CSS property to decide what vh units should represent: the largest viewport, smallest, or dynamic. In your case, you'd want dynamic - resize in response to the URL bar. I'd like to propose that soon, do you think that would solve your issues?
,
Mar 26 2017
I have tried making the <html> or <body> elements fixed, but then I could not get scroll to work when the content is taller than the viewport.... About the unfortunate edge case, what if in this scenario we let the user scroll down, but make the Address Bar NOT hide, since the portion of content that is below the end of the screen is shorter than the Address Bar height and is not enough to fill the space left by the Address Bar? That would avoid the "smaller than viewport" page and the blank unused space at the bottom... In other words... If your content height is not enough to fill the entire space when the Address Bar is hidden, DO NOT hide the Address Bar and make it always visible, INCLUDING the cases when the user is going from Landscape (where the Bar was hidden) back to Portrait (and in this case the Bar should show up again). Just an idea... Paulo
,
Mar 28 2017
Hm, that's an interesting idea. It's somewhat complicated/non-general since the user can pinch-zoom in (on some pages) and create additional scroll. Either we'd keep not-hiding the URL bar in that case or we still have the same issue. But I can see how this might be helpful in the common case. I'll play around with it and see how it feels.
,
Mar 28 2017
Nice!
,
Mar 28 2017
Expected viewport height is larger exactly as Android status bar height. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by candr...@chromium.org
, Mar 23 2017Status: Available (was: Unconfirmed)