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. > > > > 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/CADsXd2MPS-j0KMQDAXz5uq7BpUp%2BE7PKfZHcUf6X98WG78O2%2BA%40mail.gmail.com.
