Re: Possible Constraint Syntax Compromise

I think that Dom expressed a desire to use an attribute rather than a
method for accessing this information.  To do that, we can define an
interface rather than a dictionary.

(A type of set<DOMString> would be even better, but that's harder to use.)

On 21 May 2014 07:50, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
> I agree with Dan's explanation of WebIDL bindings and Peter's assessment of
> our choices at this juncture. I'll add that this API gives JS developers
> additional information (browser capabilities with virtually no
> fingerprinting issues) and gives it earlier (before gUM), making for better
> choices and a more desirable syntax (the latest sticking point).
>
> +1
>
> .: Jan-Ivar :.
>
>
> On 5/21/14 6:50 AM, Dan Burnett wrote:
>>
>> Jan-Ivar might want to comment here, as he has often explained that
>> Firefox does its parsing based on WebIDL and that an unknown constraint
>> disappears during that process.  As our standard list of constrainable
>> properties becomes more and more supported the need to check in advance for
>> such unknown constraints should also diminish, unless of course the
>> developer is specifically using a non-standard (e.g., experimental)
>> constraint.
>>
>> -- dan
>>
>> On May 20, 2014, at 9:16 PM, Timothy B. Terriberry wrote:
>>
>>> Peter Thatcher wrote:
>>>>
>>>> Out of those three, all the people I talked to preferred #3, which is
>>>> why I have proposed it.  If there is something we are all missing about
>>>> WebIDL that gives an easier exit from this conundrum, that would be
>>>> welcome news.
>>>
>>> No, it does not surprise me this is not expressible in WebIDL, so I guess
>>> it will not throw an exception. But we're still required by contract to call
>>> either the success or error callback, and what it sounded like you were
>>> saying was that the browser was free to ignore the constraint completely and
>>> return success.
>>>
>>
>
>
> --
> .: Jan-Ivar :.
>

Received on Wednesday, 21 May 2014 15:19:39 UTC