As a developer, I have run into a stupid typo in a filter's name making me pull my hair out for an hour until I realized it. Had there been a console warning or an error about the non-existent filter name, I would not be bald 🧑‍🦲 now.
On Fri, Oct 29, 2021 at 7:24 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Hey Domenic! :) > > On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> On Thu, Oct 28, 2021 at 3:48 PM 'Aaron Krajeski' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> yoavweiss@: >>> >>> Great video, thanks for that!! >>> >>> Thanks! >>> >>> Were the concerns WebKit raised on the issue >>> <https://github.com/whatwg/html/issues/5618> addressed? Can you expand >>> on that front? >>> >>> Yes, othermaciej@'s comments lead to us changing the name of that >>> function to `reset` instead of `clear`. >>> >>> Is the hold-up on the Filters PR editorial or something more fundamental? >>> >>> The hold-up is mostly over the question of whether `new >>> CanvasFilter({filter: "someNonExistantFilterType"})` should throw an error. >>> You can read the (very long) discussion in the pull request >>> <https://github.com/whatwg/html/pull/6763>. Unfortunately it's been >>> extremely hard to reach consensus on that specific issue for the past 3 >>> months. Any comments from this group that would help drive us towards >>> consensus would be much appreciated! >>> >> >> FWIW the two HTML editors on the thread (myself and Anne, with our HTML >> editor hats on), as well as Mozilla (via Anne with his Mozilla hat on), >> prefer the throwing behavior. I think in most cases to overcome that >> position we would need some really strong reasons why the Chromium project >> believes the non-throwing behavior is better. It's not clear to me how >> strong Chromium's position is on this issue, and whether it's worth >> delaying the feature over. (Or indeed, delaying all the features, since the >> plan seems to be to bundle them together?) >> > > My concerns with the throwing behavior are similar to the ones we have > discussed > <https://github.com/w3c/mediasession/issues/228#issuecomment-886455386> > in the context of MediaSession actions. > If we go with the throwing behavior, every future addition of filters > would have a significant interop risk, in case adopting developers won't > use try/catch properly. If they do that and they are not testing in > not-yet-supporting browsers, their apps are likely to break entirely in > those browsers. > If we go with a silent failure + feature detection approach, developers > using the feature without properly detecting it may not have the desired > visual effects they are going for, but won't have unrelated parts of their > app break. > > From my perspective (with my API owner hat on), less risk is better, and > the second approach seems less risky to me. > > >> >>> >>> Are these features individually detectable? Do we have reasonable >>> developer advice on how we want folks to use those features with backwards >>> compat/fallbacks in mind? >>> >>> We're working with the DevRel team on some polyfills that will be >>> included in a web.dev article that is launching. All the features are >>> trivially detectable except for perhaps contextlost/restored events. I can >>> look further into that if you'd like? >>> >> >> Those two are feature detectable using 'oncontextlost' in >> Document.prototype, happily enough. >> >> >>> For polyfills, there are different degrees of effectiveness/difficulty. >>> Easy: roundRect (small perf hit), reset >>> Hard, maybe we should just advertise a polyfill that avoids errors: >>> filters, conic gradient, text modifiers >>> Doesn't make sense to polyfill: contextloss, willReadFrequently >>> >>> On Thursday, October 21, 2021 at 3:07:21 AM UTC-4 yoav...@chromium.org >>> wrote: >>> >>>> Thanks for modernizing Canvas! :) >>>> >>>> On Thu, Oct 14, 2021 at 11:06 PM Aaron Krajeski <aar...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> *Contact emails*aar...@chromium.org, fs...@chromium.org >>>>> >>>>> *Explainer* >>>>> https://github.com/fserb/canvas2d >>>>> https://youtu.be/dfOKFSDG7IM >>>>> >>>> >>>> Great video, thanks for that!! >>>> >>>> >>>>> >>>>> *Specification* >>>>> Context Lost Event >>>>> <https://html.spec.whatwg.org/multipage/indices.html#event-contextlost> >>>>> Context Restored Event >>>>> <https://html.spec.whatwg.org/multipage/indices.html#event-contextrestored> >>>>> Will Read Frequently >>>>> <https://html.spec.whatwg.org/multipage/canvas.html#concept-canvas-will-read-frequently> >>>>> New Text Modifiers >>>>> <https://html.spec.whatwg.org/multipage/canvas.html#canvastextdrawingstyles> >>>>> Reset >>>>> <https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-reset> >>>>> >>>> >>>> Were the concerns WebKit raised on the issue >>>> <https://github.com/whatwg/html/issues/5618> addressed? Can you expand >>>> on that front? >>>> >>>> >>>>> RoundRect >>>>> >>>>> <https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-roundrect>Conic >>>>> Gradient >>>>> >>>>> <https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-createconicgradient> >>>>> Filters <https://github.com/whatwg/html/pull/6763> (still in progress) >>>>> >>>> >>>> Is the hold-up on the Filters PR editorial or something more >>>> fundamental? >>>> I noticed Mozilla's opposition on their position. Is that something >>>> that has changed since? >>>> >>>> Are these features individually detectable? Do we have reasonable >>>> developer advice on how we want folks to use those features with backwards >>>> compat/fallbacks in mind? >>>> >>>> >>>>> >>>>> *Summary* >>>>> Updated functionality for the Canvas2D API. Adds seven new >>>>> features/functions to CanvasRenderingContext2D: >>>>> >>>>> - "ContextLost" and "ContextRestored" events >>>>> - "willReadFrequently" option for canvases where lots of readback is >>>>> expected >>>>> - More CSS text modifier support >>>>> - A reset function >>>>> - A roundRect draw primitive >>>>> - Conic gradients >>>>> - Better support for SVG filters >>>>> >>>>> https://github.com/fserb/canvas2d >>>>> >>>>> *Blink component* >>>>> Blink>Canvas >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECanvas> >>>>> >>>>> >>>>> *TAG review status*Resolution: satisfied >>>>> <https://github.com/w3ctag/design-reviews/issues/627#issuecomment-838726027> >>>>> >>>>> *Risks* >>>>> Security and privacy team expressed concerns with ContextLost and >>>>> ContextRestored events during the intent to implement phase. These >>>>> concerns >>>>> were addressed by re-designing the event to not launch simultaneously >>>>> across different contexts. >>>>> >>>>> *Interoperability and Compatibility* >>>>> Gecko: In development (https://github.com/whatwg/html/issues/5431 >>>>> <https://www.chromestatus.com/admin/features/launch/6051647656558592/5?intent=1>) >>>>> Already implemented conic gradient. Okay with willReadFrequently, >>>>> transforms and reset. >>>>> >>>>> WebKit: Positive (https://github.com/whatwg/html/issues/5619). >>>>> Positive signal on text modifiers, round rect and color input. >>>>> >>>>> Web developers: Positive (https://www.youtube.com/watch?v=dfOKFSDG7IM) >>>>> CDN talk in December was received very positively. >>>>> >>>>> *Signals* >>>>> Gecko: https://github.com/mozilla/standards-positions/issues/519 >>>>> WebKit: >>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031833.html >>>>> >>>>> *Is this feature fully tested by* web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>> ? >>>>> Yes >>>>> >>>>> *Flag name* >>>>> #new-canvas-2d-api >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Tracking bug* >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1201359 >>>>> >>>>> *Estimated milestones* >>>>> OriginTrial desktop first >>>>> 95 >>>>> >>>>> OriginTrial desktop last >>>>> 98 >>>>> >>>>> OriginTrial android first >>>>> 95 >>>>> >>>>> OriginTrial android last >>>>> 98 >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> https://www.chromestatus.com/feature/6051647656558592 >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://www.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/eb702e7e-88d6-4b6f-b419-6051511689f1n%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eb702e7e-88d6-4b6f-b419-6051511689f1n%40chromium.org?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/ad052b76-cd02-475a-82a2-f010ecb92075n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ad052b76-cd02-475a-82a2-f010ecb92075n%40chromium.org?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/CAL5BFfVe%3DWB7vT%2BmM3oS%3DJg_nJj7Xu8MGt9eqHqQjkno9Xv1Aw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVe%3DWB7vT%2BmM3oS%3DJg_nJj7Xu8MGt9eqHqQjkno9Xv1Aw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.3.2 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. hTtPs://xKcd.cOm/1181/ -----END PGP SIGNATURE----- -- 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/CALgRrLmrqr1fy3mzY426YKN9%3D7RsY9VRHqvc160vLqSgO5z4Qg%40mail.gmail.com.
