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.
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.
