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. > > 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 >>>>>>>> >>>>>>>> Specificationhttps://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/CAFtDRbAp4T4QWx_WFLPN6djx1t250ABZJ5i570vrda105e2JiQ%40mail.gmail.com.
