Re: [webkit-dev] Status of custom paint?

2020-08-25 Thread Chris Harrelson
(re-sending as chris...@chromium.org, which is actually on the webkit list)

On Tue, Aug 25, 2020 at 1:36 PM Chris Harrelson  wrote:

> Hi WebKit friends,
>
> I'm wondering about the status of the implementation of the CSS Painting
> API <https://webkit.org/status/#specification-css-painting-api-level-1>
> (a.k.a. Custom Paint). I think this
> <https://bugs.webkit.org/show_bug.cgi?id=190217> is the tracking bug?
>
> My understanding is that it's mostly implemented, and the current
> implementation is available in Tech Preview. Is it still being worked on?
>
> Thanks,
> Chris
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?

2020-02-22 Thread Chris Harrelson
Hi Emlio,

Thanks for your patience with these fixes and taking the time to outline
your concerns. Hope things are better now, and as always, if not just say
so. :)

Chris

On Thu, Feb 20, 2020 at 7:39 AM Emilio Cobos Álvarez 
wrote:

> A quick status update here:
>
> I landed some heuristics to disable scroll anchoring in pathological
> cases in Firefox a long while ago. This stopped virtually all compat
> issues, though it's obviously not great.
>
> Chris and other Chromium folks have been doing work to fix Chromium
> issues that were causing these interop problems, and improving the
> scroll anchoring spec.
>
> So I'm going to try and peek up those spec changes in Firefox and then
> try to remove those heuristics on Nightly, and see how it goes.
>
>   -- Emilio
>
> On 11/7/19 12:07 AM, Chris Harrelson wrote:
> > HI Emilio,
> >
> > I'll follow up on crbug.com/920289 <http://crbug.com/920289>. Let's
> > discuss there.
> >
> > On Tue, Oct 29, 2019 at 3:03 PM Emilio Cobos Álvarez  > <mailto:emi...@mozilla.com>> wrote:
> >
> > Hi all,
> >
> >10/18/19 7:19 PM, Chris Harrelson wrote:
> >  > Hi,
> >  >
> >  > Another quick update: Emilio, Navid, Nick, Stefan and I met today
> and
> >  > discussed which issues are important to fix and why. We now have
> > a list of
> >  > spec issues, and WPT tests to fix that are Chromium bugs, that
> should
> >  > substantially improve interop. Nick and Stefan will take on the
> > work to fix
> >  > them, with the review and feedback support of Emilio.
> >
> > So, today another scroll-anchoring bug crossed my radar, and this one
> > I'm not sure at all how to fix it, because there's no obvious answer
> > here as far as I can tell.
> >
> > My diagnosis (for one of the pages, the one I could repro and
> > reduce) is
> > in here[1], but basically my current explanation is that the page
> > should
> > be broken per spec, and that when it works it's hitting a bug in both
> > Chromium[2] which we have an equivalent of but are just not hitting
> > because in Firefox changing `overflow` does more/different layout
> work
> > than in Chrome.
> >
> > The test-case may as well work if we change our scroll event or timer
> > scheduling (see there), but that is obviously pretty flaky.
> >
> > I honestly don't have many better ideas for more fancy heursitics
> about
> > how to unbreak that kind of site. From the point of view of the
> > anchoring code, the page is just toggling height somewhere above the
> > anchor, which is the case where scroll anchoring _should_ work,
> usually.
> >
> > I can, of course (and may as a short-term band-aid, not sure yet) add
> > `overflow` to the magic list of properties like `position` that
> > suppress
> > scroll anchoring everywhere in the scroller, but that'd be just
> kicking
> > the can down the road and waiting for the next difference in layout
> > performance optimizations between Blink and Gecko to hit us.
> >
> > I think (about to go on PTO for the next of the week) I'll add
> > telemetry
> > for pages that have scroll event listeners, and see if disabling
> scroll
> > anchoring on a node when there are scroll event listeners attached
> > to it
> > is something reasonable (plus adding an explicit opt-in of course).
> >
> > I'm not terribly hopeful that the percentage of such documents is
> going
> > to be terribly big, to be honest, but providing an opt-in and doing
> > outreach may be a reasonable alternative.
> >
> > Another idea would be to restrict the number of consecutive scrolls
> > made
> > by scroll anchoring to a given number at most. That would made the
> > experience in such broken websites somewhat less annoying, but it'll
> > also show flickering until that happens, which would make the browser
> > still look broken :/.
> >
> > Thoughts / ideas I may not have thought of/be aware of?
> >
> > Thanks,
> >
> >-- Emilio
> >
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15>
> > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=920289
> > <https://bugs.chromium.org/p/chromium/issues/detail?id=920289>
> >
> >  > Thanks all,
> >  &