- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 4 Feb 2014 13:04:25 +1300
- 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>
- Message-ID: <CAOp6jLYiZj7SHCz54d_JYCrKvbZ28zkLiWYnU08P-VN1oDNq=w@mail.gmail.com>
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 #2. > Rob -- 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