LGTM1 to ship in parallel with landing the PR. On Thu, Nov 4, 2021 at 12:01 PM 'Aaron Krajeski' via blink-dev < blink-dev@chromium.org> wrote:
> During a WHATWG spec meeting this morning we agreed to not throw for > malformed canvas filters. There are still a few editorial changes to go > through on that PR, but other than that everything is settled for this > launch. > > On Friday, October 29, 2021 at 1:53:20 PM UTC-4 dom...@chromium.org wrote: > >> The usual definition of "breaking change" that we use when shipping >> features is not "if web developers always do valid things, then the change >> we are making avoids breakages". We can't rely on web developers to write >> valid code all the time... see e.g. stats about what percent of the web is >> valid HTML. >> >> For example, while people might not write "asdf", they might write >> "colourMatrix" (spot the typo), or similar. >> >> On Fri, Oct 29, 2021 at 1:50 PM Fernando Serboncini <fs...@chromium.org> >> wrote: >> >>> yes, of course if you pass "asdf" one would throw and the other >>> wouldn't. There will be a potential behavior difference. >>> >>> My point is nobody would write "asdf" as a filter, because "asdf" is not >>> a spec'ed or implemented filter anywhere. There are no possible mismatches >>> at this point. If CanvasFilter exists, the set of filters is well defined >>> everywhere. >>> >>> On Fri, Oct 29, 2021 at 1:45 PM Domenic Denicola <dom...@chromium.org> >>> wrote: >>> >>>> I don't think that's true. If someone passes "asdf" to the CanvasFilter >>>> constructor, changing from not-throwing to throwing would be a breaking >>>> change. We'd need to add use counters, etc. to find out if anyone is >>>> passing such invalid values. >>>> >>>> Whereas, if we start off with throwing, we can always remove the >>>> throwing behavior later, with no use counters required. >>>> >>>> On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini <fs...@chromium.org> >>>> wrote: >>>> >>>>> Since the current implementation is not throwing, we could reasonably >>>>> launch as-is and the add throwing if it is agreed to do so after. >>>>> The added risk is the exact same risk that we are arguing to begin >>>>> with (i.e., code that uses not-implemented filters without try/catch would >>>>> break). But since there are no "not-implemented filters" yet, it may not >>>>> be >>>>> a problem. >>>>> >>>>> On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola <dom...@chromium.org> >>>>> wrote: >>>>> >>>>>> Yep. Reasonable people can disagree on the tradeoffs here. The >>>>>> question is whether this is something we want to deadlock over with other >>>>>> implementers. >>>>>> >>>>>> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor <mike...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> On 10/29/21 1:23 AM, Yoav Weiss wrote: >>>>>>> >>>>>>> Hey Domenic! :) >>>>>>> >>>>>>> On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola < >>>>>>> dom...@chromium.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> I agree with Yoav here (sorry, I don't own any hats). Not throwing >>>>>>> will likely result in fewer broken pages in less-well-tested browsers >>>>>>> that >>>>>>> haven't implemented the APIs yet. And +1 for devtools warnings to help >>>>>>> developers figure out "silent" failures. >>>>>>> >>>>>>> (I also wonder if requiring try/catch won't trip up new developers >>>>>>> trying to use it inside Promises, who don't yet know about >>>>>>> `then()/catch()` >>>>>>> patterns). >>>>>>> >>>>>> -- > 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/0612b019-71ee-41e9-aa78-aba0712d0a0dn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0612b019-71ee-41e9-aa78-aba0712d0a0dn%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/CAOMQ%2Bw__g2FKLgxFsHJ6cRAjS31ONbatHAv26rJ%3Di4dDWprLRA%40mail.gmail.com.
