LGTM3 On 04/11/2021 20:04, Daniel Bratell wrote: > LGTM2 > > /Daniel > > On 2021-11-04 20:02, Chris Harrelson wrote: >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw__g2FKLgxFsHJ6cRAjS31ONbatHAv26rJ%3Di4dDWprLRA%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 > <mailto:blink-dev+unsubscr...@chromium.org>. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8c761ee1-90cc-87b6-a05f-b592871031d4%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8c761ee1-90cc-87b6-a05f-b592871031d4%40gmail.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/1daba676-3a97-e8be-2d2b-6aa809125b17%40igalia.com.
