- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Oct 2019 16:18:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Add vhc value`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Add vhc value<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4329<br> <fantasai> https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html<br> <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<br> <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.<br> <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.<br> <dael> fantasai: Need to solve the problem. Multiple options, could take multiple of them.<br> <dael> fantasai: Want to hear what others thing<br> <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.<br> <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<br> <dael> AmeliaBR: Original posted suggested alternate unit proportional to the smaller viewport<br> <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<br> <dael> fantasai: Problem with that is current keyword is the safer value<br> <fantasai> s/Problem/Advantage/<br> <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<br> <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<br> <dael> smfr: I don't htink we should derail with keyboard. What you described florian is iOS where it does not change layout height<br> <dael> florian: If you think it's separate let's keep that out<br> <dael> smfr: Did any proposals include a unit that changes value when chroma hides? vh that changes<br> <dael> smfr: It's an option<br> <dael> TabAtkins: From author feedback they do not want that becaues layout jiggle while it moves<br> <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.<br> <dael> smfr: I'm all for avoiding layout jiggle. Seems that pages may be designed such that chrome disappears when you're at bottom<br> <dael> florian: I think it would be weird to build a page that way<br> <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<br> <jensimmons> +1 to everything should match<br> <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<br> <dael> smfr: Do we know if Andriod has a similar behavior to iOS where 100vh is the chrome hidden state?<br> <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<br> <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<br> <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<br> <AmeliaBR> s/AmeliaBR/jensimmons /<br> <dael> astearns: Anything else on this to discuss or do we have jensimmons work on the use cases to consider?<br> <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<br> <dael> astearns: Anything else people want added to discussion?<br> <dael> astearns: I think smfr list of things that should be eq is excellent<br> <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<br> <dael> fantasai: Probably 2 pairs of units would be cleaner and less likely to result in accidental errors<br> <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<br> <dael> AmeliaBR: Good arguments.<br> <dbaron> Using both at the same time is probably very hard to do correctly, though.<br> <dael> AmeliaBR: Lots of options and use cases. Getting through pros and cons for each sounds sensible<br> <dael> astearns: Let's continue in GH. jensimmons I'll assign it to you?<br> <dael> jensimmons: Okay<br> <dael> astearns: We'll discuss again on the call when it's at a good point.<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-545522799 using your GitHub account
Received on Wednesday, 23 October 2019 16:18:10 UTC