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/CAJh39TPNEQNEZFdbw9FHHfUkc3VDYrDitK_VBwG2YBDxcnb1dw%40mail.gmail.com.
