Hi everyone!
I've started seeing this deprecation being reported via Reporting API
(through a ReportingObserver and Reporting API pings) on a few sites that
are being measured for RUM.
The actual deprecation report was very hard to decode, as all that was
included was the ID (4201) and a confusing message (which looks like an
internal error message). e.g.:
{
"body": {
"anticipatedRemoval": null,
"columnNumber": 12345,
"id": "4201",
"lineNumber": 1,
"message": "Deprecation messages are stored in the devtools-frontend
repo at front_end/models/issues_manager/DeprecationIssue.ts",
"sourceFile": null
},
"type": "deprecation",
"url": "https://example.com";
}
It took some help from Yoav to understand 4201 is this specific issue (I
think). With the details here, I can begin to understand (as a developer)
how to address the reports.
I filed a Chromium bug to ask for more details in the deprecation report:
https://bugs.chromium.org/p/chromium/issues/detail?id=1368607
On Monday, September 12, 2022 at 8:26:29 PM UTC-4 andr...@google.com wrote:
> CC @Cheney Tsai, @Una Kravets, @Kadir Topal
>
> From a DevRel perspective, the three questions in my mind are:
>
> - Are affected developers aware of the change?
> - I understand they were notified via a console warning /
> deprecation warning. It'd be great to get a sense of how effective the
> communication was (ie: has usage significantly decreased since the
> warnings?).
>
>
> - Have we given them enough time for developers to react to the change?
> - This is less about how complex a change is and more about
> ensuring developers can fit the change into their planning cycle (eg:
> quarterly OKRs) and avoiding generating unplanned/urgent work, if
> possible.
> It does seem to me the timelines described are short.
>
>
> - Are developers somehow blocked in implementing the change?
> - The change seems quite straightforward, but sometimes developers
> are blocked in surprising ways. Is there a channel developers can
> provide
> feedback on?
>
>
>
> Andre
>
> On Mon, 12 Sept 2022 at 01:54, Mike Taylor <mike...@chromium.org> wrote:
>
>> LGTM2
>>
>> On 9/9/22 12:16 PM, Khushal Sagar wrote:
>>
>>
>>
>> On Fri, Sep 9, 2022 at 11:37 AM Yoav Weiss <yoav...@chromium.org> wrote:
>>
>>> Thanks for meticulously gathering that data!!
>>>
>>> Just to give a rough idea - 5K pixels would be 50x100 pixels, which
>>> is noticeable breakage but not necessarily an insurmountable one.
>>> The numbers are a bit higher than I'd like, but at the same time, this
>>> enables new capabilities and we're not walking this path alone
>>> <https://github.com/mozilla/standards-positions/issues/659#issuecomment-1182596173>
>>> .
>>>
>>> Given the above, *LGTM1* for a careful and monitored rollout,
>>> accompanied with DevRel folks supporting y'all in communicating this change
>>> to developers.
>>> What are the timelines you have in mind? Is there some way to use
>>> Deprecation Reporting to help us here?
>>>
>>
>> I would target a gradual roll out: 1% -> 10% -> 25% -> 50% -> 100% with a
>> week before each progression in M107. The release will go to stable
>> ~October 25th (schedule <https://chromiumdash.appspot.com/schedule>).
>>
>> In terms of outreach a console warning
>> <https://chromiumdash.appspot.com/commit/97b80f4e3b9b742a8c44fa5cb96b6c753b29f3d2>
>>
>> and a deprecation warning
>> <https://chromiumdash.appspot.com/commit/0d0d8e0a1862e689690a702a5c5295531d9a3a27>
>> was
>> added in M105 for cases where the element's computed style can cause this
>> behaviour change. I've also reached out to the dev rel folks for a targeted
>> email to affected sites that came up through our CT analysis.
>>
>>
>>>
>>> On Fri, Sep 9, 2022 at 5:27 PM Khushal Sagar <khusha...@chromium.org>
>>> wrote:
>>>
>>>> We have UseCounter data from M105 stable to quantify the large breakage
>>>> for this feature. Large is a page load where any image, video or canvas
>>>> drawn on the page paints over 5k CSS pixels outside its content-box. The
>>>> precise numbers (with page load count) are here
>>>> <https://docs.google.com/document/d/1GC2wanCPtoboSujQVr5xoCDlpzzhspr0PHA-OBgGbEY/edit>
>>>> (sorry
>>>> can't share the details externally).
>>>>
>>>> In terms of percentage, Windows/Mac had ~0.006% page loads fall in the
>>>> large breakage category and Android had ~0.007%.
>>>>
>>>> On Tue, Aug 2, 2022 at 3:14 PM Khushal Sagar <khusha...@chromium.org>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss <yoav...@chromium.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar <khusha...@chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss <yoav...@chromium.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks Khushal! :)
>>>>>>>>
>>>>>>>> The breakage seems potentially significant (at worst, makes the
>>>>>>>> site visually broken and unusable), and the percentage of breakage
>>>>>>>> seems
>>>>>>>> above the threshold we typically consider safe.
>>>>>>>> At the same time this seems like a positive change, and our friends
>>>>>>>> at Mozilla consider it "worth prototyping".
>>>>>>>>
>>>>>>>> Would it be possible to consider this as a deprecation of the old
>>>>>>>> behavior, and run the console issue (+deprecation warnings and
>>>>>>>> outreach to
>>>>>>>> affected sites) for a few milestones, to try and drive the usage down
>>>>>>>> before flipping this change to be on by default? Maybe also get some
>>>>>>>> documentation out there and work with devrel folks to make sure folks
>>>>>>>> are
>>>>>>>> aware of this coming change?
>>>>>>>>
>>>>>>>> Does that sound reasonable?
>>>>>>>>
>>>>>>>
>>>>>>> Thanks for the suggestion Yoav. This sounds reasonable. I've reached
>>>>>>> out to the devrel folks to do more outreach about this change. I'll
>>>>>>> update
>>>>>>> this thread with the plan for it. The console issue and deprecation
>>>>>>> warnings have been added in M105.
>>>>>>>
>>>>>>> I looked into adding a use counter for sites which have real
>>>>>>> breakage, since the current metric tracks whether the computed style
>>>>>>> *could* permit allow but not whether there is actual overflow at paint
>>>>>>> time. And unfortunately computing potential overflow is not easy to
>>>>>>> add.
>>>>>>> The CT analysis I ran earlier did this by turning the feature on and
>>>>>>> tracking actual overflow generated by the element. So a couple of
>>>>>>> questions
>>>>>>> for moving forward:
>>>>>>>
>>>>>>> - Would it be okay to turn the feature on in beta and 1% stable (in
>>>>>>> M105) to collect metrics for the sites with real breakage and the
>>>>>>> extent of
>>>>>>> this breakage (how many pixels of overflow do we see). This should be
>>>>>>> lower
>>>>>>> than the counter of 0.017%.
>>>>>>>
>>>>>>
>>>>>> That sounds like a great way to gather data! (assuming the relevant
>>>>>> Chrome processes are followed)
>>>>>> Would be good to gather a histogram of overflowed pixels, to get a
>>>>>> sense of "small breakage" vs. "large breakage".
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> - What's the number (in terms of page loads affected) we should be
>>>>>>> targeting before this would be safe?
>>>>>>>
>>>>>>
>>>>>> From my perspective, I'd be comfortable shipping this if we're seeing
>>>>>> less than 0.003% of page loads in the "large breakage" bucket (say more
>>>>>> than ~5000 overflowing pixels, assuming that number makes sense).
>>>>>>
>>>>>> +Andre Bandarra - for devrel opinions on this.
>>>>>>
>>>>>
>>>>> Currently we're recording a UseCounter when any breakage would happen,
>>>>> i.e, there is any pixel overflow. If it helps to have a UseCounter for
>>>>> overflow above a threshold, I'm happy to add that too.
>>>>>
>>>>> We do have an UMA metric which measures the number of overflowing
>>>>> pixels when there is overflow but it's for all images rendered. I can tie
>>>>> it to the UseCounter so we can also know the number of affected page
>>>>> loads
>>>>> with large breakage. I'll wait till the end of the week for more
>>>>> feedback,
>>>>> otherwise assume 5k is a good threshold for large breakage.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Yoav
>>>>>>>>
>>>>>>>> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:
>>>>>>>>
>>>>>>>>> Hey folks,
>>>>>>>>>
>>>>>>>>> I'm summarizing the steps to mitigate the compat risk with this
>>>>>>>>> feature based on the feedback:
>>>>>>>>>
>>>>>>>>> - Add a warning to the console when a developer style would
>>>>>>>>> permit replaced elements to overflow. The patch to add that is
>>>>>>>>> here
>>>>>>>>>
>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3763640>
>>>>>>>>> and
>>>>>>>>> documentation to help developers debug, which is referenced in the
>>>>>>>>> console
>>>>>>>>> warning, is here
>>>>>>>>>
>>>>>>>>> <https://github.com/WICG/shared-element-transitions/pull/166/files>.
>>>>>>>>> We can pre-emptively add this warning to M105 and ship the feature
>>>>>>>>> in M106
>>>>>>>>> to have a one release window before the behaviour changes.
>>>>>>>>>
>>>>>>>>> - Send an email to the webmaster of sites surfaced in the CT
>>>>>>>>> analysis which already have the styles that trigger the warning
>>>>>>>>> above.
>>>>>>>>>
>>>>>>>>> In addition to the above, the feature can be turned off with a
>>>>>>>>> server-side config using finch if there is any severe breakage.
>>>>>>>>>
>>>>>>>>> Please let me know if the above suffices.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>> Khushal
>>>>>>>>>
>>>>>>>>> On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar <
>>>>>>>>> khusha...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor <mike...@chromium.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 7/13/22 3:04 PM, Khushal Sagar wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss <yoav...@chromium.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss <
>>>>>>>>>>>>> yoav...@chromium.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <
>>>>>>>>>>>>>> khusha...@chromium.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Contact emails khusha...@chromium.org, vmp...@chromium.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Explainer
>>>>>>>>>>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
>>>>>>>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/7058
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Specification
>>>>>>>>>>>>>>> https://drafts.csswg.org/css-overflow/#overflow-properties
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Summary
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This change allows developers to use the existing `overflow`
>>>>>>>>>>>>>>> property with replaced elements that paint outside the
>>>>>>>>>>>>>>> content-box. Paired
>>>>>>>>>>>>>>> with `object-view-box` this can be used to create an image with
>>>>>>>>>>>>>>> a custom
>>>>>>>>>>>>>>> glow or shadow applied, with proper ink-overflow behavior like
>>>>>>>>>>>>>>> a CSS shadow
>>>>>>>>>>>>>>> would have.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Blink component Blink>CSS
>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> TAG review
>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/750
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> TAG review status Pending
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Risks
>>>>>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This feature changes the behaviour of the existing overflow
>>>>>>>>>>>>>>> property on replaced elements (img, video, canvas). Currently
>>>>>>>>>>>>>>> `overflow:visible` in a developer stylesheet on such elements
>>>>>>>>>>>>>>> is ignored
>>>>>>>>>>>>>>> during paint and the content is clipped to the element's
>>>>>>>>>>>>>>> content-box. With
>>>>>>>>>>>>>>> this feature, `overflow:visible` will result in content outside
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> element's content-box to paint as ink overflow. We've collected
>>>>>>>>>>>>>>> use counter
>>>>>>>>>>>>>>> data to measure the number of sites which could be affected by
>>>>>>>>>>>>>>> this. The
>>>>>>>>>>>>>>> use counter data collected over 1 week of a stable release
>>>>>>>>>>>>>>> (M102) is as
>>>>>>>>>>>>>>> follows. We collected 2 different counters explained below. *
>>>>>>>>>>>>>>> The first
>>>>>>>>>>>>>>> measures any instance where overflow is explicitly set from
>>>>>>>>>>>>>>> developer
>>>>>>>>>>>>>>> styles to visible. The percentage of page loads with this is
>>>>>>>>>>>>>>> 2.16%. * The
>>>>>>>>>>>>>>> second measures the above instances but only includes the cases
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> object-fit set to cover or none or object-position set to any
>>>>>>>>>>>>>>> value other
>>>>>>>>>>>>>>> than the default (50% 50%). The rationale behind this counter
>>>>>>>>>>>>>>> is to exclude
>>>>>>>>>>>>>>> cases which can not cause overflow (such as
>>>>>>>>>>>>>>> object-fit:contain), even if
>>>>>>>>>>>>>>> overflow is set to visible. The percentage of page loads with
>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>> 0.017%.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's not nothing. Any idea what breakage may look like?
>>>>>>>>>>>>>> Can we maybe collect histograms on *how much* overflow would
>>>>>>>>>>>>>> occur in those cases? (maybe with ClusterTelemetry initially, to
>>>>>>>>>>>>>> get a
>>>>>>>>>>>>>> rough idea in the lab)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I ran an analysis on CT using top 100k sites for desktop and
>>>>>>>>>>>>> top 10k sites on mobile. The raw numbers are here: desktop
>>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1kKWq8kqZOfCXqiHaiamYNDdTs5x1_YJfDTnAgXOIwaE/edit#gid=0>
>>>>>>>>>>>>>
>>>>>>>>>>>>> and mobile
>>>>>>>>>>>>> <https://docs.google.com/spreadsheets/d/1SrNyrEe4yzCOIxqNOlNgCk8O58NqqoBlBTd4Wn_gKCc/edit#gid=0>,
>>>>>>>>>>>>>
>>>>>>>>>>>>> and the rough patch
>>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3749485>
>>>>>>>>>>>>> to
>>>>>>>>>>>>> collect this data. The highlights from the analysis are below:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - The number of sites which override the default CSS to
>>>>>>>>>>>>> allow overflow *and* also had overflow during painting was 13
>>>>>>>>>>>>> out of 10k on
>>>>>>>>>>>>> mobile and 39 out of 63k on desktop (only 63k sites yielded
>>>>>>>>>>>>> results out of
>>>>>>>>>>>>> 100k).
>>>>>>>>>>>>>
>>>>>>>>>>>>> - I measured the percentage of area painted outside the
>>>>>>>>>>>>> content box out of the total painted area. The highest was 88%
>>>>>>>>>>>>> on desktop
>>>>>>>>>>>>> and 70% on mobile.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure what that means in practice. Can you elaborate?
>>>>>>>>>>>> Have you looked at extreme cases to see the impact there?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sorry, I should've added more details. :) I was looking for
>>>>>>>>>>> breakages with 2 numbers: sites with the largest number of
>>>>>>>>>>> overflowing
>>>>>>>>>>> pixels (such that other content could be occluded); sites with the
>>>>>>>>>>> largest
>>>>>>>>>>> percentage of image content outside the content box. But I realize
>>>>>>>>>>> the
>>>>>>>>>>> former is probably better to identify breakages.
>>>>>>>>>>>
>>>>>>>>>>> Looking at the top 10 sites, the worst affected is liveops.com.
>>>>>>>>>>> This has cases which use object-fit:cover so the image scales to a
>>>>>>>>>>> size
>>>>>>>>>>> bigger than its content rect and developer CSS overrides overflow
>>>>>>>>>>> to
>>>>>>>>>>> visible. Unfortunately, interacting more with this site, I did see
>>>>>>>>>>> images
>>>>>>>>>>> which are drawing above other content (screenshot attached) as you
>>>>>>>>>>> scroll
>>>>>>>>>>> down. This pattern showed up on the rest of the sites with high
>>>>>>>>>>> overflow
>>>>>>>>>>> numbers too (another example with screenshot attached).
>>>>>>>>>>>
>>>>>>>>>>> This kind of breakage is expected with this change. I'm not sure
>>>>>>>>>>> where to put the cutoff to identify sites with significant
>>>>>>>>>>> breakage, but
>>>>>>>>>>> there are at least 30 sites (out of 63k) that have images with more
>>>>>>>>>>> than
>>>>>>>>>>> 100px of overflow. The fix for the developer is to trace down the
>>>>>>>>>>> source of
>>>>>>>>>>> the overflow override and remove it.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure what's the recommended way to progress with a
>>>>>>>>>>> behaviour change like this given these numbers, the instances of
>>>>>>>>>>> affected
>>>>>>>>>>> sites seems low. Since the fix is simple, but hard to diagnose, one
>>>>>>>>>>> option
>>>>>>>>>>> could be to add a warning to the console: "overflow:visible now
>>>>>>>>>>> causes
>>>>>>>>>>> images to draw outside their bounds. Please make sure this style is
>>>>>>>>>>> intentional" for a few releases (credits to @Vladimir Levin for
>>>>>>>>>>> the idea). Would that suffice?
>>>>>>>>>>>
>>>>>>>>>>> This feels like a fairly challenging bug to diagnose out without
>>>>>>>>>>> a DevTools issue
>>>>>>>>>>> <https://developer.chrome.com/docs/devtools/issues/> (or
>>>>>>>>>>> similar console message that links to some useful docs, as you
>>>>>>>>>>> proposed).
>>>>>>>>>>> Would we have the ability to conditionally create these for some
>>>>>>>>>>> overflow
>>>>>>>>>>> threshold value?
>>>>>>>>>>>
>>>>>>>>>> Sure, we can do this conditionally based on the area of overflow.
>>>>>>>>>> I'd be inclined to always do it if the UA style is overridden to
>>>>>>>>>> allow
>>>>>>>>>> overflow for at least a few releases. Since it's likely that
>>>>>>>>>> existing sites
>>>>>>>>>> are not overriding this style intentionally (because currently it's
>>>>>>>>>> a
>>>>>>>>>> no-op). Just to catch cases which don't show up in local testing
>>>>>>>>>> because
>>>>>>>>>> scaling of the image (with properties like object-fit) can depend on
>>>>>>>>>> the
>>>>>>>>>> form factor of the device.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I manually went through ~10 sites on both desktop and mobile.
>>>>>>>>>>>>> For the ones which repro-ed, the breakage was losing rounded
>>>>>>>>>>>>> corners
>>>>>>>>>>>>> because border-radius doesn't clip the content if 'overflow' is
>>>>>>>>>>>>> 'visible'.
>>>>>>>>>>>>> In fact a few sites had the same code, likely coming from
>>>>>>>>>>>>> customerly <https://www.customerly.io/> based on class names
>>>>>>>>>>>>> and the UX. There was one case where an image (used in the
>>>>>>>>>>>>> background) had
>>>>>>>>>>>>> object-fit:cover and overflowed outside the content box now. I've
>>>>>>>>>>>>> attached
>>>>>>>>>>>>> screenshots for both of these.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Overall I didn't see any case where the overflow occluded any
>>>>>>>>>>>>> other content on the page.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That's reassuring! :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Gecko*: No signal (
>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/659)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *WebKit*: No signal (
>>>>>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032317.html
>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *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?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Debuggability
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is a CSS property which can be debugged in the devtools
>>>>>>>>>>>>>>> style panel similar to other CSS properties.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Flag name CSSOverflowForReplacedElements
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Note: Because of the compat risk with this feature, this
>>>>>>>>>>>>>>> flag can be controlled via Finch. This will allow us to
>>>>>>>>>>>>>>> rollback with a
>>>>>>>>>>>>>>> server-side config change if needed.*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tracking bug
>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1321217
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Estimated milestones
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> M105
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anticipated spec changes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> N/A
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>>>>> https://chromestatus.com/feature/5137515594383360
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Links to previous Intent discussions Intent to prototype:
>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUykJWEAqVzcUy15fpBNdA68508Mny_1z--FCBKXRTZOFQ%40mail.gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/camluwuykjweaqvzcuy15fpbnda68508mny_1z--fcbkxrtz...@mail.gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%40mail.gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUze8JV6twLfhPBwkXj_UBMGApU048OdY33hYQn_KDj2rA%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+...@chromium.org.
>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%40mail.gmail.com
>>>>>>>>>>>
>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz9cutp%2BinEc3%2B7sdv%2B2TPoBbEeFCZjZFExBHSOL1p47A%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+...@chromium.org.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%40mail.gmail.com
>>>>>>>
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUy5zyHePkt06pjbtAE_vu1VjbybK5VXURhuSETyR%2Bu54g%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/59e366b8-57c0-42a6-9b91-de4366079412n%40chromium.org.
