Re: CfC: Should WebCodecs be exposed in Window environments?

Thanks Francois,

On Fri, Jul 16, 2021 at 2:34 AM Francois Daoust <fd@w3.org> wrote:

> For the sake of completion, I note that the process section quoted above
> also has "Groups should favor proposals that create the weakest
> objections. This is preferred over proposals that are supported by a
> large majority but that cause strong objections from a few people".
>

In my reading, this does not describe our circumstances. While we have a
clear majority / minority mix, it is not the case that majority opinion is
less strongly held than that of the minority. Both sides have passionately
argued their positions.


> There seem to be areas that
> could still be explored or discussed, e.g. to:
>
> - assess whether the control queue can alleviate jank concerns:
> https://github.com/w3c/webcodecs/issues/211#issuecomment-879503390


> - better understand constrained devices:
> https://github.com/w3c/webcodecs/issues/211#issuecomment-880870815
>
> - clarify criteria that could make people change their mind:
> https://github.com/w3c/webcodecs/issues/211#issuecomment-861067041
>
> - or perhaps constrain the API somehow so that problematic usage that
> would likely jank the main thread would actually be forbidden on the
> main thread, while other usages on the main thread would remain
> possible?
>
> Francois.
>

Most of these questions are for others in the thread, but I want to chime
in on the last one. Constraining the API differently in different settings
is unappealing. We've heard from developers in the GH issue that existing
differences between window and worker are a source of pain. Moreover, given
Chrome's position that main-thread jank is not material to all use cases
(see our earlier CfC position reply), it follows that the possibility of
such jank shouldn't motivate design restrictions.

Chris