[csswg-drafts] [css-env-1] Specify viewport environment variable property propagation into subframes (#10506)

flackr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-env-1] Specify viewport environment variable property propagation into subframes ==
[css-env section 2](https://drafts.csswg.org/css-env/#environment) defines several viewport geometry environment variables. These make sense when used in the the top frame, but I think we should specify when or how these are propagated to sub frames. I created a demo showing a typical example of a subframe using a safe area to avoid drawing into the unsafe region, where you can see that on iOS this leads to it insetting from the frame box:

![Image_20240626_141411_649](https://github.com/w3c/csswg-drafts/assets/366761/d899967a-55c3-4c59-84c4-15da67682328)
In the above screenshot, the phone is in landscape. The camera notch occupies the left of the screen and the application switcher bar occupies the bottom leading to those safe areas. The safe area on the right is presumably added for symmetry.

It makes sense that the root frame has those safe areas but the sub frame is positioned by the root frame in a safe area so shouldn't have any safe area. It is possible that the root frame has positioned the sub frame outside of the safe area edges but as a default behavior I don't think we should give the sub frames the safe area.

If you make the subframe fullscreen, then it makes sense that we should begin giving it a safe area since it will draw to the edges of the screen despite its normal placement in the root frame.

TLDR, I'm proposing we specify that for these screen environment variables, subframes should only get their value when they are fullscreen. The main frame should always have the safe area set even when sub frames are full screen, as it does occupy the full screen space and should also avoid the safe area.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10506 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 26 June 2024 18:53:08 UTC