- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Thu, 27 Mar 2014 20:20:43 +0000
- To: Dan Burnett <dburnett@voxeo.com>
- CC: Harald Tveit Alvestrand <harald@alvestrand.no>, Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On Mar 26, 2014, at 1:51 PM, Dan Burnett <dburnett@voxeo.com> wrote:
>
> On Mar 14, 2014, at 3:37 AM, Harald Alvestrand wrote:
>
>> On 03/13/2014 03:47 PM, Jan-Ivar Bruaroey wrote:
>>> 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.
>>
>> What about the "I want camera A, if I can't get that, camera B" case?
>>
>> The introduction of "ideal" as a third member of a min-max structure is possible in either proposal, but is another complexity point; I think this proposal needs to be thought of separately.
>>
>
> I don't remember who suggested it, but at TPAC there was a suggestion to allow values (not properties, values) for all types that would represent "the highest possible" and "the lowest possible". This is an interesting example of a completely orthogonal addition that trivially addresses the use case of "give me the highest value you can", without having to add another attribute such as ideal that only hints at what the user might actually want.
>
> E.g., {optional: [{aspectRatio: "highest"}, {width: "lowest"}]}
>
>
> I will leave this as a proposal for some one else or some future version rather than actually propose it now.
>
We have also discussed the actually specification giving advice on what to do when no constraints. So for example, a rule might be that a device SHOULD use the highest resolution possible within the limits set by the constraints.
Received on Thursday, 27 March 2014 20:21:11 UTC