- From: Eric Rescorla <ekr@rtfm.com>
- Date: Sat, 8 Feb 2014 12:28:17 -0800
- To: "Robert O'Callahan" <robert@ocallahan.org>
- 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: <CABcZeBNk5cv-i+_bEQYqKHRpbrdYWm2z8hbBRQJ7p+q05fUpWg@mail.gmail.com>
On Mon, Feb 3, 2014 at 4:04 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > 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. > I'm still finding myself confused about what you mean by "inspection APIs" Say, for instance, that I want the MediaRecorder to record at 192 kHz. So we have some mechanism for me to ask for that and then the browser gives me back a MediaRecorder with some properties it thinks are appropriate. Are you arguing that there should be some API that will allow me to interrogate the object and see what I got (which would have to exist for every constraint, presumably) or that I have to directly test the object for its properties, e.g., by passing in audio and then seeing if it retains the high frequencies? -Ekr
Received on Saturday, 8 February 2014 20:29:24 UTC