This is a follow up to https://drafts.csswg.org/css-env-1/#issue-2732e813
So far we have the safe area variables:
safe-area-inset-top: Inset, as a
safe-area-inset-right: Inset, as a
safe-area-inset-left: Inset, as a
safe-area-inset-bottom: Inset, as a
Also Safari Tech Preview 52 has shipped both fullscreen-inset-top and fullscreen-auto-hide-delay but there is no documentation.
issues/1693 mentions the following too but afaik these haven't shipped anywhere:
user-font-size: User's requested font size
user-background-color: User's requested background color
user-foreground-color: User's requested foreground color
Could we get a env variable to access the possible UI's scrollbar size (width/height)? For designs to work within/around?
Something like env(scrollbar-width)
that is the initial length or length computed from the auto
value of the scrollbar-width
property?
Would be nice to have access to browsers navigational interface (e.g. bottom-screen navigation buttons) as displayed here: https://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html
@Malvoz The difference in the heights of the initial containing block ("smallest possible viewport") and the visual viewport? https://developers.google.com/web/updates/2016/12/url-bar-resizing
In at least iOS, safari shrinks the top and bottom nav to while chrome only has the top nav to shrink.
.smallest-viewport-height { height: calc(100vh - env(viewport-nav-resize)); }
_Edited_
The usage example in WebKit's proposal doesn't make sense IMHO, reducing its attractiveness for developers, because :root
's default font size is already set to the user's preferred font size, or the browser's default one if the user didn't change anything.
Let's say we want to set the font size of an element deeply nested in the DOM tree to 1.2x the user preferred font size.
We could use rem
, but we sometimes work on CSS code for components that are included in pages we don't manage, which might have set a different font size on :root
or html
.
We could use font-size: medium;
, but it looks like it's not safe, and we would have to nest our element in a parent to get the 1.2x size factor.
So, if we want to make sure our component is accessible (never sets a font size below the one the user asked for), and can set a font size that is a factor of the user preferred font size, env(user-font-size)
would be the right solution:
.my-nested-element {
font-size: calc(1.2 * env(user-font-size));
}
What @nhoizey said, as well as how the env(user-font-size)
will play as an initial value for use in media queries, regardless of a :root
scoped declaration setting the rem
, which will clean up my use of zoomable/responsive em
values in current media queries.
https://github.com/w3c/csswg-drafts/issues/1693#issuecomment-385124733
Most helpful comment
@Malvoz The difference in the heights of the initial containing block ("smallest possible viewport") and the visual viewport? https://developers.google.com/web/updates/2016/12/url-bar-resizing
In at least iOS, safari shrinks the top and bottom nav to while chrome only has the top nav to shrink.
.smallest-viewport-height { height: calc(100vh - env(viewport-nav-resize)); }
_Edited_