Thanks so much for reporting this, Nic! :) (pun not intended)
A few generic questions:
- Do you have outreach channels to your customers where those
deprecations are being reported? Are they presented as e.g. warnings in
their dashboards?
- What information would you find useful in the reports that would make
it easier to communicate the issue and potential solutions to your
customers?
And finally, a more specific question: can you share numbers regarding the
rough number of customer origins that are hitting this? Even an order of
magnitude would be helpful.
Cheers,
Yoav
On Tue, Sep 27, 2022 at 5:55 PM Nic Jansma <nicjan...@gmail.com> wrote:
> 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/CAL5BFfV05HfH79vSdkn4iSR_J%3DNchafTxtrRdRVqCDBvqDfhtg%40mail.gmail.com.
