We are launching with a console warning. Will check on the PR if it makes sense to add a note about it on the spec.
On Thu, Nov 4, 2021 at 3:08 PM Thomas Steiner <to...@google.com> wrote: > On Thu 4. Nov 2021 at 20:01 '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. > > > What about the console warnings? Or is this not a spec-level decision, but > an implementation detail? > > 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> >> . >> > -- > 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/CADp2-T9zxUszi7RHq1CXgbCy%3Dqa2QotPqR%3D2RZG1gT6xmc5EDw%40mail.gmail.com.
