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 <dome...@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 <dome...@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 <miketa...@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 <dome...@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/CADp2-T_yMnJQCBXy9eKk%3DHm6wcMp5pcOFPPHe6x0k-NrydsHiQ%40mail.gmail.com.
