[css-values-4] Add vhc value

frehner commented 5 years ago

Latest info

Added lvh, svh, dvh, lvw, svw, and dvw units.

See https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668 and https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-880040513 for more details. 🎉

Original content below:

Background

vh is defined as Equal to 1% of the height of the initial containing block. Perhaps the current behaviour^{1 2} could also be defined as

Equal to 1% of the height of the initial containing block with user agent chrome minimized.

In other words, on devices where the browser chrome changes size (e.g. mobile devices), 100vh is actually larger than the viewport when the browser chrome is maximized, and thus overflows.

A brief history of the vh unit is outlined here https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-542420036

Proposal

vhc (c = "with chrome", but it could be something else) could be defined as

Equal to 1% of the height of the initial containing block, with user agent chrome maximized

On devices without a changing chrome size (e.g. desktop devices), 1vh === 1vhc.

Advantages and Drawbacks

Pros and Cons list for each proposal

Original content of this section:

A drawback of vh units is that content will be cut off when (1) you load a page and (2) when you scroll upwards, while the content fits when you scroll down and the chrome is minimized.

The vhc unit would be the inverse: content would fit the page when (1) you load the page and (2) when you scroll upwards, but you would see additional content (or whitespace, depending on the implementation) when the chrome is minimized.

It also would provide a better experience than vh for games and other full-screen content that doesn't or shouldn't scroll at all.

In the end, this proposal does not completely solve the issue of 1vh needing to be different values at different times. However, it does at least give the developer a choice in which value that they want to use.

(For what it's worth, my personal preference is that I would end up using vhc units for responsive designs, because I would rather have additional content visible or some whitespace added, rather than have content cut off and not visible.)

Alternative Proposals

And a breakdown of the pros and cons of each proposal so far

Current Workarounds

As it stands, web developers that want to have a full-height website are either reliant on javascript ^{1 2 3} to get vh units to not cut off content, or just tend to avoid ¹ using vh units altogether.

Unrelated

This is my first time proposing, so if I did something wrong or need to improve something please let me know! Thank you for your patience. :)

frehner commented 5 years ago

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

fantasai commented 5 years ago

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.

rachelandrew commented 5 years ago

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?

frehner commented 5 years ago

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.

rachelandrew commented 5 years ago

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.

frehner commented 5 years ago

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.

tabatkins commented 5 years ago

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 commented 5 years ago

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.

AmeliaBR commented 5 years ago

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.

frehner commented 5 years ago

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?

tabatkins commented 5 years ago

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?

frehner commented 5 years ago

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.

AmeliaBR commented 5 years ago

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.

frehner commented 5 years ago

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

hiikezoe commented 5 years ago

* 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

bokand commented 5 years ago

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.

frehner commented 5 years ago

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 commented 5 years ago

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.

bokand commented 5 years ago

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))

frehner commented 5 years ago

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 commented 5 years ago

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.

fantasai commented 5 years ago

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.

frehner commented 5 years ago

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.

css-meeting-bot commented 5 years ago

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.

frehner commented 5 years ago

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.

emilio commented 5 years ago

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.

frehner commented 5 years ago

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?

emilio commented 5 years ago

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... :)

tabatkins commented 5 years ago

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?

frehner commented 5 years ago

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

tabatkins commented 5 years ago

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?

frehner commented 5 years ago

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 commented 4 years ago

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

frehner commented 4 years ago

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 commented 4 years ago

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 :)

css-meeting-bot commented 4 years ago

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>

frehner commented 4 years ago

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.

astearns commented 4 years ago

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.

frehner commented 4 years ago

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?

astearns commented 4 years ago

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.

svgeesus commented 4 years ago

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.

frehner commented 4 years ago

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?"

w3c / csswg-drafts