[css-env] Add environment variables defined in WebKit

[SebastianZ]

In #6729, @heycam was tasked to provide a list of environment variables WebKit implements, which should be standardized. @tabatkins asked for that list to be able to publish a FPWD of CSS Env 1.

From reading the related code, it looks like the missing environment variables are:

• fullscreen-inset-top
• fullscreen-inset-left
• fullscreen-inset-bottom
• fullscreen-inset-right
• fullscreen-auto-hide-duration

@heycam, @fantasai Should those be added to the spec.? Are there any other variables not listed here?

Sebastian

[nt1m]

Maybe @jernoble or @eric-carlson have thoughts

[bramus]

In #6729 (comment), @smfr confirmed that the extra envvars mentioned at the start of this thread is correct.

AFAICT these are not documented anywhere. The only reference I could find was a mention in this “What’s new in Safari and WebKit” PDF from WWDC 2018. There is no video that accompanies this deck (or at least I could not find one at https://developer.apple.com/videos/wwdc2018/):

UPDATE: Did find #2871 here in the repo (which didn’t show up through a Google search). These envvars were discussed back in the day, but there was no resolution to actually add them.

[emilio]

But the safe-inset- variables already update on fullscreen, so why do we need these?

[bramus]

I wasn’t even aware these (undocumented) fullscreen-* envvars existed before I read this issue … which lead me to assume that usage is practically inexistent. If the safe-inset-* ones offer the same functionality (which they do?) then perhaps we should just drop these indeed.

[smfr]

The fullscreen-inset-* env vars are different from safe-area-inset-* in that they represent areas that contain UA-supplied UI in the fullscreen presentation, such as the close button, picture-in-picture button etc. They were intended for sites like YouTube to be able to place titles or captions avoiding this UA-supplied UI, while the video still covers the area underneath.

Having said that, we are not aware of any sites that have adopted these, so we are open to either renaming, or unshipping them.

[sashafirsov]

@bramus ,

I wasn’t even aware these (undocumented) fullscreen-* envvars

perhaps it is not about someone's familiarity but about approach consistency?

If the API exposes some data, those should not be cherry-picked but driven by some kind of schema. In this case a property map.