[css-env-1] list of predefined variables

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 from the top of the viewport to the title-safe content area.
safe-area-inset-right: Inset, as a from the right of the viewport to the title-safe content area.
safe-area-inset-left: Inset, as a from the left of the viewport to the title-safe content area.
safe-area-inset-bottom: Inset, as a from the bottom of the viewport to the title-safe content area.

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

[jonjohnjohnson]

Could we get a env variable to access the possible UI's scrollbar size (width/height)? For designs to work within/around?

• [css-values] Should viewport units still depend on scrollbar width for overflow:scroll? #1766 (comment)
• [css-overflow] overflow: Consider reserving space for scrollbars with some property #92 (comment)

Something like env(scrollbar-width) that is the initial length or length computed from the auto value of the scrollbar-width property?

[Malvoz]

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

[jonjohnjohnson]

@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 current iOS mobile, safari shrinks both the top and bottom nav, while chrome only has the top nav to shrink.

.smallest-viewport-height { height: calc(100vh - env(viewport-nav-resize)); }

Edited

[nhoizey]

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

[jonjohnjohnson]

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.

#1693 (comment)