LGTM2 The fact that iOS already shipped this is a compelling argument.
On Thu, Sep 12, 2024 at 3:55 PM Rick Byers <rby...@chromium.org> wrote: > On Thu, Sep 12, 2024 at 9:09 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> On Wed, Sep 11, 2024 at 5:05 PM Wenyu Fu <weny...@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 >>> <https://drive.google.com/file/d/19kaNBAr8RFQ0X9odMjx4g-t28lnCHSS_/view?usp=drive_link>. >>> 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 >>> <https://drive.google.com/file/d/1IhIiYMaG5bK2n-ufahEqkQwcPTok7sFe/view?usp=drive_link> >>> - >>> 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 <weny...@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 <weny...@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) < >>>>>> yoavwe...@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 >>>> <https://developer.mozilla.org/en-US/docs/Web/CSS/env#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 >>>> <https://www.chromium.org/blink/launching-features/#behavior-changes>. >>>> 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) > > >>>> On Fri, Aug 30, 2024 at 7:10 PM Wenyu Fu <weny...@chromium.org> wrote: >>>>>>> >>>>>>>> > 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 >>>>>>>> >>>>>>>> On Thu, Aug 29, 2024 at 11:53 PM uazo <carmelo.mess...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> > Design docs >>>>>>>>> >>>>>>>>> could you make public access to the indicated document? >>>>>>>>> >>>>>>>>> thank you! >>>>>>>>> >>>>>>>>> On Thursday, August 29, 2024 at 9:09:17 PM UTC+2 >>>>>>>>> ikilp...@chromium.org wrote: >>>>>>>>> >>>>>>>>>> On Thu, Aug 29, 2024 at 12:00 PM Wenyu Fu <wen...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emailswen...@chromium.org, wen...@google.com >>>>>>>>>>> >>>>>>>>>>> ExplainerNone >>>>>>>>>>> >>>>>>>>>>> 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 componentBlink>CSS >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Search tagssafearea >>>>>>>>>>> <https://chromestatus.com/features#tags:safearea> >>>>>>>>>>> >>>>>>>>>>> TAG reviewNone >>>>>>>>>>> >>>>>>>>>>> TAG review statusNot 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. >>>>>>>>>>> >>>>>>>>>> >>>> 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. >>>> >>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ?No >>>>>>>>>>> >>>>>>>>>>> Flag name on chrome://flagsdynamic-safe-area-insets, >>>>>>>>>>> dynamic-safe-area-insets-on-scroll >>>>>>>>>>> >>>>>>>>>>> Finch feature nameDynamicSafeAreaInsets, >>>>>>>>>>> DynamicSafeAreaInsetsOnScroll >>>>>>>>>>> >>>>>>>>>>> Requires code in //chrome?False >>>>>>>>>>> >>>>>>>>>>> Tracking bughttps://g-issues.chromium.org/issues/324436581 >>>>>>>>>>> >>>>>>>>>>> Launch bughttps://launch.corp.google.com/launch/4339772 >>>>>>>>>>> >>>>>>>>>>> MeasurementNo specific measurement on web platform. This >>>>>>>>>>> success will be measured together with >>>>>>>>>>> https://launch.corp.google.com/launch/4339772 >>>>>>>>>>> >>>>>>>>>>> Availability expectationFeature is already available on Safari, >>>>>>>>>>> and is implemented to make available on Chrome on Android. >>>>>>>>>>> >>>>>>>>>>> Adoption expectationNo change is required from web developer. >>>>>>>>>>> >>>>>>>>>>> Adoption planNo 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 >>>>>>>>>>> >>>>>>>>>> >>>> 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 >>>>>>>>>>> <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 on the web visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbBh16No8Jsge-tsaxfXsYOauJVkW4cxsVJQkJ_-2hFAww%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbBh16No8Jsge-tsaxfXsYOauJVkW4cxsVJQkJ_-2hFAww%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 on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbDYE2m%3Do-ddaJZc1CvN5FL4jHRbS_fo8T4mfc8tvwk6OA%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbDYE2m%3Do-ddaJZc1CvN5FL4jHRbS_fo8T4mfc8tvwk6OA%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 on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbATXu5g-ou4Vc6O%3D8%2BaKnTGkVSFmOZu_ZZSVo0pz_GbfA%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFtDRbATXu5g-ou4Vc6O%3D8%2BaKnTGkVSFmOZu_ZZSVo0pz_GbfA%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 on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJn064YAioCwXFQ9FRgdt1i_5f9ROE00nirya40RcLCrA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJn064YAioCwXFQ9FRgdt1i_5f9ROE00nirya40RcLCrA%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJxfoNaxWUYCC9RjvhqoUoiZgeR4q1X3%3Dvq52Kh58mMuw%40mail.gmail.com.
