[css-env] safe-area-insets-* for embedded document by iframe

[makotokato]

safe-area-insets-* is the defines for visible rectangle such as cutout support. But I guess that it is unclear for embedded document by iframe.

• Chrome seems to be 0 in embedded (child) document by iframe.
• Safari seem be same value for parent document and embedded (child) document.

What correct behaviour for embedded document?

parent

...
<meta name="viewport"
  content="width=device-width, initial-scale=1.0, viewport-fit=cover">
<style>
body {
       padding: 10px;
	margin: 0px;
}
iframe {
	padding: 0px;
	margin: 0px;
	border: none;
}
</style>
<iframe width="100%" height="100%" src="child.html"></iframe>
...

child / embedded document

...
<style>
#content {
  padding-right: env(safe-area-inset-right);
  padding-left: env(safe-area-inset-left);
  padding-top: env(safe-area-inset-top);
  padding-bottom: env(safe-area-inset-bottom);
}
</style>
<div id="content">
...

[upsuper]

... and should they change based on where the iframe is?

[emilio]

... and should they change based on where the iframe is?

No, that sounds like a straight-forward cross-origin information leak.

[upsuper]

Yes, that sounds like a cross-origin information leak, but I can imagine that there are use cases for that. For example, certain site may want to have an iframe taking the whole viewport and interact with it somehow.

I'm thinking that maybe the parent document should be able to control the safe-area-insets-* of its child to provide more flexibility and possibilities, e.g. website can embed third-party media player with some inset controls provided from the parent, or they can embed an iPhone simulator with content inside an iframe.

Since environment variables are currently only exposed via CSS, it would probably be a good idea to also do such control via CSS, for example, maybe we can provide a set of properties for iframe just following the same names as the environment variables, and the value would be applied into the iframe for them.

WDYT?

[emilio]

Seems like that could be used as a somewhat-sophisticated postMessage... Not sure, it seems nice and there are other use-cases for such things, but a bit scared about the implications of the receiver of the properties being able to run script to read them and react to them...

Anyhow if we go that route we should probably expose them for svg images and such first, rather than iframes...

[css-meeting-bot]

The CSS Working Group just discussed safe-area-insets.

The full IRC log of that discussion

<TabAtkins> Topic: safe-area-insets
<RossenF2F> github:https://github.com//issues/4670
<TabAtkins> emilio: there's no explicit area in env() spec about how safe-area-inset behaves in iframes
<TabAtkins> emilio: ipmls disagree. We're doing some related work, would like it clarified.
<TabAtkins> emilio: If iframes are nested, they may not care about safe areas, etc.
<TabAtkins> TabAtkins: Who's responsible for this spec?
<TabAtkins> heycam: dino and you
<TabAtkins> TabAtkins: I'm there for processing model, not values. ^_^
<RossenF2F> Zakim, open queue
<Zakim> ok, RossenF2F, the speaker queue is open
<TabAtkins> hober: I'm happy to bug dean about this.
<TabAtkins> TabAtkins: Can you (emilio) tag dino into the thread?
<TabAtkins> emilio: Yes

[emilio]

CC @grorg, maybe you could weigh-in?

[akantsc]

@emilio @grorg Is there any updated status on this? I've recently encountered a problem that could very much use the ability for the parent to set the child iframe's insets.

[Aarbel]

Also interested in an update here, especially to simulate devices with safe-area on desktop: cf storybookjs/storybook#12852

Being able to set env variables for an iframe would be a must !