W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2013

Re: Why ignoring unknown mandatory constraints is not stupid

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Tue, 26 Nov 2013 00:51:36 +0000
To: Adam Roach <adam@nostrum.com>
CC: Harald Alvestrand <harald@alvestrand.no>, Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <F7F2273F-81D0-4C0D-8785-725834CD8008@cisco.com>

On Nov 17, 2013, at 2:15 PM, Adam Roach <adam@nostrum.com> wrote:

> Now, my application ends up running inside a browser that doesn't yet know what this mandatory "facing mode" constraint means.
> 
> What do you think should happen?

It needs to get an error if it is mandatory. That is the only way the application can find out that this browser has no clue of what facing mode means. I agree that most application will not need to make facing mode mandatory but some constraints they will. Apps need a way of forming a contract with the browser on what the browser will do. 

If some application is going to take range data from a 3d camera, it really needs to know it is range data not image data. Feeding RGB into an application that expect range data is going to fail - the user does not know better and no it is is not appropriate for the browser to tell the user to send things to the application that are not going to work. The user will not have a reasonable experience with this case and the will phone the app developer to complain. The app developer will get sick of the "you apps sucks in browsers" phone calls because there will be absolutely no way for the developer to make there app not suck in browsers. The only thing they will be able to do is abandon HTML5 and use native apps.

The general attitude on this list of developers are stupid and we know better than them is sort of really irrupting. But the view point of for the developers that are not stupid, we are going to make it impossible for them deliver a good user experience is just not OK. If the app says it must have lama mode, and the browser has no idea what lama mode means, the application needs some way of discovering that. If lama mode where a single supported or not supported issue, one could have a capabilities call that told you about this. But if it gets more complicated as a range on things, or something that can be done some of the time but not others, it is hard to have it as a separate capabilities call. 

Lets say we had a video constraint that turned on and off a light and we were on a device with a light and browser that supported it. Some apps can work if they can not set this. But the flashlight app pretty much has to be able to turn it on. If it can not turn the light on, it needs to get an error so it can explain that it won't work because some other app is controlling the light. Having the application thing the light is on, but the light is actually off, is an terrible user experience and results in people not wanting to use HTML5 to build the flashlight app because you can reliably make it work. Detecting that the browser and device it is running on support the light feature is not enough. 
Received on Tuesday, 26 November 2013 00:52:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC