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 emails
wen...@chromium.org,
wen...@google.com
Explainer
None
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
<https://crbug.com/324436581>
Blink component
Blink>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 tags
safearea
<https://chromestatus.com/features#tags:safearea>
TAG review
None
TAG review status
Not 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://flags
dynamic-safe-area-insets,
dynamic-safe-area-insets-on-scroll
Finch feature name
DynamicSafeAreaInsets,
DynamicSafeAreaInsetsOnScroll
Requires code in
//chrome?
False
Tracking bug
https://g-issues.chromium.org/issues/324436581
Launch bug
https://launch.corp.google.com/launch/4339772
Measurement
No specific measurement on
web platform. This success
will be measured together
with
https://launch.corp.google.com/launch/4339772
Availability
expectation
Feature is already
available on Safari, and
is implemented to make
available on Chrome on
Android.
Adoption expectation
No change is required from
web developer.
Adoption plan
No 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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJxfoNaxWUYCC9RjvhqoUoiZgeR4q1X3%3Dvq52Kh58mMuw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
