- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2020 12:55:38 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <fremy> Topic: New viewport unit<br> <RossenTheReal> github:https://github.com/w3c/csswg-drafts/issues/4329<br> <fremy> jensimmons: we have discussed this before<br> <fremy> jensimmons: we are trying to solve the issue on mobile where the viewport changes when you start scrolling<br> <fremy> jensimmons: (as the bottom bar retracts)<br> <fremy> jensimmons: you can work around this in javascript, but it's not possible to do in css<br> <fremy> jensimmons: proposal also includes taking into account the appearance of the keyboard<br> <fremy> florian: I think the top bar sometimes disappear as well in some OSes<br> <fremy> jensimmons: ah, good point<br> <fremy> jensimmons: and those things can keep changing<br> <fremy> jensimmons: (also, similar to the issue with vw and scrollbars)<br> <fremy> jensimmons: (maybe it's a different issue, but it's still good to keep it in mind)<br> <fremy> jensimmons: I am afraid redefining vh/vw might be too late by now, because authors have corrections<br> <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<br> <fremy> jensimmons: so we should provide all the units to authors, and it's on them to take a look<br> <fremy> jensimmons: at performance<br> <fremy> florian: so, we would have a unit that would represent the initial containing block?<br> <fremy> jensimmons: yes, this new unit would be static, and not change when the chrome changes<br> <fremy> jensimmons: VHC would be the same but with the chrome maximized<br> <florian> q+<br> <fremy> jensimmons: but we could also use an environment variable<br> <fremy> proposal summarized below:<br> <fremy> <link><br> <jensimmons> https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485<br> <myles> q+<br> <fantasai> s/<link>/https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-547551485/<br> <fremy> dbaron: I just wanted to ask, do we want to talk about keyboards when we talk about maximized chrome?<br> <fremy> jensimmons: I don't think so, it would only include the normal chrome<br> <fremy> jensimmons: but an environment variable might be better to handle the keyboard case<br> <RossenTheReal_> q?<br> <Zakim> dbaron, you wanted to ask if that includes virtual keyboards<br> <RossenTheReal_> ack dbaron<br> <fremy> TabAtkins: most of the times, you don't want your footer to reduce space when the keyboard appears<br> <fremy> TabAtkins: because content space is already tiny<br> <fremy> jensimmons: but some things might want to snap etc...<br> <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<br> <fremy> iank_: for example, adding an additional keyboard row<br> <fremy> dbaron: but switching keyboard would change the height of keyboards sometimes<br> <fremy> iank_: and some settings can cause the number bar to appear or not above the letters<br> <dbaron> s/keyboard/keyboard (between English and Chinese)/<br> <dbaron> s/settings/form input types/<br> <TabAtkins> q+<br> <RossenTheReal_> ack florian<br> <fremy> florian: I am confused at the idea that the animation concept would work<br> <fremy> florian: how do you switch between the values on scroll?<br> <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<br> <fremy> fantasai: because some units are used to compute font size etc and relayout during scroll sounds not great in general<br> <fremy> fantasai: environment variables are better because it makes it more clear it's gonna change dynamicly<br> <fremy> fantasai: but the units are useful for the static initial position case<br> <astearns> for the minutes, there have been multiple call-outs thanking @frehner for the very clear issue opening and summaries<br> <fremy> florian: I think that answers my question<br> <fremy> florian: but if we have both, I don't think we need the other viewport units<br> <jfkthame> q+<br> <RossenTheReal_> ack myles<br> <fremy> myles: I think I might repeat a bit but I do agree the two units don't work<br> <fremy> myles: so we add the dynamic thing<br> <fremy> myles: but then why do we need the second unit we currently dont have?<br> <myles> q+<br> <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 ...<br> <fremy> ... to use the concept of minimalized and maximalized chrome in layouts<br> <fantasai> s/not great in general/not great for users, and also not great for performance/not great for users, or for performance/<br> <jensimmons> q?<br> <fremy> florian: an article for the top banner which try to cover the screen as you open the site<br> <fremy> florian: but you don't want that banner to resize when you scroll or open a keyboard<br> <fremy> florian: and you can't solve that with the env() and the one unit<br> <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<br> <fremy> TabAtkins: I strongly agree that we can use both<br> <fremy> TabAtkins: I would have objected to only add the static ones, but if we have both I am fine<br> <fremy> fantasai: we don't have a high demand for the keyboard one in general<br> <fremy> fantasai: and we can't know in advance the size of the keyboard<br> <TabAtkins> ack TabAtkins<br> <fremy> fantasai: so I think that use case should only be covered by the dynamic env() unit<br> <fremy> jfkthame: should we think about privacy<br> <fantasai> fremy: we already have that info exposed via JS<br> <dbaron> s/privacy/privacy effects of exposing the size of the keyboard/<br> <fremy> jfkthame: (because the height of the keyboard might reveal what language the user speaks)<br> <RossenTheReal_> ack jfkthame<br> <bkardell_> q+<br> <fremy> myles: we could also solve all of this with javascript<br> <fremy> myles: with an event that say "the chrome is stable now, do yourcomputations now"<br> <RossenTheReal_> ack myles<br> <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<br> <florian> q+<br> <fremy> myles: (which is unfortunate)<br> <RossenTheReal_> ack bkardell_<br> <fremy> bkardell_: I'm not entirely clear on what the static thing brings, can someone resummarize?<br> <myles> s/could also solve/already can solve/<br> <fremy> TabAtkins: vh is the full height, never reduce<br> <fremy> TabAtkins: vhc would be the same, but without the bars<br> <fremy> bkardell_: the vh unit does change<br> <fremy> jensimmons: only if the window is resized, but not as you scroll<br> <RossenTheReal_> q?<br> <fremy> bkardell_: but, you agree they are not purely static, right?<br> <myles> q+<br> <fremy> jensimmons: yes, but what we mean by static, is that it's static as you scroll<br> <fremy> jensimmons: it changes when we need to relayout everything<br> <fremy> jensimmons: but it doesn't change otherwise<br> <fremy> myles: comment about vhc not being useful for one example jensimmons showed on the powerpoint<br> <fremy> jensimmons: good question; both use cases could be fine for designers<br> <fremy> jensimmons: but at least on desktop vh and vhc it seems the units would always match<br> <RossenTheReal_> q?<br> <jensimmons> example: https://labs.jensimmons.com/2016/examples/coversheet-2.html<br> <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<br> <fantasai> The goal is to see the entire photo, and just below the fold the article<br> <fantasai> scrolling should not change the size of anything on the page, just scrol<br> <jensimmons> q?<br> <jensimmons> q+<br> <fantasai> If the smaller measurement was used, part of the article would show above the fold<br> <fantasai> This might not be wanted<br> <fantasai> s/fold/fold when the bottom bar is retracted/<br> <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<br> <fantasai> so using the larger measurement (for retracted bars) would be a problem<br> <fremy> RossenTheReal_: let's timebox this for another ten minutes<br> <fremy> florian: I think there is another layer of complexity in this story<br> <fremy> florian: at least in the keyboard case<br> <fremy> florian: what if the keyboard is semi-transparent above the content<br> <fremy> RossenTheReal_: actually one of the things I wanted to mention<br> <fremy> RossenTheReal_: we had a similar issue with Windows (8?)<br> <fremy> RossenTheReal_: the keyboard would not change the appwindow size on the platform<br> <fremy> RossenTheReal_: sometimes the keyboard was not even transparent, it occluded the app<br> <fremy> RossenTheReal_: but we needed to animate the bottom bar of the app to stay above the keyboard<br> <fremy> RossenTheReal_: and we had a special "position" value to achieve that<br> <fremy> RossenTheReal_: but I don't know if having the units would work, because it would be out of sync<br> <fremy> florian: but we can have the value matches the keyboard all the time<br> <fremy> florian: but maybe there are good use cases for both, I'm not sure<br> <hober> q+<br> <fremy> jensimmons: I don't think we want to debate this issue too much<br> <fremy> jensimmons: I guess there are use cases for all<br> <RossenTheReal_> q?<br> <RossenTheReal_> ack florian<br> <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<br> <fremy> jensimmons: I understand but what a viewport means from the implementer is their question<br> <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<br> <fremy> florian: but if you want to coordinate static positions, it's difficult because things would get out of sync<br> <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<br> <fremy> dbaron: but when the keyboard is there<br> <fremy> dbaron: and I suspect that this might be right, we don't need to worry about hypotheticals about the keyboard<br> <fremy> dbaron: as long as you can react as the keyboard opens<br> <fantasai> s/after the keyboard/after the keyboard is added/<br> <fantasai> s/is there/is not there/<br> <fantasai> +1 to dbaron<br> <fremy> emilio: fixed position elements used to respond to the keyboard<br> <fremy> emilio: and that had complications very soon<br> <fremy> emilio: do we want env() units to have the same issues?<br> <fremy> RossenTheReal_: you mean visual vs .... viewport?<br> <RossenTheReal_> q?<br> <fremy> TabAtkins: I suppose we want visual<br> <RossenTheReal_> ack myles<br> <TabAtkins> Specifically, I think we want this height to match the height of a fixpos with top:0; bottom:0;<br> <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<br> <fremy> myles: when we tried to ship to disappearing bars, we realized there are some problems, and we might fix them at some point<br> <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<br> <myles> s/browsers work today/browser chrome works today/<br> <RossenTheReal_> ack jensimmons<br> <fremy> jensimmons: fantasai said we might want two env() variables, what are they?<br> <myles> s/might fix them/might want to fix them/<br> <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<br> <emilio> q+<br> <myles> s/we ended up/the browser community ended up/<br> <fremy> fantasai: I think the keyboard case seems less urgent to solve<br> <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<br> <fremy> emilio: replying to tab about the visual viewport thing<br> <fremy> emilio: part of the reason we don't update them is performance<br> <fremy> emilio: and this would kill that performance optimization<br> <fremy> emilio: if you want the visual viewport behavior (fixedpos-0-0) you also need a width unit<br> <fremy> emilio: (because when you zoom you change that as well)(<br> <emilio> ack emilio<br> <fremy> jensimmons: it seems to me that we are talking about a vh unit that's a fixed unit based on the maximized space<br> <fremy> jensimmons: vhc would be the minimize space, but also static<br> <fremy> jensimmons: and the dynamic variable would be whatever it is right now, and yes that would would change 60fps possibly<br> <RossenTheReal_> q?<br> <fremy> jensimmons: we will educate<br> <RossenTheReal_> Zakim, close queue<br> <Zakim> ok, RossenTheReal_, the speaker queue is closed<br> <fremy> jensimmons: but maybe we can make a vhk unit to care about the keyboard later<br> <fremy> jensimmons: "question mark, question mark, question mark" (just thinking out loud)<br> <fremy> jensimmons: and then there might be another set which is, give me the space available<br> <fremy> jensimmons: even if it's behind a keyboard (or not)<br> <RossenTheReal_> ack hober<br> <fremy> hober: to reply to fantasai list of things, the values is orthogonal<br> <fremy> hober: but for the use case to know about the keyboard, one of the use case it to add things above the keyboard<br> <fremy> hober: and that usecase should probably be addressed in html and javascript, maybe not css<br> <fremy> hober: for example, we thought about some way to add custom buttons for the touch bar in html/js<br> <fremy> hober: and it seems a more natural fit than trying to emulate this with positioning with css<br> <fremy> hober: so, is there another use case?<br> <fremy> astearns: when the textbox is focused, move it right above the keyboard<br> <fremy> fantasai: you can do that with scroll-snap<br> <fremy> fantasai: because it will snap to the viewport<br> <fremy> jensimmons: so, are you arguing it wouldnt be required to do this math with env variables<br> <bkardell_> astearns: the grey beard seems kind of a give away of that though?<br> <RossenTheReal_> ack fantasai<br> <fremy> fantasai: my proposal is the two static sizes (minimized/maximized chrome) and the dynamic one where you report the current size<br> <fremy> fantasai: vh should probably be the maximized chrome (smaller measurement)<br> <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<br> <fremy> fantasai: it's not as pretty if you truly wanted to fit<br> <fremy> TabAtkins: that's a change of behavior<br> <fremy> fantasai: chrome folks said they would have loved to change, but webkit did the other way around<br> <fremy> TabAtkins: that was a long time ago, I don't think we could switch without compat<br> <fremy> fantasai: more breaking than we would fix?<br> <fremy> hober: yes<br> <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<br> <fremy> hober: I'd be happy to reject the fourth one and reopen later<br> <fremy> jensimmons: actually the issue doesn't cover the fourth one anyway, so not even needed<br> <fremy> RossenTheReal_: so, are we reaching a consensus on the two static + one dynamic value?<br> <fremy> jensimmons: I think so<br> <fremy> fantasai: also, we would also need to add the symetric values for vhi and vhb<br> <fremy> hober: I think the issue is that it would be a lot of similar units<br> <fremy> hober: I'd rather something longer that's more clear<br> <fremy> fantasai: yeah but that's unfair because vh is short, then if you want to write good code you need to write more<br> <fremy> fantasai: for instance we already have some confusion with vmin<br> <fremy> jensimmons: can we resolve on the concepts but not the name?<br> <fremy> myles: rossen said that the symmetrical values would be needed, but in practice we wouldn't have different values in any browser<br> <fremy> fantasai: the viewport units are vh, vw, vmin, vmax<br> <fremy> fantasai: all of these can potentially map to vh<br> <fantasai> s/vmax/vmax, vi, vb/<br> <fremy> dbaron: I am not convinced that vmin needs this<br> <fremy> fantasai: why would you exclude them<br> <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<br> <dbaron> s/vmin needs this/vmin and vmax need this new feature/<br> <fremy> RossenTheReal_: in tablet mode on windows, there are different chrome you can trigger when you swipe etc...<br> <fantasai> s/At that point/fantasai: At that point/<br> <fremy> RossenTheReal_: things like notifcation bars and whatnot<br> <fremy> RossenTheReal_: in tablet mode, all of the windows are always maximized<br> <fremy> RossenTheReal_: and the bars can appear on top of the content<br> <fremy> RossenTheReal_: (but these bars haved fixed size value known in advance)<br> <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<br> <fremy> RossenTheReal_: so for us, vw sounds useful<br> <fremy> emilio: if we don't want things that are sized with them to be affected by zoom<br> <fremy> fantasai: the vh and the new unit and the initial containing block should all behave the same way<br> <fremy> fantasai: whether the browser affect the all three the same way, they can do whatever they want<br> <fantasai> s/whether/as long as/<br> <fremy> RossenTheReal_: are we ready to make a resolution?<br> <fremy> RossenTheReal_: can we resolve on the keyboard thing?<br> <fremy> jensimmons: not necessary<br> <fremy> RossenTheReal_: is there consensus on vhc? (besides the name)<br> <fremy> fantasai: plus the variants<br> <fremy> RossenTheReal_: plus the variants (vi/vb/...)<br> <fremy> RossenTheReal_: any objection to this set of units?<br> <fremy> dbaron: not counting scrollbars?<br> <fremy> emilio: not counting scrollbars<br> <fremy> RossenTheReal_: let's kick that can down the road, we can rediscuss later<br> <fremy> RossenTheReal_: but I'm not hearing any objection<br> <fremy> RossenTheReal_: so let's resolve<br> <fremy> RESOLVE: adding the set of viewport units (vhc and symmetrical values)<br> <RossenTheReal_> RESOLVED: Add a set of viewport units (vhc for ex.) that reflect the size of the layout viewport less all UA UI<br> <fremy> RossenTheReal_: the second question, do we need to provide the events / env variable that allows to transition between them<br> <fremy> fantasai: I think the consensus was to have the dynamic full size<br> <fremy> florian: we can also consider giving differences between the dynamic and full one<br> <fremy> jensimmons: that's simpler to just say that env() variable is exactly like vh but it doesn't stay static<br> <fremy> jensimmons: and the number is a live measurement of the space, instead of a difference<br> <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.<br> <fremy> florian: I don't disagree but I am unsure it answers my question, but ok let's move on<br> <hober> dbaron: yeah.<br> <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<br> <fremy> jensimmons: (done in javascript right now)<br> <fremy> jensimmons: and I think that use case is important<br> <fremy> hober: it's a bummer that we have to do relayout during scroll<br> <hober> s/we have to/we'd have to/<br> <fremy> myles: there is an alternative that doesn't do that (myles to expand, didn't catch all things)<br> <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.<br> <fremy> jensimmons: vh doesn't already change for performance<br> <fremy> jensimmons: and that the new env() variable would only be used in cases where it's needed<br> <fremy> jensimmons: so the perf impact would be lower<br> <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<br> <fremy> emilio: also, it's unfortunate because if you use it on the body because then you still need to relayout everything<br> <fremy> RossenTheReal_: this example works with position:sticky<br> <fremy> fantasai: this case yes, but it might not always be the case<br> <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<br> <fremy> jensimmons: I am sure there are use cases<br> <fremy> jensimmons: I could gather more evidence if needed<br> <fremy> RossenTheReal_: I think we should probably get another example, but I think we should focus on answering the question at hand<br> <fremy> RossenTheReal_: do we agree to add the dynamic unit?<br> <fremy> jensimmons: We need to know if this is something we can implement<br> <fremy> myles: yes, if you can do in js<br> <bkardell_> q+<br> <fremy> hober: but it's really problematic that we would need to do layout in scrolling<br> <fremy> hober: even if we add this, this would stay janky<br> <fantasai> http://inkedblade.net/viewport-test.html<br> <bkardell_> q-<br> <fremy> hober: so I don't think we should do this<br> <fremy> hober: but we can have smooth perf with position:sticky<br> <fremy> jensimmons: but there are other examples, if you need to the height to be considered<br> <fremy> RossenTheReal_: there's position:fixed for that<br> <fremy> emilio: yes<br> <fremy> TabAtkins: but there are cases where you only want to show it in some context<br> <fremy> TabAtkins: and position:fixed make it visible at all times<br> <dbaron> dbaron: does position:sticky help with that?<br> <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?<br> <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<br> <hober> s/this would stay janky/this would be an attractive nusiance. the behavior would be just as janky as js./<br> <fremy> RossenTheReal_: also if you have a "fake fullscreen" where an experience takes the full size of the viewport<br> <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<br> <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<br> <fremy> RossenTheReal_: you can of course do that with js, and we ask the question whether we want a better solution<br> <fantasai> btw, anyone with Safari mobile able to load http://inkedblade.net/viewport-test.html ?<br> <fremy> RossenTheReal_: I think we should probably defer, and see more use cases<br> <fremy> RossenTheReal_: except if we all agree<br> <fremy> RossenTheReal_: but the points on perf and layout on scrolling remain<br> <astearns> I see blue taller than yellow, fantasai<br> <fremy> fantasai: I pasted a testcase<br> <fremy> fantasai: there is no interop in a lot of cases<br> <fremy> emilio: there is been a lot of effort from us to match Chrome/Safari<br> <fremy> emilio: so I'm surprised we don't match<br> <fantasai> Safari also showing 100% and 100vh not being equivalent<br> <fremy> RossenTheReal_: what is showing, I don't have a phone?<br> <fremy> florian: 100% and 100vh don't always match<br> <fremy> florian: in Chrome<br> <fremy> RossenTheReal_: but that's for the previous discussion then?<br> <fantasai> It's an open point we need to resolve<br> <astearns> q?<br> <fremy> RossenTheReal_: let's get back on track<br> <fremy> RossenTheReal_: can we resolve now, or do we want to defer?<br> <fremy> jensimmons: I think we should think about this more<br> <fremy> jensimmons: so let's table this for now<br> <fremy> fantasai: also, I think we should have a discussion about the compat<br> <fremy> fantasai: should 100% and 100vh match?<br> <fremy> hober: I don't think we can resolve this<br> <fremy> fantasai: the spec doesn't have a concept to allow them to diverge<br> <fremy> hober: there is a lot of content designed for mobile<br> <fremy> hober: and they rely on webkit/blink actually<br> <fremy> fantasai: I would have loved implementations to file an issue<br> <fremy> fantasai: because right now the spec doesn't match and we were not aware<br> <astearns> +1 to annoyance at not getting an issue from (multiple!) devs breaking spec behavior<br> <fremy> heycam: but since we aim to match gecko and blink/webkit, I think yes we would want to update the spec<br> <fremy> <br type=lunch><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-577169195 using your GitHub account
Received on Wednesday, 22 January 2020 12:55:41 UTC