Another article that advocates for avoiding vh units completely because of this problem: https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html

frehner on 9 Oct 2019

Agenda+ to make everyone read the article linked above. This is bad and we should do something about it; I'm less sure about what.

fantasai on 10 Oct 2019

👍2

Is this behavior ever useful? Should it not be the case that if the size of the viewport changes, by way of scrollbars or due to browser chrome appearing, the size of the initial containing block changes. Or is there something special about this URL bar?

rachelandrew on 10 Oct 2019

This is bad and we should do something about it; I'm less sure about what.

Agreed! As noted, my proposal doesn’t really solve the issue, but it does at least offer choice and perhaps a better default than how vh currently behaves.

But if someone comes up with a solution that makes the vh unit itself useful again I would be all for it!

Should it not be the case that if the size of the viewport changes, by way of scrollbars or due to browser chrome appearing, the size of the initial containing block changes.

That’s actually how vh units initially behaved! But it turns out that it’s a horrible UX because content would actually move/change size as you scrolled. So Safari (and later Chrome) both agreed that just fixing it to a single height would be the better UX - feel free to take a look at the two citations in my first paragraph.

frehner on 10 Oct 2019

I'm thinking that the issue is that we really need a good default for vh as it stands that doesn't cause data loss, because a lot of web developers do not test very comprehensively on mobile devices, instead they will drag their window small or use RWD browser tools that cause a small viewport. These methods won't highlight the appearing chrome problem you describe. It would be better to have the default for vh be unable to cause data loss even if that caused content to shift, and then add the thing people can opt into that does the other behavior. As the people opting in then presumably know what they are doing. However maybe that ship has sailed.

rachelandrew on 10 Oct 2019

I'm thinking that the issue is that we really need a good default for vh

Agreed; I would love for vh to be useful again.

However maybe that ship has sailed.

Yeah, I think it has unfortunately. There have been issues opened for both browsers for years and all have been closed saying the current behavior is intentional.

frehner on 10 Oct 2019

vh doesn't pay attention to scrollbars, so that it can be a computed-value time unit and not depend on layout.

But nothing stops vh from responding to UA chrome hiding/showing. That's not a content-based decision, it just happens as a result of user interaction. It means we have to invalidate as the chrome disappears, but otherwise is not problematic. I think we can just clarify that the viewport units should do so.

tabatkins on 15 Oct 2019

Further question: should it respond to on-screen-keyboard showing/hiding? I suspect the answer is no, but I'm not sure what answer is most consistent.

tabatkins on 15 Oct 2019

should it respond to on-screen-keyboard showing/hiding?

I would say that yes, any feature for adjusting to URL bar show/hide behavior should also include the keyboard and any other pop-up/pop-over browser widgets that cover part of the layout viewport. Example use case: if the UI consists mostly of a large text box, it's nice to make that fill most of the window. It's less nice if the box gets covered up by the keyboard you're using to type in it, and you end up with a scrolling text box inside a scrolling window.

An alternative to adding new units would be to expose environment variables for the size of the obscured region on each side of the screen. Or maybe, include this type of obscuring in the "safe inset area" variables that are already defined.

AmeliaBR on 15 Oct 2019

👍3

I think we can just clarify that the viewport units should do so.

sorry, can you clarify what you mean by this? Are you proposed that vh units go back to the original behavior of changing the value of 1vh based on UA chrome?

If so, I don't think that is a better solution than the current situation -- that's how it behaved originally and it was a worse experience than what we have now. :)

(If not, sorry, can you explain what you mean? I apologize)

An alternative to adding new units would be to expose environment variables for the size of the obscured region on each side of the screen. Or maybe, include this type of obscuring in the "safe inset area" variables that are already defined.

I think that would put us back at the original behavior of vh units, which means that content actually changes size (and thus can shift underneath the user) when you scroll, right? Or am I misunderstanding your proposal?

frehner on 15 Oct 2019

If so, I don't think that is a better solution than the current situation -- that's how it behaved originally and it was a worse experience than what we have now. :)

Hm, I'm confused then. In what situations would it be worse? Naively, I'd think that it's the best of both worlds, neither under- nor over-flowing regardless of how the chrome is displayed.

I think that would put us back at the original behavior of vh units, which means that content actually changes size (and thus can shift underneath the user) when you scroll, right? Or am I misunderstanding your proposal?

Ah, hm, is this the issue? It's really better to have something over or underflowing than have things possibly shift when the user scrolls?

tabatkins on 15 Oct 2019

Ah, hm, is this the issue? It's really better to have something over or underflowing than have things possibly shift when the user scrolls?

Correct! At least, that's what Safari and Chrome teams agreed as well. Here's a brief history of vh units:

vh units are added to browsers. 1vh changes values depending on UA chrome sizes. This is a bad UX because content is _constantly_ shifting as a user scrolls up and down the page.
Safari changes the value of 1vh to be whatever the height when UA chome is minimal. Here's a quote on their reasoning, around 2015:

This is completely intentional. It took quite a bit of work on our part to achieve this effect. :)

The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS).

It is hard to show you the "looks like shit" part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting.

Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size.

From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.
Chrome follows suit about a year later

So, that's how we got here -- vh units used to change dynamically, then it was determined that was horrible (and honestly it was), but now we're left with a vh value that only reflects the larger view size but not the small view size, which makes full screen designs difficult to work with.

frehner on 15 Oct 2019

Ah, I hadn't realized you wanted vhc to always represent the minimum viewport height (minus the pop-up chrome), even when that chrome isn't current visible.

So there are three distinct use cases:

A stable layout that exactly fits the full viewport with minimized chrome.
A stable layout that exactly fits the viewport when pop-up browser chrome is displayed.
A dynamic layout that always exactly fits the current viewport, regardless of how many browser widgets are surrounding it.

AmeliaBR on 16 Oct 2019

👍4 ❤1

Ah, I hadn't realized you wanted vhc to _always_ represent the minimum viewport height (minus the pop-up chrome), even when that chrome isn't current visible.

So there are three distinct use cases:

A stable layout that exactly fits the full viewport with minimized chrome.

A stable layout that exactly fits the viewport when pop-up browser chrome is displayed.

A dynamic layout that always exactly fits the current viewport, regardless of how many browser widgets are surrounding it.

Seems like a great summary, yes! Thank you.

I think everyone _hoped_ that one css unit (vh) could work for all those cases (and honestly it would be awesome if it did), but I'm not entirely sure what that would look like or how it would work.

So I proposed an additional unit instead :D

frehner on 16 Oct 2019

* A stable layout that exactly fits the viewport when pop-up browser chrome is displayed.

If the vhc means this, it would be confusing. vhc sounds the height includes the browser chrome's height.

Also, I guess the units people really wants is the visual viewport size instead of the layout viewport.
CCing @bokand

hiikezoe on 16 Oct 2019

I initially argued that vh should reflect the minimum possible size but didn't get a response from WebKiters so decided that the larger size and compat with Safari was preferable to a saner default but incompatibility with Safari.

Also, I guess the units people really wants is the visual viewport size instead of the layout viewport.
CCing @bokand

I don't think so. The visual viewport is conceptually detached from layout. i.e. if the user zooms in, the visual viewport shrinks. So we don't ever want layout to depend on visual viewport properties.

I think having a new unit for the minimum possible size sounds fine, or exposing the browser chrome insets instead as @AmeliaBR mentioned (I think that's equivalent to this proposal) which might be easier to explain.

I would say that yes, any feature for adjusting to URL bar show/hide behavior should also include the keyboard and any other pop-up/pop-over browser widgets that cover part of the layout viewport. Example use case: if the UI consists mostly of a large text box, it's nice to make that fill most of the window. It's less nice if the box gets covered up by the keyboard you're using to type in it, and you end up with a scrolling text box inside a scrolling window.

Chrome on Android today resizes the ICB when the keyboard comes in. I think it's a rather regrettable decision since resizing the ICB can take a long time - it's a significant source of making the mobile web feel janky. In addition, it's not uncommon to tap on an editable only for the resized layout to now obscure the box you're trying to type into.

We've had success on ChromeOS using a model where the onscreen keyboard shrinks the visual viewport but leaves layout unchanged. Anecdotally this works much better: the user can still pan around the full viewport but the layout doesn't change at all when the keyboard comes up which works much better, especially on sites that didn't give much thought to onscreen keyboards. Unfortunately it's a difficult thing to bring to Android because of compat so we haven't been able to do it yet.

bokand on 16 Oct 2019

or exposing the browser chrome insets instead as @AmeliaBR mentioned (I think that's equivalent to this proposal) which might be easier to explain.

My only concern with that is: does the size of the inset change as the UA chrome changes size? If so, that feels like we would actually just be back at the initial behavior of vh units, and we wouldn’t have solved anything. But if they remain the same value even as UA chrome resizes, then I think that’s a good alternative to a vhc unit

frehner on 16 Oct 2019

though thinking about it, I'm curious how it would work. If there's 1 value that changes, then that's not good.

If there are 2 values (e.g. something like inset-ua-chrome-small and inset-ua-chrome-large), what would it take to get a full-height element?

For example:

height: 100vhc;

vs

height: calc(100vh - env(inset-ua-chrome-small) + env(inset-ua-chrome-large));

If I'm understanding the proposed env variable correctly - but it's entirely possible I'm not, though.

frehner on 16 Oct 2019

My recommendation would be the inset is a "collapsible height", i.e. how much the UA might expand as a result of scrolling.

In this case, this would be the full URL bar height, regardless of whether that's showing. So the full height would be:

height: calc(100vh - env(inset-collapsible-height))

bokand on 17 Oct 2019

👍4

Ah ok, yeah, that’s not too bad. Personally I would prefer to use a vhc unit (easier understand and teach, and if you have to use that value itself in a calc then it is much simpler than having to do nested calcs - unless you then put it in an custom property or something) but I wouldn’t be opposed to it if that’s what’s decided is better.

I also think you’ll find more developers using vhc (or equivalent) over vh so it would be nice if it were simple, but I have no hard evidence of that -- except for all the articles that say "avoid vh on mobile devices" :P

frehner on 17 Oct 2019

I was talking in slack with someone, and they proposed an alternative idea.

What if the behavior of vh could be determined in a dynamic way, similar to box-sizing? For example

.container {
  vh-sizing: expanded-viewport-height;
  height: 100vh;
}

with vh-sizing options potentially being something like

collapsed-viewport-height (the current behavior of vh)
expanded-viewport-height (the desired behavior of a vhc unit)
exact-viewport-height (a unit that would always match the viewport exactly, even with keyboards or other UA chrome)

(all of these are just placeholder names)

With this pattern, the developer has options for all three use cases as noted by @AmeliaBR here, while also still being able to use vh in a backwards-compatible way with "progressive enhancement" (probably not the right word for it but I hope the idea comes across).

I thought it was a novel enough idea, and the backwards and forwards compatibility aspect of it made it interesting enough for me to add here for feedback as well.

frehner on 17 Oct 2019

👍9 👎1

My concern here is that as long as vh itself is defined to be too big when browser chrome is present, sites developed on desktop using emulation or just narrow window sizes will be designed using the existing viewport units, and not work correctly on mobile. Critical information will be beneath the "fold" in these cases. I agree that the vh unit needs to be stable as the user browses the page, but it seems to me that it would be safer (more consistent with the “avoid dataloss” principle) if the vh unit was tailored to the more conservative size, that corresponds to the size on initial page load. If we then also need a unit that corresponds to the fully-retracted UI's viewport size, then we can add an additional unit for that; but imo the default behavior should be the safer one if possible.

fantasai on 23 Oct 2019

👍2

I agree that the vh unit needs to be stable as the user browses the page, but it seems to me that it would be safer (more consistent with the “avoid dataloss” principle) if the vh unit was tailored to the more conservative size, that corresponds to the size on initial page load. If we then also need a unit that corresponds to the fully-retracted UI's viewport size, then we can add an additional unit for that; but imo the default behavior should be the safer one if possible.

I agree; I think @bokand also mentioned that they (blink) would have preferred that to be the default here. Unfortunately, webkit adopted the opposite and now it's standard.

I think in an ideal world we could change the default behavior of vh, but then you have the potential to break the layout of tons of websites that relied on the old (current) size of vh. In other words, it isn't a 100% backwards compatible change.

Which is why I find the solution I listed above compelling, because it is 100% backwards compatible while also allowing new functionality for devs that opt-in to the new behavior.

frehner on 23 Oct 2019

👍2

The CSS Working Group just discussed Add vhc value.

The full IRC log of that discussion

<dael> Topic: Add vhc value

<dael> github: https://github.com/w3c/csswg-drafts/issues/4329

<fantasai> https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html

<dael> fantasai: Topic is not add a vhc as much as it is solve the problem. Issues is that on mobile we have multiple notions of viewport. viewport units are defined in regards to viewport but on most browsers there's a disappearing address bar

<dael> fantasai: To avoid content from constantly shifting have made that not respond to appear/disappear of address. Problems is deaults being impl makes viewport behavior where 100vh assumes address bar is not visible. THat's not initial state.

<dael> fantasai: Lots of websites design to fit within visible are upon a page load or to have things visible/invisible upon load. Getting that things supposed to be on screen using vh are not visible due to changing height.

<dael> fantasai: Need to solve the problem. Multiple options, could take multiple of them.

<dael> fantasai: Want to hear what others thing

<dael> AmeliaBR: Recap proposals from issue. 1 is don't add any new syntax but encourage any browser with the disappearing nav bar effect to size vh to value when chroma is visible.

<dael> AmeliaBR: Sometimes you'l have more than 100vh visible but on initial load it will fit the screen. That's a guidance to UA without changing language

<dael> AmeliaBR: Original posted suggested alternate unit proportional to the smaller viewport

<dael> fantasai: Third is make the current vh unit to fit the initial load and then add a unit that allows author to take full height of viewport if they want. Inverse of the initial proposal

<dael> fantasai: Problem with that is current keyword is the safer value

<fantasai> s/Problem/Advantage/

<dael> AmeliaBR: Final option is to not add a unit and then add environment variables for disappearing effect so it's similar to inset variables

<dael> florian: Another aspect to problem; it's not just the title, but appearance and disappearance of keyboard. Currently keyboard resizes viewport, but maybe that should only change visual viewport. That's a good idea, but title bar can't do that

<dael> smfr: I don't htink we should derail with keyboard. What you described florian is iOS where it does not change layout height

<dael> florian: If you think it's separate let's keep that out

<dael> smfr: Did any proposals include a unit that changes value when chroma hides? vh that changes

<dael> smfr: It's an option

<dael> TabAtkins: From author feedback they do not want that becaues layout jiggle while it moves

<dael> AmeliaBR: Doesn't behave nicely with things that disappear on scroll. For UX and rendering reasons. For other things like keyboard where it's more discrete it's reasonable.

<dael> smfr: I'm all for avoiding layout jiggle. Seems that pages may be designed such that chrome disappears when you're at bottom

<dael> florian: I think it would be weird to build a page that way

<dael> jensimmons: This is something I've heard a lot, the sentements in this issue. Like many parts of CSS the loudest voices can be most negative. We shoudl work on this and give consideration for all use cases and not jump too quickly and not resolve quickly for what loudest voices say. I'd be happy to work on this and think it through. We need to think about how to animate if they want that. This is more complex. But we should tackle

<jensimmons> +1 to everything should match

<dael> smfr: Related all would match, 100vh, 100% body, window.innerHeight would all mean same thing. Currently don't. Don't know if they can but ti should be a goal

<dael> smfr: Do we know if Andriod has a similar behavior to iOS where 100vh is the chrome hidden state?

<dael> fantasai: Blink has 100vh and 100% on html body meaning different things. 100vh matches Safari. They would like 100% html match but that's currently being a work around for vh not considering address bar

<dael> fantasai: One of the devs that worked on this in Blink said they wanted to argue for 100vh not including address bar but they had to match Safari

<dael> AmeliaBR: Seems like WG took approach for UAs to fill in details and each browser took a different approach and it's not really working and we should come in and specify, but with a range of options for authors so they can do what they want

<AmeliaBR> s/AmeliaBR/jensimmons /

<dael> astearns: Anything else on this to discuss or do we have jensimmons work on the use cases to consider?

<dael> fantasai: I'm happy to kick it to jensimmons to think. It's important and we should not drop, but we can talk later

<dael> astearns: Anything else people want added to discussion?

<dael> astearns: I think smfr list of things that should be eq is excellent

<dael> AmeliaBR: Another option on issue was someone suggesting box sizing like property where authors choose what vh units are relative to. It's another thing to think of

<dael> fantasai: Probably 2 pairs of units would be cleaner and less likely to result in accidental errors

<dael> myles: 2 units might be better cause can use both at the same time. Mode switch you can't use both at same time

<dael> AmeliaBR: Good arguments.

<dbaron> Using both at the same time is probably very hard to do correctly, though.

<dael> AmeliaBR: Lots of options and use cases. Getting through pros and cons for each sounds sensible

<dael> astearns: Let's continue in GH. jensimmons I'll assign it to you?

<dael> jensimmons: Okay

<dael> astearns: We'll discuss again on the call when it's at a good point.

css-meeting-bot on 23 Oct 2019

❤1

I thought it might be useful to write down some of the pros/cons of each proposal so far.

`vhc`

Pros:

easy to use and understand

Cons:

A new unit
Isn't dynamic; would possibly consider adding additional unit(s) to cover other cases (e.g. popup UA chrome sizing?)

Progressive enhancement usage, and a codepen example

.container {
  height: 100vh;
  height: 100vhc;
}

`env(inset-collapsable-height)`

Pros:

Clear and explicit

Cons:

is more difficult to use, especially considering it will probably be used more frequently than vh will
Isn't dynamic; would possibly consider adding additional env variable(s) to cover other cases (e.g. popup UA chrome sizing?)

Progressive enhancement usage, and a codepen example

.container {
  height: calc(100vh - env(inset-collapsable-height, 0px));
}

`vh-sizing`

Pros:

Uses the same vh unit but changes its behavior where supported
Cascades

Cons:

Cannot use different vh definitions in the same block
Cascades ;)
Less clear / direct than a new unit

Progressive enhancement usage, and a codepen example

.container {
  height: 100vh;
  vh-sizing: expanded-viewport-height;
}

Hopefully this is helpful. Let me know if you want me to change/add something to this list as well.

frehner on 29 Oct 2019

Doesn't appear to have an easy way to do progressive enhancement, see this example - (I tested in firefox)

FWIW height: calc(100vh - env(foo, 0px)); does work. That's just because calc(100vh - 0) is invalid, because 0 in calc gets parsed as a <number> instead of a <length>, and you can't subtract <length> and <number>s inside calc.

That may be something worth special-casing / changing to make work? Not sure.

emilio on 30 Oct 2019

Doesn't appear to have an easy way to do progressive enhancement, see this example - (I tested in firefox)

FWIW height: calc(100vh - env(foo, 0px)); does work. That's just because calc(100vh - 0) is invalid, because 0 in calc get's parsed as a <number>, not a <length>, and you can't subtract <length> and <number>s.

That may be something worth special-casing / changing to make work? Not sure.

For clarity, I want these styles to _not_ apply in cases where the browser doesn't understand them, and the problem is that the browser actually does try to apply them even if it doesn't understand them.

For example, if you look at the height: 100vhc example in the browser dev tools, you'll see it's crossed out because the browser doesn't understand it. That's what we want -- browsers that don't understand the unit to not apply the unit.

But in the env example, the browser thinks it understands it and tries to apply it, which is actually what we _don't_ want in this case.

If that makes sense?

frehner on 30 Oct 2019

Well, the way to deal with the variable not being there is setting the fallback value, just like custom properties.

That being said https://github.com/w3c/csswg-drafts/issues/3285 would've probably been the model you want, though env() was shipped without much public discussion... :)

emilio on 30 Oct 2019

FWIW height: calc(100vh - env(foo, 0px)); does work. That's just because calc(100vh - 0) is invalid, because 0 in calc get's parsed as a , not a , and you can't subtract and s.

I can't parse this; do have too many, or not enough, negations?

tabatkins on 31 Oct 2019

Well, the way to deal with the variable not being there is setting the fallback value, just like custom properties.

That being said #3285 would've probably been the model you want, though env() was shipped without much public discussion... :)

I think the point I’m making is being missed - it doesn’t work for progressive enhancement situations, as shown in the code pen. Even with the fallback value for the env value

frehner on 31 Oct 2019

FWIW height: calc(100vh - env(foo, 0px)); does work. That's just because calc(100vh - 0) is invalid, because 0 in calc gets parsed as a <number> instead of a <length>, and you can't subtract <length> and <number>s inside calc.

Why is env(foo, 0px) equivalent to 0?

tabatkins on 31 Oct 2019

Well, the way to deal with the variable not being there is setting the fallback value, just like custom properties.

That being said #3285 would've probably been the model you want, though env() was shipped without much public discussion... :)

Whoops, my apologies, I was wrong. I've updated the codepen and the pros/cons list to show the progressive enhancement for that as well. Thank you for correcting me.

frehner on 31 Oct 2019

Is there anything I'm missing or can do to help out?

frehner on 18 Nov 2019

https://twitter.com/thekitze/status/1196709498670460928?s=20

100vh on iOS will be the end of me as a web developer

A post showing sentiment about this issue.

frehner on 19 Nov 2019

Happy new year!

@jensimmons is there anything I can do to help move this along? I've summarized a list of the current proposals with pros and cons if that helps.

I'm totally willing to do more or help remove any roadblocks that are in my power to remove to help out as well.

Anything to make vh units usable on mobile devices again :)

frehner on 6 Jan 2020

The CSS Working Group just discussed New viewport unit, and agreed to the following:

RESOLVED: Add a set of viewport units (vhc for ex.) that reflect the size of the layout viewport less all UA UI

The full IRC log of that discussion

<fremy> Topic: New viewport unit

<RossenTheReal> github:https://github.com/w3c/csswg-drafts/issues/4329

<fremy> jensimmons: we have discussed this before

<fremy> jensimmons: we are trying to solve the issue on mobile where the viewport changes when you start scrolling

<fremy> jensimmons: (as the bottom bar retracts)

<fremy> jensimmons: you can work around this in javascript, but it's not possible to do in css

<fremy> jensimmons: proposal also includes taking into account the appearance of the keyboard

<fremy> florian: I think the top bar sometimes disappear as well in some OSes

<fremy> jensimmons: ah, good point

<fremy> jensimmons: and those things can keep changing

<fremy> jensimmons: (also, similar to the issue with vw and scrollbars)

<fremy> jensimmons: (maybe it's a different issue, but it's still good to keep it in mind)

<fremy> jensimmons: I am afraid redefining vh/vw might be too late by now, because authors have corrections

<fremy> jensimmons: sometimes we don't want things to resize as the viewport changes, too; we want everything to fit at start and that's it

<fremy> jensimmons: so we should provide all the units to authors, and it's on them to take a look

<fremy> jensimmons: at performance

<fremy> florian: so, we would have a unit that would represent the initial containing block?

<fremy> jensimmons: yes, this new unit would be static, and not change when the chrome changes

<fremy> jensimmons: VHC would be the same but with the chrome maximized

<florian> q+

<fremy> jensimmons: but we could also use an environment variable

<fremy> proposal summarized below:

<fremy> <link>

<jensimmons> https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485

<myles> q+

<fantasai> s/<link>/https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485/

<fremy> dbaron: I just wanted to ask, do we want to talk about keyboards when we talk about maximized chrome?

<fremy> jensimmons: I don't think so, it would only include the normal chrome

<fremy> jensimmons: but an environment variable might be better to handle the keyboard case

<RossenTheReal_> q?

<Zakim> dbaron, you wanted to ask if that includes virtual keyboards

<RossenTheReal_> ack dbaron

<fremy> TabAtkins: most of the times, you don't want your footer to reduce space when the keyboard appears

<fremy> TabAtkins: because content space is already tiny

<fremy> jensimmons: but some things might want to snap etc...

<astearns> my team's use case DOES want to get the reduced space. We want to position the input the keyboard is operating on to be right above the keyboard

<fremy> iank_: for example, adding an additional keyboard row

<fremy> dbaron: but switching keyboard would change the height of keyboards sometimes

<fremy> iank_: and some settings can cause the number bar to appear or not above the letters

<dbaron> s/keyboard/keyboard (between English and Chinese)/

<dbaron> s/settings/form input types/

<TabAtkins> q+

<RossenTheReal_> ack florian

<fremy> florian: I am confused at the idea that the animation concept would work

<fremy> florian: how do you switch between the values on scroll?

<fremy> fantasai: yeah, I don't think that work in practice, because the units are not meant to change the value of the units as you scroll up and down

<fremy> fantasai: because some units are used to compute font size etc and relayout during scroll sounds not great in general

<fremy> fantasai: environment variables are better because it makes it more clear it's gonna change dynamicly

<fremy> fantasai: but the units are useful for the static initial position case

<astearns> for the minutes, there have been multiple call-outs thanking @frehner for the very clear issue opening and summaries

<fremy> florian: I think that answers my question

<fremy> florian: but if we have both, I don't think we need the other viewport units

<jfkthame> q+

<RossenTheReal_> ack myles

<fremy> myles: I think I might repeat a bit but I do agree the two units don't work

<fremy> myles: so we add the dynamic thing

<fremy> myles: but then why do we need the second unit we currently dont have?

<myles> q+

<fremy> fantasai: the reason I think we should have two units, is that the env() variables will be dynamic, but the other ones would not, and allow ...

<fremy> ... to use the concept of minimalized and maximalized chrome in layouts

<fantasai> s/not great in general/not great for users, and also not great for performance/not great for users, or for performance/

<jensimmons> q?

<fremy> florian: an article for the top banner which try to cover the screen as you open the site

<fremy> florian: but you don't want that banner to resize when you scroll or open a keyboard

<fremy> florian: and you can't solve that with the env() and the one unit

<fremy> fantasai: within an article, you can have graphs or images which you want to size in function of the viewport, but you dont want their size to change as you scroll

<fremy> TabAtkins: I strongly agree that we can use both

<fremy> TabAtkins: I would have objected to only add the static ones, but if we have both I am fine

<fremy> fantasai: we don't have a high demand for the keyboard one in general

<fremy> fantasai: and we can't know in advance the size of the keyboard

<TabAtkins> ack TabAtkins

<fremy> fantasai: so I think that use case should only be covered by the dynamic env() unit

<fremy> jfkthame: should we think about privacy

<fantasai> fremy: we already have that info exposed via JS

<dbaron> s/privacy/privacy effects of exposing the size of the keyboard/

<fremy> jfkthame: (because the height of the keyboard might reveal what language the user speaks)

<RossenTheReal_> ack jfkthame

<bkardell_> q+

<fremy> myles: we could also solve all of this with javascript

<fremy> myles: with an event that say "the chrome is stable now, do yourcomputations now"

<RossenTheReal_> ack myles

<fremy> myles: also I would like to note that this will have implications for the webkit framework as multiple browsers have to expose this to us

<florian> q+

<fremy> myles: (which is unfortunate)

<RossenTheReal_> ack bkardell_

<fremy> bkardell_: I'm not entirely clear on what the static thing brings, can someone resummarize?

<myles> s/could also solve/already can solve/

<fremy> TabAtkins: vh is the full height, never reduce

<fremy> TabAtkins: vhc would be the same, but without the bars

<fremy> bkardell_: the vh unit does change

<fremy> jensimmons: only if the window is resized, but not as you scroll

<RossenTheReal_> q?

<fremy> bkardell_: but, you agree they are not purely static, right?

<myles> q+

<fremy> jensimmons: yes, but what we mean by static, is that it's static as you scroll

<fremy> jensimmons: it changes when we need to relayout everything

<fremy> jensimmons: but it doesn't change otherwise

<fremy> myles: comment about vhc not being useful for one example jensimmons showed on the powerpoint

<fremy> jensimmons: good question; both use cases could be fine for designers

<fremy> jensimmons: but at least on desktop vh and vhc it seems the units would always match

<RossenTheReal_> q?

<jensimmons> example: https://labs.jensimmons.com/2016/examples/coversheet-2.html

<fantasai> jensimmons shows an example of a page with a large photo taking up the viewport on load, below it is the rest of the article

<fantasai> The goal is to see the entire photo, and just below the fold the article

<fantasai> scrolling should not change the size of anything on the page, just scrol

<jensimmons> q?

<jensimmons> q+

<fantasai> If the smaller measurement was used, part of the article would show above the fold

<fantasai> This might not be wanted

<fantasai> s/fold/fold when the bottom bar is retracted/

<fantasai> but on the other hand, if important info was aligned to the bottom, the author might want to make sure it's always visible

<fantasai> so using the larger measurement (for retracted bars) would be a problem

<fremy> RossenTheReal_: let's timebox this for another ten minutes

<fremy> florian: I think there is another layer of complexity in this story

<fremy> florian: at least in the keyboard case

<fremy> florian: what if the keyboard is semi-transparent above the content

<fremy> RossenTheReal_: actually one of the things I wanted to mention

<fremy> RossenTheReal_: we had a similar issue with Windows (8?)

<fremy> RossenTheReal_: the keyboard would not change the appwindow size on the platform

<fremy> RossenTheReal_: sometimes the keyboard was not even transparent, it occluded the app

<fremy> RossenTheReal_: but we needed to animate the bottom bar of the app to stay above the keyboard

<fremy> RossenTheReal_: and we had a special "position" value to achieve that

<fremy> RossenTheReal_: but I don't know if having the units would work, because it would be out of sync

<fremy> florian: but we can have the value matches the keyboard all the time

<fremy> florian: but maybe there are good use cases for both, I'm not sure

<hober> q+

<fremy> jensimmons: I don't think we want to debate this issue too much

<fremy> jensimmons: I guess there are use cases for all

<RossenTheReal_> q?

<RossenTheReal_> ack florian

<fremy> florian: thinking that there are two variants of the right case, one where the keyboard is on top, the other when it's reduced

<fremy> jensimmons: I understand but what a viewport means from the implementer is their question

<fremy> jensimmons: but for the point of view of the author, it's about to design an experience, and the question authors have in mind is not this detail

<fremy> florian: but if you want to coordinate static positions, it's difficult because things would get out of sync

<fremy> dbaron: a good point TabAtkins outlined before is: are there actually use cases to size things based on the space that would be left after the keyboard

<fremy> dbaron: but when the keyboard is there

<fremy> dbaron: and I suspect that this might be right, we don't need to worry about hypotheticals about the keyboard

<fremy> dbaron: as long as you can react as the keyboard opens

<fantasai> s/after the keyboard/after the keyboard is added/

<fantasai> s/is there/is not there/

<fantasai> +1 to dbaron

<fremy> emilio: fixed position elements used to respond to the keyboard

<fremy> emilio: and that had complications very soon

<fremy> emilio: do we want env() units to have the same issues?

<fremy> RossenTheReal_: you mean visual vs .... viewport?

<RossenTheReal_> q?

<fremy> TabAtkins: I suppose we want visual

<RossenTheReal_> ack myles

<TabAtkins> Specifically, I think we want this height to match the height of a fixpos with top:0; bottom:0;

<fremy> myles: one note is that I'd want to warn against trying to chase how browsers work today, because that might change in the future

<fremy> myles: when we tried to ship to disappearing bars, we realized there are some problems, and we might fix them at some point

<fremy> myles: I'm not sure we want to have a specific value for each of the iterations we ended up with along the way

<myles> s/browsers work today/browser chrome works today/

<RossenTheReal_> ack jensimmons

<fremy> jensimmons: fantasai said we might want two env() variables, what are they?

<myles> s/might fix them/might want to fix them/

<fremy> fantasai: static: the bigger and the smaller; dynamic: one that's the current one between those two, and the other is what is actually available after the keyboard etc has been taken away

<emilio> q+

<myles> s/we ended up/the browser community ended up/

<fremy> fantasai: I think the keyboard case seems less urgent to solve

<fremy> fantasai: so if we aren't sure what to do in this case, it's ok, but we just had to keep it in mind to choose the right framework

<fremy> emilio: replying to tab about the visual viewport thing

<fremy> emilio: part of the reason we don't update them is performance

<fremy> emilio: and this would kill that performance optimization

<fremy> emilio: if you want the visual viewport behavior (fixedpos-0-0) you also need a width unit

<fremy> emilio: (because when you zoom you change that as well)(

<emilio> ack emilio

<fremy> jensimmons: it seems to me that we are talking about a vh unit that's a fixed unit based on the maximized space

<fremy> jensimmons: vhc would be the minimize space, but also static

<fremy> jensimmons: and the dynamic variable would be whatever it is right now, and yes that would would change 60fps possibly

<RossenTheReal_> q?

<fremy> jensimmons: we will educate

<RossenTheReal_> Zakim, close queue

<Zakim> ok, RossenTheReal_, the speaker queue is closed

<fremy> jensimmons: but maybe we can make a vhk unit to care about the keyboard later

<fremy> jensimmons: "question mark, question mark, question mark" (just thinking out loud)

<fremy> jensimmons: and then there might be another set which is, give me the space available

<fremy> jensimmons: even if it's behind a keyboard (or not)

<RossenTheReal_> ack hober

<fremy> hober: to reply to fantasai list of things, the values is orthogonal

<fremy> hober: but for the use case to know about the keyboard, one of the use case it to add things above the keyboard

<fremy> hober: and that usecase should probably be addressed in html and javascript, maybe not css

<fremy> hober: for example, we thought about some way to add custom buttons for the touch bar in html/js

<fremy> hober: and it seems a more natural fit than trying to emulate this with positioning with css

<fremy> hober: so, is there another use case?

<fremy> astearns: when the textbox is focused, move it right above the keyboard

<fremy> fantasai: you can do that with scroll-snap

<fremy> fantasai: because it will snap to the viewport

<fremy> jensimmons: so, are you arguing it wouldnt be required to do this math with env variables

<bkardell_> astearns: the grey beard seems kind of a give away of that though?

<RossenTheReal_> ack fantasai

<fremy> fantasai: my proposal is the two static sizes (minimized/maximized chrome) and the dynamic one where you report the current size

<fremy> fantasai: vh should probably be the maximized chrome (smaller measurement)

<fremy> fantasai: because if people are designing on desktop, they might not realized that it could end up beyond the fold on mobile as you scroll

<fremy> fantasai: it's not as pretty if you truly wanted to fit

<fremy> TabAtkins: that's a change of behavior

<fremy> fantasai: chrome folks said they would have loved to change, but webkit did the other way around

<fremy> TabAtkins: that was a long time ago, I don't think we could switch without compat

<fremy> fantasai: more breaking than we would fix?

<fremy> hober: yes

<fremy> jensimmons: I would like to come to a resolution with the three we seem to agree on, and leave the fourth one for later

<fremy> hober: I'd be happy to reject the fourth one and reopen later

<fremy> jensimmons: actually the issue doesn't cover the fourth one anyway, so not even needed

<fremy> RossenTheReal_: so, are we reaching a consensus on the two static + one dynamic value?

<fremy> jensimmons: I think so

<fremy> fantasai: also, we would also need to add the symetric values for vhi and vhb

<fremy> hober: I think the issue is that it would be a lot of similar units

<fremy> hober: I'd rather something longer that's more clear

<fremy> fantasai: yeah but that's unfair because vh is short, then if you want to write good code you need to write more

<fremy> fantasai: for instance we already have some confusion with vmin

<fremy> jensimmons: can we resolve on the concepts but not the name?

<fremy> myles: rossen said that the symmetrical values would be needed, but in practice we wouldn't have different values in any browser

<fremy> fantasai: the viewport units are vh, vw, vmin, vmax

<fremy> fantasai: all of these can potentially map to vh

<fantasai> s/vmax/vmax, vi, vb/

<fremy> dbaron: I am not convinced that vmin needs this

<fremy> fantasai: why would you exclude them

<fantasai> i/dbaron/ At that point, the only one that doesn't have this variant is vw, seems a bit odd to leave it out

<dbaron> s/vmin needs this/vmin and vmax need this new feature/

<fremy> RossenTheReal_: in tablet mode on windows, there are different chrome you can trigger when you swipe etc...

<fantasai> s/At that point/fantasai: At that point/

<fremy> RossenTheReal_: things like notifcation bars and whatnot

<fremy> RossenTheReal_: in tablet mode, all of the windows are always maximized

<fremy> RossenTheReal_: and the bars can appear on top of the content

<fremy> RossenTheReal_: (but these bars haved fixed size value known in advance)

<fantasai> I think authors should be able to use these "safely-sized" viewport units with the same level of usability as the "unsafely-sized" viewport units

<fremy> RossenTheReal_: so for us, vw sounds useful

<fremy> emilio: if we don't want things that are sized with them to be affected by zoom

<fremy> fantasai: the vh and the new unit and the initial containing block should all behave the same way

<fremy> fantasai: whether the browser affect the all three the same way, they can do whatever they want

<fantasai> s/whether/as long as/

<fremy> RossenTheReal_: are we ready to make a resolution?

<fremy> RossenTheReal_: can we resolve on the keyboard thing?

<fremy> jensimmons: not necessary

<fremy> RossenTheReal_: is there consensus on vhc? (besides the name)

<fremy> fantasai: plus the variants

<fremy> RossenTheReal_: plus the variants (vi/vb/...)

<fremy> RossenTheReal_: any objection to this set of units?

<fremy> dbaron: not counting scrollbars?

<fremy> emilio: not counting scrollbars

<fremy> RossenTheReal_: let's kick that can down the road, we can rediscuss later

<fremy> RossenTheReal_: but I'm not hearing any objection

<fremy> RossenTheReal_: so let's resolve

<fremy> RESOLVE: adding the set of viewport units (vhc and symmetrical values)

<RossenTheReal_> RESOLVED: Add a set of viewport units (vhc for ex.) that reflect the size of the layout viewport less all UA UI

<fremy> RossenTheReal_: the second question, do we need to provide the events / env variable that allows to transition between them

<fremy> fantasai: I think the consensus was to have the dynamic full size

<fremy> florian: we can also consider giving differences between the dynamic and full one

<fremy> jensimmons: that's simpler to just say that env() variable is exactly like vh but it doesn't stay static

<fremy> jensimmons: and the number is a live measurement of the space, instead of a difference

<dbaron> In hindsight, I think we'd have been better off if we'd called vmin vsmaller, and if we'd called vmax vlarger, or something like that.

<fremy> florian: I don't disagree but I am unsure it answers my question, but ok let's move on

<hober> dbaron: yeah.

<fremy> jensimmons: example of a use case where there is a footer on the side that needs to stay stuck on the bottom of the viewport, even as the user scrolls

<fremy> jensimmons: (done in javascript right now)

<fremy> jensimmons: and I think that use case is important

<fremy> hober: it's a bummer that we have to do relayout during scroll

<hober> s/we have to/we'd have to/

<fremy> myles: there is an alternative that doesn't do that (myles to expand, didn't catch all things)

<myles> as long as there is an alternative that doesn't do layout on scroll, and this is named appropriately, and it is an opt-in mechanism, it's acceptable.

<fremy> jensimmons: vh doesn't already change for performance

<fremy> jensimmons: and that the new env() variable would only be used in cases where it's needed

<fremy> jensimmons: so the perf impact would be lower

<fremy> jensimmons: but I agree we need to enable authors to understand what they are doing so they use the unit only when they really need the animation

<fremy> emilio: also, it's unfortunate because if you use it on the body because then you still need to relayout everything

<fremy> RossenTheReal_: this example works with position:sticky

<fremy> fantasai: this case yes, but it might not always be the case

<fantasai> fantasai: For example, maybe I have an effect where I click on a picture and it becomes the full size of the viewport, should be the size of the viewport right now

<fremy> jensimmons: I am sure there are use cases

<fremy> jensimmons: I could gather more evidence if needed

<fremy> RossenTheReal_: I think we should probably get another example, but I think we should focus on answering the question at hand

<fremy> RossenTheReal_: do we agree to add the dynamic unit?

<fremy> jensimmons: We need to know if this is something we can implement

<fremy> myles: yes, if you can do in js

<bkardell_> q+

<fremy> hober: but it's really problematic that we would need to do layout in scrolling

<fremy> hober: even if we add this, this would stay janky

<fantasai> http://inkedblade.net/viewport-test.html

<bkardell_> q-

<fremy> hober: so I don't think we should do this

<fremy> hober: but we can have smooth perf with position:sticky

<fremy> jensimmons: but there are other examples, if you need to the height to be considered

<fremy> RossenTheReal_: there's position:fixed for that

<fremy> emilio: yes

<fremy> TabAtkins: but there are cases where you only want to show it in some context

<fremy> TabAtkins: and position:fixed make it visible at all times

<dbaron> dbaron: does position:sticky help with that?

<bkardell_> would it be useful to have a collection of use cases and allow the CSSWG to propose how you could do this today, and then let devs tell us why that doesn't suit their needs?

<fantasai> TabAtkins gives example of some widget which is not position fixed or sticky, and is compacted by default, but when expanded (in place) should take the size of the viewport

<hober> s/this would stay janky/this would be an attractive nusiance. the behavior would be just as janky as js./

<fremy> RossenTheReal_: also if you have a "fake fullscreen" where an experience takes the full size of the viewport

<fremy> RossenTheReal_: and you might want to resize that experience as the user is scrolling, so it doesn't go out of bounds of the viewport

<fantasai> hober, this is why we're providing the units, and making them a lot more convenient to work with. vhc or whatever is a lot easier than env(viewport-height) unless you've got a strong reason for the latter

<fremy> RossenTheReal_: you can of course do that with js, and we ask the question whether we want a better solution

<fantasai> btw, anyone with Safari mobile able to load http://inkedblade.net/viewport-test.html ?

<fremy> RossenTheReal_: I think we should probably defer, and see more use cases

<fremy> RossenTheReal_: except if we all agree

<fremy> RossenTheReal_: but the points on perf and layout on scrolling remain

<astearns> I see blue taller than yellow, fantasai

<fremy> fantasai: I pasted a testcase

<fremy> fantasai: there is no interop in a lot of cases

<fremy> emilio: there is been a lot of effort from us to match Chrome/Safari

<fremy> emilio: so I'm surprised we don't match

<fantasai> Safari also showing 100% and 100vh not being equivalent

<fremy> RossenTheReal_: what is showing, I don't have a phone?

<fremy> florian: 100% and 100vh don't always match

<fremy> florian: in Chrome

<fremy> RossenTheReal_: but that's for the previous discussion then?

<fantasai> It's an open point we need to resolve

<astearns> q?

<fremy> RossenTheReal_: let's get back on track

<fremy> RossenTheReal_: can we resolve now, or do we want to defer?

<fremy> jensimmons: I think we should think about this more

<fremy> jensimmons: so let's table this for now

<fremy> fantasai: also, I think we should have a discussion about the compat

<fremy> fantasai: should 100% and 100vh match?

<fremy> hober: I don't think we can resolve this

<fremy> fantasai: the spec doesn't have a concept to allow them to diverge

<fremy> hober: there is a lot of content designed for mobile

<fremy> hober: and they rely on webkit/blink actually

<fremy> fantasai: I would have loved implementations to file an issue

<fremy> fantasai: because right now the spec doesn't match and we were not aware

<astearns> +1 to annoyance at not getting an issue from (multiple!) devs breaking spec behavior

<fremy> heycam: but since we aim to match gecko and blink/webkit, I think yes we would want to update the spec

<fremy> <br type=lunch>

css-meeting-bot on 22 Jan 2020

❤4

Sorry, forgive my ignorance - was the conclusion of the meeting detailed above to move forward or table this proposal for the time being? I'm not sure if the tabling discussion was around this specific proposal or around other things related to it.

frehner on 20 Feb 2020

We're moving forward - we resolved to add new static 'safe' units that will let you lay things out and be guaranteed to fit when all of the browser chrome is present.
The part we did not decide on is whether to do anything about the dynamic cases, when chrome is appearing or disappearing.

astearns on 20 Feb 2020

👍3

We're moving forward - we resolved to add new static 'safe' units that will let you lay things out and be guaranteed to fit when all of the browser chrome is present.
The part we did not decide on is whether to do anything about the dynamic cases, when chrome is appearing or disappearing.

Thank you!

I noticed in the linked bugzilla that there might be some bikeshedding on the name itself (which I totally agree with -- vhc was just a placeholder name I proposed).

Do we need to have that conversation here or will that happen in a separate meeting/location?

frehner on 20 Feb 2020

A conversation here would be fine. I expect this issue will stay open until edits are made on a draft, then it may get closed and a new "should we change the name" issue might get created. If we can close on a name before the edits are made, then all the better.

astearns on 20 Feb 2020

👍1

Removing the tag for css-values-3 as this is new work and should go in css-values-4.css-values-3` is stable, being prepped for Proposed Rec.

svgeesus on 10 Mar 2020

Looking at naming possibilities here, just throwing some out:

vhmin - aka the smaller vh unit.
- con: possible confusion between this and vmin
- possible alternatives: vhm? or minvh?
vhc - as originally proposed: "view height with chrome."
- con: "chrome" is probably not the best word to convey to the average developer what this unit is measuring
vhc - view height collapsed.
- con: collapsed could be confusing - e.g. "is the view height collapsed when the UA chrome is big, or is it the other way around?"

Proposed solution

The problem is with:

a browser design that uses scrolling as a trigger for changing the viewport size by sliding some piece of browser UI into or out of it, causing both scrolling and a change to viewport size to happen simultaneously, and
a browser design that means that vh is calculated based on a something that is NOT actually the visible viewport as required by its definition, most of the time.

So let's start by banning that simultaneous scroll and changing of the viewport size by sliding some toolbar into or out of view. If a toolbar is in the process of being slid into or out of view when the user starts to scroll, pause that while the user scrolls, and then continue it when they are done.

So, now we are left with two challenges: How can we hide the address bar when not needed? How can we show the address bar when needed? We need to do this in a way that leaves the definition of vh in tact most, if not all of the time.

Hiding the address bar when not needed

There are various possibilities here, and I don't think it would matter too much if different browsers choose different approaches. Some possibilities I can think of are:

Hide it immediately as soon as an HTTP request has been made. From a security point of view this is perhaps not the best idea, because the user doesn't get to see where they are being (re)-directed to.
Start hiding it as soon as an HTTP request has been made and while the page is loading. In the meantime take the viewport to be the full height it will eventually achieve with the address bar gone, so that either a) the content briefly loads underneath the address bar while it is getting out the way or b) the content slides into full view as the address bar gets out the way. Only once this transition is complete can the user start interacting/scrolling.
Fully load the page with the address bar in place, but with the viewport at its maximum possible size and so with either the top or bottom being cut off temporarily. Start hiding the address bar as soon as possible provided the user doesn't interact with the page by scrolling. As the address bar is hidden the full viewport will become exposed or will slide back into view.
Fully load the page with the address bar in place and with the viewport having a reduced size because of that, and then provided the user doesn't interact with the page by touching/scrolling - start hiding it, making the viewport expand in size at that point in time.
Like 4, but making the address bar disappear after some period of non-interaction.

Showing the address bar when needed

At present, scrolling in the reverse direction is used as a trigger for re-showing the address bar. That will need to change. Here, I think it would be helpful if there could be a consistent approach across all browsers to the gesture for achieving this. I don't know what the best approach is, but possibilities include:

dragging from the edge of the window where the address bar once was (like opening a drawer or pulling out a tray), noting that doing this again once the address bar is visible could result in a page reload;
touching anywhere non-interactive and holding;
touching anywhere non-interactive and dragging slowly away from an edge (instead of slowly scrolling);
touching anywhere non-interactive and dragging fast away from an edge (instead of rapid scrolling).

In terms of the viewport, the address bar could slide over it, noting that this is only a temporarily infringement (like a temporary keyboard/form input control might), or it could cause the viewport to shrink in size (change in vh).

Re-hiding the address bar on a loaded page

If the user calls up the address bar, but then chooses not to interact with it for some period of time, it could be re-hidden. Whether or not this results in a recorded change in vh will depend on what the browser has decided to do when showing the address bar. I don't think it's critical either way provided the default is for the address bar to be hidden and it's appearance is only fleeting/temporary. (Whereas, at present, you typically have to scroll down the the very bottom of all content, and then some, to be able to reveal content that should always be in view.)

Conclusion

I believe that if browsers take an approach like described above, the problem can be considered fully addressed:

standards compliance restored:
- vh behaves as defined by the spec, either with possible minor short-lived infringements only during a transitions or with a changing viewport size (but not at the same time as user scrolling), depending on exact implementation
consistency of layout between desktop and mobile - possible to use vh and flexbox to position items at top and/or bottom with central scrollable region for both mobile and desktop once again!
problem with simultaneous scrolling and viewport size change eliminated
possible for browsers to implement this in a way that avoids the vh unit changing at all due to address bar movements, with the compromise being that some content will be hidden when the address bar is in place - but only temporarily and briefly, and will be exposed or slide back into view when it gets out the way.

So in this case, I suppose I am saying that I think that browsers should adjust the design of the address bar hiding feature to comply with the CSS spec in a way that provides a good user experience, not the spec being broken to support questionable browser design choices and poor user experience. (If that can't be done in a way that is good for user experience, then perhaps hiding address bars will have to be disabled until such time that CSS provides some new functionality to make it work well - but I don't think this proposal is it, and I think the the proposed solution above can be made to work adequately.)

As such, you could argue that this proposed change to the CSS spec is perhaps no longer required. I think there is still merit in an additional vhmax unit though, which would be based on the maximum size the viewport could have (i.e. with hide-able toolbars hidden). If you want to scale font-sizes, then you would probably want that to be relative to browser window size and may not wish that to be sensitive to minor changes in viewport size which you could get with vh (depending on browser implementation of the address bar hiding). vhmax would give you that.

Whatever is ultimately decided, please don't redefine vh and further break backwards compatibility. Keep vh as is so that websites like ours with elements pinned to the top and bottom are not broken and a central scroll region are not broken, and add new units if that helps.

Thank you.

mind-bending-forks on 19 Nov 2020

❤3

That was a very long post which not everyone will want or have the time to read, so let me try to capture it in a nutshell:

The key thing I am unhappy about is that design of the hiding address bar feature combined with the way scroll works on mobile browsers means that, for mobile browsers only, sites using vh and flexbox like this will have an important part of the viewport cut off for for pretty much the user's whole journey with the page. They only get to see and interact with the whole thing if they scroll right to the very end of the scrollable content and then some.

So, what I'd ideally like:

I'd like mobile browsers to change their design so that the whole viewport (i.e. all 100vh of it) is visible most, if not all of the time. For my example above, that means that the user should not be required to scroll to the bottom of the scrollable content to reveal the full viewport. Some other mechanism is needed. Some ideas for how to achieve this are above.
When I have a filed bug relating to this, I have been told WONT FIX with a link to this issue. So, I'd like a clear statement from here that any browser design that results in the some of the defined viewport being cut off pretty much all of the time, and thus resulting in a different experience across desktop and mobile, is non-standard conforming and needs to be fixed. Breaking websites in such a way should not be an accepted outcome of this proposal.

mind-bending-forks on 20 Nov 2020

So, I'd like a clear statement from here that any browser design that results in the some of the defined viewport being cut off pretty much all of the time, and thus resulting in a different experience across desktop and mobile, is non-standard conforming and needs to be fixed. Breaking websites in such a way should not be an accepted outcome of this proposal.

I'm not sure where or why you've come to the conclusion that "breaking websites in such a way" is a desired outcome of this proposal. I've acknowledged in this proposal that the current behavior is not ideal, and my intent with this proposal is to provide a hopefully simple-to-implement-by-browsers workaround for how things currently are (with the goal that it could get released sooner rather than later........) This proposal, for better or worse, doesn't change the current behavior of vh - it is meant to provide a workaround/new option by way of a new unit.

I have been told WONT FIX with a link to this issue.

It seems to me from that bug report that this wasn't linked to as a _solution_ to your problem, but as a _see also_ to your problem; in other words, perhaps this proposal could help you in the meantime (if it's accepted/implemented).

That said, I would love for an additional proposal to be created that addresses the root cause and gets browsers to conform to it; I would fully support it (not that my support means much 🙂 ).

frehner on 20 Nov 2020

👍1

Thanks @frehner.

in other words, perhaps this proposal could help you in the meantime (if it's accepted/implemented).

I appreciate your efforts. Unfortunately ~this proposal~ the proposed vhc unit won't help our particular case.

I'm new here and not familiar with the CSS spec process. Please can you point me to the full specification of exactly what this proposal is, so that I am not talking at cross purposes? Is it literally just what is said in the Proposal section of https://github.com/w3c/csswg-drafts/issues/4329#issue-495372962, that is, to introduce a new unit, vhc that is based on the minimum possible viewport size, or is it more than that? Earlier comments in the thread give the distinct impression that vh itself was being changed or being considered for change too.

Also, we initially raised an issue about the breakage in Firefox for Android, and were told that it would be addressed by this issue, but then that issue was subsequently closed without fixing the breakage. When we commented on the closure, we were pointed to a document that indicates that Safari, Firefox and Chrome mobile browsers are now all taking the definition of vh to be "relative to the largest possible viewable area" (rather than as per the CSS spec). When we complained about that we were told:

If you want to change the vh unit behavior, you should open a spec issue in https://github.com/w3c/csswg-drafts instead.

which led us to believe that vh had or was already being redefined in the standard to be "relative to the largest possible viewable area" and that we would need to open a spec issue if we wanted to change it back. We were also told:

There is an ongoing discussion to change the spec description about vh units and introduce a new CSS unit which is not including dynamic toolbar height, it's https://github.com/w3c/csswg-drafts/issues/4329

Again, we read this as two things: a) change the spec description about vh and b) introduce a new CSS unit.

We were also asked to file new issues in against Firefox for the problems that had not been addressed, one of which was the specific breakage I have been referring to. That was then marked as WONT FIX though with a link to this thread.

So, we understood (perhaps misunderstood) that this thread and associated proposed changes to the CSS spec were being:

used as a justification for marking the current breakage as WONT FIX in Firefox (else why mark as WONT FIX) and
that the vh unit was being suggested for modification here too... (with earlier comments in the thread talking about how vh can be changed to make it useful etc.)

So:

If the definition of vh in the spec is not actually being changed, then I'm not sure that I need to file a proposal here. If it is agreed that vh is intended to be relative to the "visible" viewport size, then mobile browsers are currently not respecting that. It would seem that I need to file new issues on Firefox, Safari and Android requesting that they change the way they work to be compatible with the spec. and so my proposal needs to be sent to them (in triplicate?) instead.
If the definition of vh is being considered for change within the CSS spec (for example, to mean "relative to the largest possible viewable area"), either here or in some other proposal, then please can someone point me to that, so that I can comment there?

Thanks.

mind-bending-forks on 20 Nov 2020

If the definition of vh _is_ being considered for change within the CSS spec (for example, to mean "relative to the largest possible viewable area"), either here or in some other proposal, then please can someone point me to that, so that I can comment there?

I think of this as less a _change_, and more a _clarification_, to reflect existing practice of how browsers are already interpreting vh on mobile platforms. I do think it's important that this clarification be made, to avoid confusion, and the work-in-progress PR for this issue does contain wording that includes this clarification.

theres-waldo on 20 Nov 2020

If the definition of vh _is_ being considered for change within the CSS spec (for example, to mean "relative to the largest possible viewable area"), either here or in some other proposal, then please can someone point me to that, so that I can comment there?

I think of this as less a _change_, and more a _clarification_, to reflect existing practice of how browsers are already interpreting vh on mobile platforms. I do think it's important that this clarification be made, to avoid confusion, and the work-in-progress PR for this issue does contain wording that includes this clarification.

To be clear, I added that but it doesn’t have to be there - it wasn’t discussed as part of this proposal so it could be removed.

frehner on 20 Nov 2020

I think a clarification, whether that be here or in a separate proposal for change to the spec. would be helpful. I would propose something different to the modification that @frehner has already started drafting though. Maybe something like this at some appropriate point in the spec.:

On occasion, the user agent may need to change the area available for the display of content. If that change is:

associated with the display of additional user interface required to undertake a specific action, such as a keyboard when assistance with form input is required or an address bar when the user needs to navigate or to a new location, and is also

temporary by design such that:

the user interface only appears when required or requested by the user, and

the additional user interface is removed when the user completes the action, dismisses it or undertakes an unrelated action,

then it is at the discretion of the user agent as to whether that constitutes either

an overlay (with no change to vh or vw), or

a change of the viewport area (with corresponding reduction in vhor vw).

Any other change of the area within which content is displayed must be interpreted by the user agent as a change in the viewport.

I hope that this would make it clear that the current situation on mobile browsers, whereby an address bar is present at a point when the user has not requested it causing the content to be pushed down and the viewport to be truncated at the bottom, and this state persisting until the user has scrolled right to the bottom of the scrollable content and then a bit more before the address bar finally moves out the way and full viewport finally becomes visible, is not compatible with the standard and so is not acceptable browser/user agent design: It fails the criterion that the additional user interface (address bar) is only presented when required or when requested, and it fails the criterion that it is gets out the way as soon as it is not needed any more. It means browsers will have to change the design of that feature (address bar scroll bar interaction) or keep the feature but alter (fix) vh to be compatible with the actual viewport again.

Regarding this proposal for a new unit representing 1% of the "minimum possible" viewport size, is it a well-defined/workable/future-proof concept in general terms? I'm not sure that it is. (I've edited this to clarify concerns...)

How will a user agent know in advance whether the user will call up an address bar or a small or large keyboard or other control, each of which could have a different size? Does the user agent need to choose the smallest possible area based on all possible 'overlays' to be on the safe side?
The size of the additional UI and so remaining available space could depend on user agent/OS font sizes, zoom or accessibility settings, and so vhc would change if those change, shrinking if the controls expand. Is that expected/wanted behaviour?
What happens in future if a browser decides to let the user slide the address bar out even further to expose some other control such that the minimum size shrinks? Does that mean that any web content using vhc in that browser would unexpectedly look different because the minimum theoretical size has changed, even though that new control would not be visible most of the time?

So, if a new unit is to be added to the spec, I would suggest that it represent "1% of the maximum possible viewport size" instead, which is a much more clearly defined (and understood I think) quantity, since any user agent will place the viewport within some kind of container that has limits on its size. On desktop browsers, where users can choose to display or hide various display toolbars, status bars etc. this will be relative to the maximum viewport size they could theoretically achieve by hiding them all. The key thing is that it would scale with the user agent container/browser window, and would not change when the viewport changes size due to changes in the user agent interface, and so would be suitable for scaling fonts etc. (regardless of how browsers choose to interpret vh).

With the changes above (clarification and different new unit):

the vhmax or "1% of the maximum possible viewport size" unit would be suitable for scaling fonts/content, and
the vh unit would - once again I hope - be suitable for positioning content.

mind-bending-forks on 21 Nov 2020

If the definition of vh _is_ being considered for change within the CSS spec (for example, to mean "relative to the largest possible viewable area"), either here or in some other proposal, then please can someone point me to that, so that I can comment there?

I think of this as less a _change_, and more a _clarification_, to reflect existing practice of how browsers are already interpreting vh on mobile platforms.

I'd like to challenge the point about this being a _clarification_ not a _change_. About a year to a year and a half ago, all browsers, including mobile browsers, were interpreting vh as being relative to the _visible_ viewport. This was its initial definition back in 2005, was also its defintion in the first candidate recommendation back in 2012 and remains its unambiguous definition in the CSS current spec:

"Viewport-percentage lengths" defined relative to the initial containing block: https://www.w3.org/TR/css-values-3/#viewport-relative-lengths
... and the definition of initial containing block links this to the viewport, "For continuous media, it has the dimensions of the viewport and is anchored at the canvas origin; it is the page area for paged media." https://www.w3.org/TR/CSS21/visudet.html#containing-block-details
... and the viewport definition makes it clear that this is the area and through which users can interact with the content: "User agents for continuous media generally offer users a viewport (a window or other viewing area on the screen) through which users consult a document."

From the moment vh became widely available in browsers, content creators (like ourselves) were using it for both positioning and scaling content. Then, in the past year and a bit mobile browsers, wanting to implement hiding toolbars, found that their chosen design didn't provide a good user experience. Instead of changing the design to fix it, they took a wrong turn and decided to reinterpret vh to be the maximum possible viewport size instead in an attempt to patch the problem. However, this patch had the unintended consequence of breaking websites like our own that were using vh for positioning of content within the visible viewport. The current draft of this proposal unnecessarily (and unacceptably in my view) formalises a change of the definition of vh from "relative to the viewport area (the viewport being what you can see and interact with)" to "relative to the maximum possible viewport area". It is therefore accepting a backwards incompatible change that results in breakage for websites that have been using the current definition of vh - which has been in the spec in some form for 15 years. The current draft text definitely represents a _change_ and not a _clarification_, since it changes the way that some websites using vh function in such a way that they are broken.

The wrong turn that mobile browsers have made is relatively recent in the grand scheme of things and I observe that the design of such features is still in flux, and so it can be fixed/undone/improved. So I don't see any need to change the spec with regards to vh meaning the visible viewport. However, clarification on how browsers should handle changes in the visible viewport due to additional toolbars and whatnot and giving some leeway for brief/temporary overlays, as per my previous post, would be useful, I think and would hopefully allow browsers to update their design in a way that is good for user experience and content creators alike.

mind-bending-forks on 21 Nov 2020

It’s been 5 years that mobile browsers have been doing this. See https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-542420036

frehner on 21 Nov 2020

Regarding this proposal for a new unit representing 1% of the "minimum possible" viewport size, is it a well-defined/workable/future-proof concept in general terms? I'm not sure that it is. (I've edited this to clarify concerns...)

How will a user agent know in advance whether the user will call up an address bar or a small or large keyboard or other control, each of which could have a different size? Does the user agent need to choose the smallest possible area based on all possible 'overlays' to be on the safe side?

The size of the additional UI and so remaining available space could depend on user agent/OS font sizes, zoom or accessibility settings, and so vhc would change if those change, shrinking if the controls expand. Is that expected/wanted behaviour?

What happens in future if a browser decides to let the user slide the address bar out even further to expose some other control such that the minimum size shrinks? Does that mean that any web content using vhc in that browser would unexpectedly look different because the minimum theoretical size has changed, even though that new control would not be visible most of the time?

My understanding of the proposal is that vhc would be 1% of the minimum possible viewport size given the _current_ settings. So, if you change the system font size in a way that affects the height of the address bar, the page would be reflowed and vhc sizes recomputed. But if you just trigger hiding or showing the address bar through interactions with the page, it would not.

theres-waldo on 21 Nov 2020

... and the viewport definition makes it clear that this is the area and through which users can interact with the content: "User agents for continuous media generally offer users a viewport (a window or other viewing area on the screen) through which users consult a document."

Terms that were unambiguous at the time a spec was written can become less clear when the spec is applied in a new context such as mobile browsing.

"Viewport" is an example of such a term. In mobile browsers, the ability to pinch-zoom the page without reflowing it (which implies pinch-zooming does not change the initial containing block (ICB) from which page elements derive their sizes) has meant that the "viewport" used to derive quantities such as the ICB or scroll positions reported via window.scrollX/Y is not necessarily the same as what's currently visible on screen. The Web Viewports Explainer document provides good background information on this subject.

theres-waldo on 21 Nov 2020

@frehner said:

It’s been 5 years that mobile browsers have been doing this. See #4329 (comment)

Thanks for the link.

It looks like this actually landed in Chrome for Android in version 56, in Feb 2017.

It's interesting to see that the problem with the (then) new design was reported as far back as Feb 2015 on iOS and objected to multiple times by different people and yet there appears to have been and to still be no intent to address these concerns within Safari or any of the other mobile browsers. I'm not sure why it is not seen as a problem that needs addressing. Benjamin Poulain said back in 2015 in defence of problem it created that "This is completely intentional. It took quite a bit of work on our part to achieve this effect. :)" and he also said "For positioning, you can look into "fixed" and "sticky" positinioning. Those two modes creates layers that are composited in real time." So he clearly understood that positioning of content was an issue with the new design, yet missed the point as far as I am concerned. Position fixed and sticky do something different. They take those elements out of the flow. They don't allow you to have a central scrollable region with dynamically determined height, which is what is actually broken. The proposed workaround doesn't help here.

It does look like my team is somewhat late in identifying this problem. I've checked issues surrounding the release in September 2019 of a website using flexbox and a 100vh viewport to position elements at top and bottom with a central scroll. I see that in testing there, we observed that the website was completely broken in Safari on iOS 12 with scroll not functioning at all, but that iOS 13, which had just been released, fixed this. I see that we ended up including -webkit-overflow-scrolling: touch; in an attempt to fix that for iOS users that had not yet upgraded to 13. There is no report of this specific issue that I can find though.

Personally, I use Firefox as my primary Android browser and only noticed this with the release of the 'new' Firefox for Android version 80 in August 2020, in which what appears to have been a very poorly tested (not meaning to offend, but that's my experience) bottom url bar feature was introduced as default. Noting that it caused problems on various sites prompted me to check how our own sites fared. That's what has ultimately alerted me to this.

@theres-waldo said:

The size of the additional UI and so remaining available space could depend on user agent/OS font sizes, zoom or accessibility settings, and so vhc would change if those change, shrinking if the controls expand. Is that expected/wanted behaviour?
My understanding of the proposal is that vhc would be 1% of the minimum possible viewport size given the _current_ settings. So, if you change the system font size in a way that affects the height of the address bar, the page would be reflowed and vhc sizes recomputed. But if you just trigger hiding or showing the address bar through interactions with the page, it would not.

Sure, I understand that. What I was trying to get at, but not very well, is that you could have two different users with the same browser and browser window size, user A and B. User B's browser UI could take up more space (e.g. larger UI for accessibility reasons) and so have a smaller viewport. If the new unit is used to scale content, user B would have their content scaled down more and so be smaller. If that is understood and is accepted behaviour, that is fine. I suppose I don't fully understand what the intent of the new unit is though. If it's to help with scaling then I can't see advantage of it over scaling against the maximum possible viewport size, which is a simpler and better defined concept. If it's to help with positioning content in view, it doesn't since developers can't know which part of the viewport (top or bottom) will be cut off by the browser, based on the browser design and the CSS spec.

@theres-waldo said:

... and the viewport definition makes it clear that this is the area and through which users can interact with the content: "User agents for continuous media generally offer users a viewport (a window or other viewing area on the screen) through which users consult a document."

Terms that were unambiguous at the time a spec was written can become less clear when the spec is applied in a new context such as mobile browsing.

"Viewport" is an example of such a term. In mobile browsers, the ability to pinch-zoom the page without reflowing it (which implies pinch-zooming does not change the initial containing block (ICB) from which page elements derive their sizes) has meant that the "viewport" used to derive quantities such as the ICB or scroll positions reported via window.scrollX/Y is not necessarily the same as what's currently visible on screen. The Web Viewports Explainer document provides good background information on this subject.

Thanks for the link. That took me a while to digest and has forced me to think a lot. I understand better what the current draft text is proposing and attempting to achieve in modifying the definition of vh to "When user agent chrome does not change size, it is equal to 1% of the height of the initial containing block. When user agent chrome does change size, it is equal to 1% of the height of the initial containing block with the user agent chrome at its smallest size." However, I still don't think it's the right way forward, personally. The definition "Equal to 1% of the height of the initial containing block." is fine as is and does not need modification. The question that needs clarifying is, is a user agent allowed to put 'chrome'/UI on top of the ICB or partially obscure some part of the ICB by shifting it, and do so without modifying viewport-relative units as is currently happening on mobile browsers? If so how and when can they do that?

I've taken a look at how Chrome for Android, Firefox for Android and Firefox for Android Nightly work this evening. I have looked at how they work for two web pages A) and B), and in normal browsing and private browsing modes:

Web Page A) is simply a sufficient quantity of content arranged linearly such that it will overflow the visible viewport:

<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Web Page A</title>
    <style>
* { margin: 0; }
main { background-color: grey; }
header, footer { background-color: green; }
    </style>
  </head>
  <body>
    <header>Header: Start of content</header>
    <main>
      <ol>
        <li>First item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Item</li><li>Last item</li>
      </ol>
    </main>
    <footer>Footer: End of content</footer>
  </body>
</html>

Web Page B is a variant on this with a header and footer fixed to the top and bottom of the viewport and a central scrollable region using 100vh and flexbox, which you can find above in an earlier comment, and which you can view for yourself.

I observed the following:

Chrome for Android

Web Page A - Normal Browsing

Initially: The address bar is shown at the top. The content starts at the bottom of the address bar.
As I scroll down (swipe up), the address bar immediately slides out the way and the content shifts up.
I can continue to scroll until I reach the bottom of the content.
If I scroll back up (swipe down) at any point, the address bar slides back into view.

Web Page A - Private Browsing

Initially: The address bar is shown at the top. The content starts at the bottom of the address bar.
As I scroll down (swipe up), the address bar stays put! This appears to be a bug in Chrome. It only happens the first time after a page load/reload. Thereafter, if the user scrolls back up and then back down, the address bar starts moving out the way like a normal-browsing window.
I can continue to scroll until I reach the bottom of the content.

Web Page B - Normal Browsing

Initially: The address bar is shown at the top. The fixed header is positioned at the bottom of the address bar. The fixed footer is nowhere to be seen. It's cut off the bottom. A user would not know that it even existed in this case.
As I scroll down (swipe up), the address bar stays put and the central region scrolls with the footer remaining cut off.
If I scroll back up (swipe down) at any point, this simply changes the scroll position and does not affect the address bar.
As I reach the bottom of the central region, the address bar starts to disappear off the top of the of the window and the entire content shifts up with it to eventually reveal the footer.
Now, if I wish to reveal the address bar, I have to scroll the entire way back to the top of the list. Then, if I scroll more, everything shifts down and only then is the address bar revealed.

Web Page B - Private Browsing

Same as normal browsing.

Comment on Chrome for Android behaviour

Behaviour for Web Page A is acceptable to me.
- The ICB is the size of the viewport without the address bar.
- The "viewport" has the same size as the ICB (as per spec), but is initially positioned such that the bottom of it is cut off. However, this is only temporary: The ICB (and hence full viewport) shifts back into view as soon as the user starts interacting with the page by scrolling. Thus, the entirety of the viewport is visible most of the time.
- An alternative would have been to keep the viewport in the same position as the ICB and as if the address bar was not there. The address bar would initially be rendered on top of the viewport, but would move out the way quickly (e.g. after a short period of time, or if the user starts interacting with the content, such as by touching/scrolling as described above ).
  - There appears to be a bug in the address bar hide/reveal in private browsing.
Behaviour for Web Page B is not acceptable to me.
- The address bar does not get out the way, and so what should be the visible viewport is truncated the majority of the time.
- If the behaviour was adjusted so that the address bar moved out the way as soon as the user started to scroll, just like for Web Page A, the problem would be adequately addressed. It seems inconsistent that Web Page A and Web Page B behave differently with regards to scroll and address bar hiding. I cannot think of any obvious technical reason why Chrome (or any other browser) would not be able to implement that. If that was fixed, then we would be in a situation whereby the visible viewport was only briefly and temporarily obscured/truncated again. (Hence my proposal to explicitly allow temporarily overlaying or truncating the viewport.)
- If that could not be done for whatever reason, then in this case, because the address bar does not get out of the way and is a (semi-)permanent feature, viewport = ICB ought to be taken as the visible area with the address bar shown. That would avoid content that should be visible being cut off.

Firefox for Android

Web Page A - Normal Browsing

Initially: The address bar is shown at the bottom. The content starts at the top app window.
As I scroll down (swipe up), the address bar immediately slides out the way.
I can scroll until I reach the bottom of the content.
If I scroll back up (swipe down) at any point, the address bar slides back into view.

Web Page A - Private Browsing

Same as normal browsing.

Web Page B - Normal Browsing

Initially: The address bar is shown at the bottom. The fixed header is positioned at the top of the app window. The fixed footer is nowhere to be seen. It's cut off the bottom. A user would not know that it existed.
As I scroll down (swipe up), the address bar stays put and the central region scrolls with the footer remaining cut off.
I can never reveal the bottom of the list in the central region, nor the bottom footer. The scroll hits a buffer and doesn't permit me to.
If I scroll back up (swipe down) at any point, this simply changes the scroll position.

Web Page B - Private Browsing

Same as normal browsing.

Comment on Firefox for Android behaviour

Same issues with Firefox as with Chrome. For web page B, the address bar doesn't get out the way, resulting in what should be the visible viewport being truncated most, if not all the time.
There is also a bug with scroll that is only partially addressed in Firefox Nightly. In the current Firefox nightly, you get as far as you can scroll, which still has content hidden under the address bar. Then, if you attempt to scroll some more the address bar drops away only to reveal that the viewport is off the bottom of the window, with white space underneath. This has already been reported. Also, sometimes the scroll gets stuck and you can't scroll back up. That too has been reported.

I'll leave Safari on iOS as an exercise for the reader!

I hope this helps understand why I proposed above, to keep the current definition of vh, but add a clarification that it is acceptable for user agents to overlay/obscure/truncate part of the visible viewport, provided it is only temporary and brief and for a specific reason. It normalises the good bits of current mobile browser design (e.g. how web page A behaves), while forbidding the bad bits (how web page B currently behaves) without requiring a change to the current definition of vh. I've tried to improve/simplify my previous text here:

The user agent may either a) overlay the visible viewport or b) shift the ICB such that part of the visible viewport is obscured without altering viewport-percentage length units, provided that the change is:

associated with the display of additional user interface required to undertake a specific action, such as a keyboard when assistance with form input is required or an address bar when the user needs to navigate or to a new location, and

temporary by design such that:

the user interface only appears when required or requested by the user, and

the additional user interface is removed when the user completes the action, dismisses it or undertakes an unrelated action.

Any other change to the ICB or visible viewport must result in a corresponding change of viewport-percentage length units.

mind-bending-forks on 23 Nov 2020

Thank you for having this discussion. I don't have anything to add. I just appreciate that some do.

mightyiam on 24 Nov 2020

👍2

It would be good to have some feedback on my input to this thread, so I/we know what to do from here. @frehner said back in October 2019 that "if someone comes up with a solution that makes the vh unit itself useful again I would be all for it!". I've made a suggestion to allow but clarify when/how the viewport/ICB can be overlaid/obscured/cut-off by the user agent. Let's call it the obscured viewport clarification suggestion for brevity. With my suggestion, browsers are guided to avoid designs that obscure/truncate/overlay what would ordinarily (e.g. without zoom) be the visible viewport unless it is temporary and for a specific purpose. This hopefully makes vh useful again for developers who wish to use it to position content, while accepting that it may be obscured on occasion by the user agent, but only temporarily/briefly. This therefore requires improvement to current mobile browser design, which, as per my previous post, sometimes leaves content cut off most of the time and without good reason. So:

Firstly, is my obscured viewport clarification suggestion a good one, is it a non-starter, or are their misconceptions/other factors for consideration that need to be ironed out? Are there other issues with vh that it does not address?
Secondly, if it is a good suggestion, then where do we go from here and what does that mean for @frehner's proposal to add a new viewport-percentage unit relating to the 'maximum chrome' scenario and his current draft text that also updates the definition of vh, especially noting that this proposal has already been approved? Various possibilities I can think of are:
- This proposal stays as is. I turn my suggestion into a new obscured viewport clarification proposal and file a new issue for it. It is understood that implications for the definition of vh are incompatible across the two proposals.
- This proposal is altered to become purely about it new unit, which is considered on its own merits and in way that does not alter the current definition of vh. I make a new 'obscured viewport clarification' proposal.
- This proposal is dropped/abandoned??? I make a new 'obscured viewport clarification' proposal.
- I work with @frehner to adjust/repurpose this proposal in some way agreed by people here?
- Something else..?

I'd also like to add that @frehner's recent thread on twitter was brought to my attention and I note that I also made several posts on here on the same day. I also note that my colleagues reviewed my first post on this thread before I posted it, and they provided feedback along the lines of "it's fair but very direct/blunt in places" and I acknowledge that I can be overly direct and blunt! So, for the record, while I don't believe I've been in any way aggressive, if I've been overly blunt/direct or just wrong about anything and caused any offence, I apologise. Also, feel free to correct me if you think I've got anything wrong. Thanks.

mind-bending-forks on 24 Nov 2020

👍1

I've observed this thread for the last week or so - things seem to have gotten weird. Your posts, @mind-bending-forks, started with indignation that browser standards didn't bend to your will or solve your problems. The sheer length of your posts makes things a bit weird because almost nobody will take the time to read them, and they don't seem to contribute to a healthy discussion about the original topic. Looking up @frehner's tweets and then posting the tweets here is quite unusual, and almost seemed like harassment to me. I think that the best path forward is to let the discussion here calm and shift back to its original topic - if it doesn't solve your problems then you can make separate proposals. I don't think this issue is the place where you'll find your answers.

joeldenning on 24 Nov 2020

😕1 👎1

@joeldenning You are entitled to your opinion that my contributions to this thread are weird, unusual and not conducive to a healthy discussion. However, I take exception to the suggestion that I have harassed or almost harassed anyone. I haven't.

If anyone would like to take the time to read and evaluate what I have contributed, which I believe to be relevant and on topic, and to engage with me on a technical level about it, then I would be happy to do so. In the meantime, I'll be taking @frehner's advice and taking a break from this for a while. Thank you.

mind-bending-forks on 25 Nov 2020

👍1

@mind-bending-forks

As I'm not a member of the w3c, I have no idea what would be better - if you were to create a new proposal and try to get the w3c's attention in that way, or having the conversation here. I personally am open to either way and will follow the conversation wherever it is (if you make a new issue, please link it here so I can follow it!)

In any case, no matter what happens, may I suggest something that _may_ help your proposal a bit? (again, as I'm not a member of the w3c, I can't guarantee anything, but I hope that my suggestion can help your ideas progress)

Perhaps you could follow the template I used for my first post here for your proposal? If you were to do it that way, it makes it easier for anyone to drop in, take a look at what's being proposed, and comment on it - even if they haven't been following the conversation so far. I think that would increase the chances that it gets discussed.

It may help to take some time on it too - write it down, wait some time, and proof read it / clean it up. I did that 3/4 times on each of my proposals and I find it has really helped me cement what I'm proposing and what's just superfluous and can be removed.

Maybe you could even include another section that talks about how it may affect websites that (for better or worse) expect the current behavior of vh and if they would need to be changed in any way - it's always good to be thinking about how a proposal may affect existing websites, even if you're correcting a bug. (see Javascript's typeof null for reference haha)

Anyway, again, you don't need to do that. I just have found some measure of success by doing it that way and I would love to understand your proposal - and see it get commented on.

Sidenote: regarding my tweets you referenced earlier, it's unfortunate that you came away with the impression that I was directing them at you. For clarity, I wasn't, though the timing of it may have appeared that way. In any case, I hope we can move on from that discussion and just focus on the proposal here. 🙂

frehner on 30 Nov 2020

👍5

@frehner Thank you very much. I really appreciate this excellent advice.

As it turns out, last weekend I started drafting an article, attempting to draw together what I have come to understand - which is still evolving - into something that is hopefully more coherent and easy to follow than the disparate posts I have made in this thread. It currently has sections on:

background and technical details;
what the problems are that need addressing with examples (and animated(!) illustrations - which I think is important for understanding what is happening here and not talking at cross-purposes);
this proposal;
my proposed way forward; and
implications for the CSS specification and browsers.

One of my colleagues has provided feedback on an initial draft already. Pulling it together like that has been a good experience for me so far. Your suggestion to cover how the new proposal may affect websites - for better or for worse, is a good one, and this is something I think I could expand more on in my current draft. So, I plan to get that finalised and posted for people to read and comment/provide feedback on if they so wish. I can't be definite about timescales because I'm fitting this in around family and work commitments as I'm sure everyone is, but maybe sometime next week. Then I'll follow your advice and attempt to distil that down into the something far more succinct that follows the proposal template you have used here and file a new issue.

Sidenote: I honestly wasn't sure whether your tweets were directed at me, provoked in part by me, or unrelated, but I didn't want to just ignore them and take the risk that I'd inadvertently contributed. I'm glad that doesn't appear to have been the case, and I hope that you've been able to take the step back that you mentioned and hope that it has helped.

mind-bending-forks on 1 Dec 2020

👍2

As you can see, I've just submitted a new proposal: #5777. This proposal references an article documenting my current understanding and point of view:

https://mind-bending-forks.github.io/css-viewport-percentage-length-units/

Feedback is welcome.

mind-bending-forks on 10 Dec 2020

👍2

Csswg-drafts: [css-values-4] Add vhc value

Latest info

Background

Proposal

Advantages and Drawbacks

Alternative Proposals

Current Workarounds

Unrelated

Most helpful comment

All 82 comments

`vhc`

`env(inset-collapsable-height)`

`vh-sizing`

Proposed solution

Hiding the address bar when not needed

Showing the address bar when needed

Re-hiding the address bar on a loaded page

Conclusion

Chrome for Android

Web Page A - Normal Browsing

Web Page A - Private Browsing

Web Page B - Normal Browsing

Web Page B - Private Browsing

Comment on Chrome for Android behaviour

Firefox for Android

Web Page A - Normal Browsing

Web Page A - Private Browsing

Web Page B - Normal Browsing

Web Page B - Private Browsing

Comment on Firefox for Android behaviour

Related issues