W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2014

Re: Constraints and MediaRecorder

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 4 Feb 2014 13:04:25 +1300
Message-ID: <CAOp6jLYiZj7SHCz54d_JYCrKvbZ28zkLiWYnU08P-VN1oDNq=w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Jan-Ivar Bruaroey <jib@mozilla.com>, Harald Alvestrand <harald@alvestrand.no>, Martin Thomson <martin.thomson@gmail.com>, Cullen Jennings <fluffy@iii.ca>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On Tue, Feb 4, 2014 at 12:25 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> I agree that this is true to some extent, but TBH I found it more
> convincing before your post above suggesting that capability testing
> might consist of empirically verifying that the browser did what it
> promised it did. From the perspective of the consumer of the API,
> what I want is deterministic behavior and that includes errors when
> I ask for something the UA won't.

OK, but the Web likes graceful degradation when feasible. That's why we
don't throw errors when you use an unsupported CSS property in a
stylesheet, and why 2D canvas silently skips rendering operations when
given NaN parameters. This is partly because the Web has a cohort of
mediocre developers and poorly maintained apps, partly because the Web has
heterogenous implementations with different levels of API support, and
partly because Web implementations compete on how many apps they can run so
economics favour permissiveness. (There are yet other reasons applying to
specific examples.) Having said that, I appreciate that degree of
permissiveness involves tradeoffs that have to be analyzed on a case by
case basis.

In this case we have some consumers who want to provide optional
constraints, and others who want to provide mandatory constraints, and
providing a single API that provides both without confusing anyone over its
semantics is a bit hard. If we go with only optional constraints, and let
people implement mandatory checking via inspection APIs that we'll probably
have to provide anyway, it feels like a win to me.

ISTM that there are two arguments one could offer here:
> 1. The JS shouldn't get to dictate to the browser, so effectively its
> requests in the API are just hints and the browser can silently
> not comply and the JS either has to examine the parameters
> of the response or (in the limit) actually directly verify the
> browser's behavior.
> 2. The JS should be allowed to dictate to the browser but constraints
> aren't a good mechanism for doing that.
> I had thought you were arguing #2, but perhaps you are arguing #1?
> Or something else I haven't listed.

In my proposal for MediaRecorderOptions I implicitly argued #1. That aside,
for MediaRecorder I don't think Constraints are worthwhile for either #1 or

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w
Received on Tuesday, 4 February 2014 00:04:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:24 UTC