Intent to Prototype & Ship: safe-area-max-inset-* variables

[Vladimir Levin]

Contact emails

vmp...@chromium.org, sko...@chromium.org

Explainer

This proposal builds upon the safe-area-inset variables specified here https://drafts.csswg.org/css-env-1/#safe-area-insets. The safe-area-inset variables can dynamically change based on the device, which can require relayout or in some cases jittery appearance. There are some efforts to be able to composite such changes, but it isn't easily possible in all cases. With that, we propose adding safe-area-max-inset-* set of properties that represent the maximum value that the safe-area-inset-* variables can take. These are static and do not change on the device, which allows developers to reliably use the variables to create smooth and fast effects like bottom-bars that slide down as the safe-area-inset-* changes (as an example).

Specification

https://drafts.csswg.org/css-env-1/#safe-area-max-insets

Summary

In https://chromestatus.com/feature/5174306712322048 we've added dynamic safe area insets which can change as the user interacts with the device. This proposal amends the general safe area feature to add max-area-safe-inset-* variants of the variables which do not change and represent the maximum possible safe area inset. The use case this solves is to avoid needing to relayout the page in cases where the footer (for example) can simply slide as the safe area inset value grows, as opposed to changing size.

Blink component

Blink>Scroll

TAG review

https://github.com/w3ctag/design-reviews/issues/1046

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1171)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/454)

Web developers: Positive This is a requested feature that allows smooth non-layout inducing effects while respecting the safe area insets.

Other signals:

Activation

This feature can be used independently of others and is straightforward to use

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?

None

Debuggability

This feature is debuggable like other css environment variables

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

Yes

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

Yes

Tests would be added as part of implementation

Flag name on about://flags

None

Finch feature name

CSSSafeAreaMaxInsets

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/391621941

Estimated milestones

DevTrial on desktop	135
DevTrial on Android	135

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).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6393888941801472?gate=6231377068163072

This intent message was generated by Chrome Platform Status.

[Robert Flack]

FYI in the spec issue we thought that safe-area-max-inset-* would be better to ensure that it appears next to the safe-area-inset-* in sorted lists: https://github.com/w3c/csswg-drafts/issues/11019#issuecomment-2607836504 where the summary in this issue says max-area-safe-inset-*

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Mhmiv2FvBGiW256%3DCsEvFctnqt3%2BVfOg_0_ONGY1VbNg%40mail.gmail.com.

[Matt Menke]

I'm not seeing any privacy information.  Does this leak information not currently available about the hardware running Chrome, or what software is running on it?

[Robert Flack]

On Mon, Feb 3, 2025 at 11:03 AM Matt Menke <mme...@google.com> wrote:

I'm not seeing any privacy information.  Does this leak information not currently available about the hardware running Chrome, or what software is running on it?

The value exposed in safe-area-max-inset-bottom is the same value that safe-area-inset-bottom exposes once you scroll down.

You could also observe the max inset immediately by setting your viewport-fit to cover:

    @viewport {
      viewport-fit: cover;
    }

As such, I don't believe this is new information, or exposed any earlier than it is already observable.

[Robert Flack]

Small correction, viewport-fit=cover is specified in the meta viewport content string, e.g.

<meta name="viewport" content="width=device-width, viewport-fit=cover">

Demo: https://output.jsbin.com/muxotol

[Victor Miura]

Fwiw, I would not say that these values are static. They can change for example for an accessibility scale change.

It might be better to say these values are not intended to be animated. They provide a "safe max", that can be used for maximum height or padding, which will not be changed frequently, for example in response to scrolling, by the UA.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMUr16H3H0_maKn9Z-%3DHttOcKT-bF%2Be3GsjxHOCuobJEA%40mail.gmail.com.

[Vladimir Levin]

On Mon, Feb 3, 2025 at 1:24 PM Victor Miura <vmi...@google.com> wrote:

Fwiw, I would not say that these values are static. They can change for example for an accessibility scale change.

It might be better to say these values are not intended to be animated. They provide a "safe max", that can be used for maximum height or padding, which will not be changed frequently, for example in response to scrolling, by the UA.

That's a good point, thank you. By static I meant that these would not be changed by typical frequent user actions like scrolling, but as you mention it's not quite the right term.

[Mike Taylor]

LGTM1

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MPS-j0KMQDAXz5uq7BpUp%2BE7PKfZHcUf6X98WG78O2%2BA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMUr16H3H0_maKn9Z-%3DHttOcKT-bF%2Be3GsjxHOCuobJEA%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+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM3

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMUr16H3H0_maKn9Z-%3DHttOcKT-bF%2Be3GsjxHOCuobJEA%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MPS-j0KMQDAXz5uq7BpUp%2BE7PKfZHcUf6X98WG78O2%2BA%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c7d4e2d-01e5-4433-b56e-dafa1533c6b7n%40chromium.org.