Re: [csswg-drafts] [css-env-1] Maximum safe area inset values to allow sliding bottom bar (#11019)

The CSS Working Group just discussed `[css-env-1] Maximum safe area inset values to allow sliding bottom bar`, and agreed to the following:

* `RESOLVED: adopt safe-area-max-inset-* values`

<details><summary>The full IRC log of that discussion</summary>
&lt;joshtumath> flackr: The safe-area-inset allows authors to know what portion of their content might overlap content they're not in control of<br>
&lt;joshtumath> ... e.g. the camera<br>
&lt;joshtumath> ... let's authors know when it goes over the safe area, but this changes ddynsmically<br>
&lt;joshtumath> ... this requires re-layout. I would like to add a maximum safe inset area<br>
&lt;joshtumath> ... to allow it to slide in from the side of the screen to cover the inset space<br>
&lt;Rossen5> q<br>
&lt;joshtumath> ... in particular, this is giving you the safe area you would have at large viewport sizes<br>
&lt;joshtumath> ... when viewport is small, less of your content is reaching the edge of the screen so it's less likely to go under native controls and things<br>
&lt;joshtumath> ... when the viewport grows to the large size, it will go under the camera<br>
&lt;smfr> q+<br>
&lt;emilio> q+<br>
&lt;TabAtkins> +1, this sounds reasonable to me.<br>
&lt;smfr> trying to unmute<br>
&lt;Rossen5> ack smfr<br>
&lt;smfr> I will dial back in sorry<br>
&lt;Rossen5> ack emilio<br>
&lt;Rossen5> q smfr<br>
&lt;joshtumath> emilio: it looks reasonable<br>
&lt;Rossen5> q+ smfr<br>
&lt;bramus> q+<br>
&lt;joshtumath> ... I was trying it out in Chrome for Android and don't get the safe area jump you are trying to fix<br>
&lt;joshtumath> flackr: this is behind a bunch of different feature flags<br>
&lt;smfr> (back)<br>
&lt;bramus> Chrome flags: https://gist.github.com/bramus/6ad1bfe96e9b93885c0858e5816acccb<br>
&lt;joshtumath> ... as your controls slide away, the viewport would grow also underneath the switcher bae<br>
&lt;joshtumath> s/bae/bar/<br>
&lt;joshtumath> emilio: recomputing environment variables can be expensive.<br>
&lt;joshtumath> ... keeping track of what uses each variable. but yeah this might be a reasonable way of fixing it.<br>
&lt;joshtumath> flackr: we can use the approach suggested in the issue to optimise it<br>
&lt;joshtumath> ... treat it like a position: sticky type effect<br>
&lt;joshtumath> emilio: but you still need to update the style of elements. you could implement smarter tracking<br>
&lt;Rossen5> ack smfr<br>
&lt;joshtumath> smfr: with Apple we're fine with this<br>
&lt;joshtumath> ... something I thought of is that when they change there will be a resize event. but will there be an event for this to know it's changed?<br>
&lt;joshtumath> flackr: it's already dynamic but I'm proposing adding a static value<br>
&lt;Rossen5> ack bramus<br>
&lt;joshtumath> bramus: I took it for a spin and I think it will work out nicely, solve author problems<br>
&lt;joshtumath> Rossen: OK, the summary of the proposal is to adopt the max-safe-area-inset values<br>
&lt;joshtumath> flackr: wasn't sure if it should be safe-area-max<br>
&lt;bramus> safa-area-max-inset?<br>
&lt;joshtumath> Rossen: safe-area-max?<br>
&lt;joshtumath> RESOLVED: adopt safe-area-max-inset-* values<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11019#issuecomment-2607836504 using your GitHub account


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

Received on Wednesday, 22 January 2025 17:24:31 UTC