- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 13 Mar 2014 10:47:06 -0400
- To: Harald Alvestrand <harald@alvestrand.no>, public-media-capture@w3.org
On 3/13/14 5:45 AM, Harald Alvestrand wrote: > One of the interesting things you've introduced in this proposal is > representing attribute names as both strings and attributes, in order > to implement the "require" and "prefer" methods. This is unstylish. I think it is stylish to follow the rules here. Dictionary keys being inherently optional can't be used to fashion a requirement list, because the browser wont see requirements it doesn't know. A string survives. It also accomplishes the stated goal from our last teleconference, which was to "make mandatory harder to use" (a poorly worded way of saying "lets avoid people falling into mandatory and its sharp 'I mean it!' edges by default). > Another interesting property is that you have lost the ability to > propose an order in which to try alternative values for the same > attribute. This is a loss of functionality. A loss in complexity that should affect no known use-cases, hence a win. For example, lets compare a "I prefer higher frame rates" use-case, first with existing constraints: var constraints = { video: { optional: [ { aspectRatio: 16/9 }, { frameRate: { min: 300 } }, { frameRate: { min: 200 } }, { frameRate: { min: 100 } }, { frameRate: { min: 60 } } ] } }; navigator.getUserMedia(constraints, success, failure); Yes, that's {{[{{}}]}}, giving lisp a stylish run for its money. With constraints, you had to put, in the optional part, the same parameter (e.g. frameRate) several times with gradually decreasing values. The number of values you had to provide seem arbitrary, but may in fact no be, as you have to coax the algorithm to go up instead of down. If a device supports a band of resolutions that are close together, then this may in fact not pick the highest available resolution. Fail. Compare to: var request = { aspectRatio: 16/9, frameRate: { min: 60, ideal: 300 }, }; navigator.getUserMedia(request, success, failure); In dictionaries, multiple entries are not allowed, so to get higher frame-rates, you express intent with the "ideal" key, creating an upward pull toward 300 hz, favoring higher frame-rates to lower ones. This expresses intent better than the old design's repetition of gradually decreasing values. The "ideal" key also avoids overloading "min" and "max" with gravitational meaning, which, while never expressed, seems to confound many people (e.g. people assuming "if I specify max 120hz, then I should get 120 hz if I can, because why not?", which doesn't match my understanding of the current spec or what's been implemented thus far. Let me know if you have other questions or want me to post clarifications. .: Jan-Ivar :.
Received on Thursday, 13 March 2014 14:47:35 UTC