Intent to Ship: Dynamic safe area insets

[Wenyu Fu]

Contact emails

wen...@chromium.org, wen...@google.com

Explainer

None

Specification

https://developer.mozilla.org/en-US/docs/Web/CSS/env

Design docs

https://docs.google.com/document/d/1Wg8M-tkeo7_JDRYVV2vB22pAPQMYXuJ2Ik-fmqn-plg/edit?tab=t.0

Summary

Dynamically change the safe area inset based on the shown ration for the browser controls. This is used when to keep the web contents from the display cutout area when Chrome is drawing edge to edge. This feature is targeting Android only. Similar browser behavior is already available for Chrome on iOS and Safari Mobile. Detailed design & implementation, please see crbug.com/324436581

Blink component

Blink>CSS

Search tags

safearea

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No specific behavior changes to API, no impact to WebView.

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Android only - feature targeting OS with a browser controls.

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

dynamic-safe-area-insets, dynamic-safe-area-insets-on-scroll

Finch feature name

DynamicSafeAreaInsets, DynamicSafeAreaInsetsOnScroll

Requires code in //chrome?

False

Tracking bug

https://g-issues.chromium.org/issues/324436581

Launch bug

https://launch.corp.google.com/launch/4339772

Measurement

No specific measurement on web platform. This success will be measured together with https://launch.corp.google.com/launch/4339772

Availability expectation

Feature is already available on Safari, and is implemented to make available on Chrome on Android.

Adoption expectation

No change is required from web developer.

Adoption plan

No changes needed from the developer.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Sample links

https://screencast.googleplex.com/cast/NTMyMTc4MzcyODE0NDM4NHxmOGViYjdmMC1iZg

Estimated milestones

Shipping on Android

129

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No anticipated spec change at the scope for this launch.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5174306712322048?gate=5101473814544384

This intent message was generated by Chrome Platform Status.

[Ian Kilpatrick]

On Thu, Aug 29, 2024 at 12:00 PM Wenyu Fu <wen...@chromium.org> wrote:

Contact emails

wen...@chromium.org, wen...@google.com

Explainer

None

Specification

https://developer.mozilla.org/en-US/docs/Web/CSS/env

Design docs

https://docs.google.com/document/d/1Wg8M-tkeo7_JDRYVV2vB22pAPQMYXuJ2Ik-fmqn-plg/edit?tab=t.0

Summary

Dynamically change the safe area inset based on the shown ration for the browser controls. This is used when to keep the web contents from the display cutout area when Chrome is drawing edge to edge. This feature is targeting Android only. Similar browser behavior is already available for Chrome on iOS and Safari Mobile. Detailed design & implementation, please see crbug.com/324436581

Blink component

Blink>CSS

Could we create a new Blink component for the env(safe-area-*) implementation? (Maybe Blink>SafeArea).

The work isn't being done by the team which owns Blink>CSS so it would be good if there were experts which could triage incoming bugs, etc in this area. 

  

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbBh16No8Jsge-tsaxfXsYOauJVkW4cxsVJQkJ_-2hFAww%40mail.gmail.com.

[uazo]

> Design docs

could you make public access to the indicated document?

thank you!

[Wenyu Fu]

> The work isn't being done by the team which owns Blink>CSS so it would be good if there were experts which could triage incoming bugs, etc in this area. 

Good callout! I can't seem to find an appropriate component for this feature, thus I choose the closest. During development I've been closely working with owners from Blink>CSS (futhark@) and I think this still fits the CSS area. 

FWIW I think we could still create the Blink>CSS>SafeArea component

> make public access to the indicated document?

Sorry for the inconvenience. The original doc is associated with my google account, and I have trouble sharing it to the public.

I've made a public copy: https://docs.google.com/document/d/1VL0KNzdQwATk9Uf8kP0kcbO1-dDx86pPvB_bMQdLLHE/edit

[Yoav Weiss (@Shopify)]

The design doc doesn't give a lot of background. Can you provide a short explanation or an inline explainer as to what this is trying to solve and how we think developers will be using this? Thanks! :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbDYE2m%3Do-ddaJZc1CvN5FL4jHRbS_fo8T4mfc8tvwk6OA%40mail.gmail.com.

[Wenyu Fu]

For Chrome on Android, we are aiming to draw the web contents edge to edge, drawing part of the web contents under the bezels (i.e. navigation bar). This change allows us to correctly dispatch the safe-area-inset* attributes based on the shown ration of the browser controls, so if websites has control elements that anchor to the bottom, they can read the CSS env variable "safe-area-inset-bottom" to avoid having the controls being occluded by the navigation bar. This Intent to Ship is targeting the render side of the change.

[Wenyu Fu]

Friendly ping :) This feature has an associated Chrome milstone, it'd be great if I can get some feedback so I can have them addressed in a timely manner 

[Robert Flack]

My only concern with the current feature is that dynamically updating the safe area while scrolling requires a main thread update for the developer drawn controls (e.g. footer) to respond. This is going to be slow. Hopefully there is a path by which we can recognize this positioning and update it frame perfectly on the compositor similar to fixed / sticky position content.

Otherwise, this seems in line with the established pattern for devices which draw the viewport to an area that is not entirely guaranteed to be visible.

On Mon, Sep 9, 2024 at 12:54 PM Wenyu Fu <wen...@chromium.org> wrote:

Friendly ping :) This feature has an associated Chrome milstone, it'd be great if I can get some feedback so I can have them addressed in a timely manner 

On Fri, Sep 6, 2024 at 7:58 AM Wenyu Fu <wen...@chromium.org> wrote:

For Chrome on Android, we are aiming to draw the web contents edge to edge, drawing part of the web contents under the bezels (i.e. navigation bar). This change allows us to correctly dispatch the safe-area-inset* attributes based on the shown ration of the browser controls, so if websites has control elements that anchor to the bottom, they can read the CSS env variable "safe-area-inset-bottom" to avoid having the controls being occluded by the navigation bar. This Intent to Ship is targeting the render side of the change.

On Fri, Sep 6, 2024 at 3:59 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

The design doc doesn't give a lot of background. Can you provide a short explanation or an inline explainer as to what this is trying to solve and how we think developers will be using this? Thanks! :)

MDN has a great explanation and examples of how this variable is used by developers. I suspect given this is already an established feature and that this is changing it to be dynamic in the case of native UI which only covers the content some of the time that this could have been a PSA. The only risk I can think of is if this is the first instance of a dynamically changing inset, there may be developers who read it once from Javascript and don't have a signal to update their UI when it changes.

I think it would be fair to say that this is supported on all platforms, as they define the environment variable, even though it's only Android that will currently establish a safe area for overdrawn OS controls. I think if any other platform had native controls drawn on top that we would update the variable there too.

Can you attach this video so that it is available externally? I think this is a good example of how the feature is used and what it will look like.

Estimated milestones

Shipping on Android

129

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No anticipated spec change at the scope for this launch.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5174306712322048?gate=5101473814544384

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbBh16No8Jsge-tsaxfXsYOauJVkW4cxsVJQkJ_-2hFAww%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbDYE2m%3Do-ddaJZc1CvN5FL4jHRbS_fo8T4mfc8tvwk6OA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbATXu5g-ou4Vc6O%3D8%2BaKnTGkVSFmOZu_ZZSVo0pz_GbfA%40mail.gmail.com.

[Wenyu Fu]

Thank you for the feedback Robert!

> updating the safe area while scrolling requires a main thread update for the developer drawn controls (e.g. footer) to respond

I've attached a recording of the same feature's behavior on iOS. One of the initiatives for this change is to align Chrome on Android parity with iOS.

> Can you attach this video so that it is available externally?

Here's the link to the recording - I've updated that in chrome status too: https://chromestatus.com/feature/5174306712322048?gate=5101473814544384

[Yoav Weiss (@Shopify)]

On Wed, Sep 11, 2024 at 5:05 PM Wenyu Fu <wen...@chromium.org> wrote:

Thank you for the feedback Robert!

> updating the safe area while scrolling requires a main thread update for the developer drawn controls (e.g. footer) to respond

I've attached a recording of the same feature's behavior on iOS. One of the initiatives for this change is to align Chrome on Android parity with iOS.

> Can you attach this video so that it is available externally?

Here's the link to the recording - I've updated that in chrome status too: https://chromestatus.com/feature/5174306712322048?gate=5101473814544384

On Wed, Sep 11, 2024 at 7:41 AM Robert Flack <fla...@chromium.org> wrote:

My only concern with the current feature is that dynamically updating the safe area while scrolling requires a main thread update for the developer drawn controls (e.g. footer) to respond. This is going to be slow. Hopefully there is a path by which we can recognize this positioning and update it frame perfectly on the compositor similar to fixed / sticky position content.

Otherwise, this seems in line with the established pattern for devices which draw the viewport to an area that is not entirely guaranteed to be visible.

On Mon, Sep 9, 2024 at 12:54 PM Wenyu Fu <wen...@chromium.org> wrote:

Friendly ping :) This feature has an associated Chrome milstone, it'd be great if I can get some feedback so I can have them addressed in a timely manner 

On Fri, Sep 6, 2024 at 7:58 AM Wenyu Fu <wen...@chromium.org> wrote:

For Chrome on Android, we are aiming to draw the web contents edge to edge, drawing part of the web contents under the bezels (i.e. navigation bar). This change allows us to correctly dispatch the safe-area-inset* attributes based on the shown ration of the browser controls, so if websites has control elements that anchor to the bottom, they can read the CSS env variable "safe-area-inset-bottom" to avoid having the controls being occluded by the navigation bar. This Intent to Ship is targeting the render side of the change.

On Fri, Sep 6, 2024 at 3:59 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

The design doc doesn't give a lot of background. Can you provide a short explanation or an inline explainer as to what this is trying to solve and how we think developers will be using this? Thanks! :)

MDN has a great explanation and examples of how this variable is used by developers. I suspect given this is already an established feature and that this is changing it to be dynamic in the case of native UI which only covers the content some of the time that this could have been a PSA. The only risk I can think of is if this is the first instance of a dynamically changing inset, there may be developers who read it once from Javascript and don't have a signal to update their UI when it changes.

Makes sense! Can y'all take a look at the HTTP archive to make sure we don't see evidence of this happening in the wild?

[Rick Byers]

On Thu, Sep 12, 2024 at 9:09 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Wed, Sep 11, 2024 at 5:05 PM Wenyu Fu <wen...@chromium.org> wrote:

Thank you for the feedback Robert!

> updating the safe area while scrolling requires a main thread update for the developer drawn controls (e.g. footer) to respond

I've attached a recording of the same feature's behavior on iOS. One of the initiatives for this change is to align Chrome on Android parity with iOS.

> Can you attach this video so that it is available externally?

Here's the link to the recording - I've updated that in chrome status too: https://chromestatus.com/feature/5174306712322048?gate=5101473814544384

On Wed, Sep 11, 2024 at 7:41 AM Robert Flack <fla...@chromium.org> wrote:

My only concern with the current feature is that dynamically updating the safe area while scrolling requires a main thread update for the developer drawn controls (e.g. footer) to respond. This is going to be slow. Hopefully there is a path by which we can recognize this positioning and update it frame perfectly on the compositor similar to fixed / sticky position content.

Otherwise, this seems in line with the established pattern for devices which draw the viewport to an area that is not entirely guaranteed to be visible.

On Mon, Sep 9, 2024 at 12:54 PM Wenyu Fu <wen...@chromium.org> wrote:

Friendly ping :) This feature has an associated Chrome milstone, it'd be great if I can get some feedback so I can have them addressed in a timely manner 

On Fri, Sep 6, 2024 at 7:58 AM Wenyu Fu <wen...@chromium.org> wrote:

For Chrome on Android, we are aiming to draw the web contents edge to edge, drawing part of the web contents under the bezels (i.e. navigation bar). This change allows us to correctly dispatch the safe-area-inset* attributes based on the shown ration of the browser controls, so if websites has control elements that anchor to the bottom, they can read the CSS env variable "safe-area-inset-bottom" to avoid having the controls being occluded by the navigation bar. This Intent to Ship is targeting the render side of the change.

On Fri, Sep 6, 2024 at 3:59 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

The design doc doesn't give a lot of background. Can you provide a short explanation or an inline explainer as to what this is trying to solve and how we think developers will be using this? Thanks! :)

MDN has a great explanation and examples of how this variable is used by developers. I suspect given this is already an established feature and that this is changing it to be dynamic in the case of native UI which only covers the content some of the time that this could have been a PSA. The only risk I can think of is if this is the first instance of a dynamically changing inset, there may be developers who read it once from Javascript and don't have a signal to update their UI when it changes.

Makes sense! Can y'all take a look at the HTTP archive to make sure we don't see evidence of this happening in the wild?

FWIW, given this is already shipped on iOS, I personally think the compat risk is quite small. Even if we did find a few sites that read it once and then didn't update, they'd probably not be any more broken than they are today with non-dynamic safe areas, right?

Personally I think we should just ship this ASAP to match iOS. As Rob says, there's an argument that it's just a bug fix.

LGTM1 from me (but happy for others to disagree)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJn064YAioCwXFQ9FRgdt1i_5f9ROE00nirya40RcLCrA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

The fact that iOS already shipped this is a compelling argument.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJxfoNaxWUYCC9RjvhqoUoiZgeR4q1X3%3Dvq52Kh58mMuw%40mail.gmail.com.

[Wenyu Fu]

Rick, Yoav, Mike (and many API owners behind the scene), thank you for the review and the approval!