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.



On Mon, Feb 3, 2025, 5:39 PM Robert Flack <fla...@chromium.org> wrote:

> 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
>
> On Mon, Feb 3, 2025 at 11:19 AM Robert Flack <fla...@chromium.org> wrote:
>
>> 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.
>>
>> On Monday, February 3, 2025 at 10:49:51 AM UTC-5 Robert Flack wrote:
>>>
>>>> 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-*
>>>>
>>>> On Mon, Feb 3, 2025 at 10:08 AM Vladimir Levin <vmp...@chromium.org>
>>>> wrote:
>>>>
>>>>> Contact emailsvmp...@chromium.org, sko...@chromium.org
>>>>>
>>>>> ExplainerThis 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).
>>>>>
>>>>> Specificationhttps://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 componentBlink>Scroll
>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EScroll%22>
>>>>>
>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/1046
>>>>>
>>>>> TAG review statusPending
>>>>>
>>>>> 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
>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>> ?Yes
>>>>>
>>>>> Tests would be added as part of implementation
>>>>>
>>>>>
>>>>> Flag name on about://flagsNone
>>>>>
>>>>> Finch feature nameCSSSafeAreaMaxInsets
>>>>>
>>>>> Requires code in //chrome?False
>>>>>
>>>>> Tracking bughttps://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
>>>>> <https://chromestatus.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/CADsXd2Mhmiv2FvBGiW256%3DCsEvFctnqt3%2BVfOg_0_ONGY1VbNg%40mail.gmail.com
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Mhmiv2FvBGiW256%3DCsEvFctnqt3%2BVfOg_0_ONGY1VbNg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
> 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+unsubscr...@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
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMUr16H3H0_maKn9Z-%3DHttOcKT-bF%2Be3GsjxHOCuobJEA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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+unsubscr...@chromium.org.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALLOKV4_6X6Xy_wxvbpd1g0FPrGrzQq2j_0Jsa3ReoeJAaEDZw%40mail.gmail.com.

Reply via email to