W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2014

Re: [Bug 26577] New: imageCaptureError attribute shouldn't be nun-null.

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 15 Aug 2014 13:34:48 +0200
Message-ID: <53EDF058.7010306@alvestrand.no>
To: public-media-capture@w3.org
Does anyone know what the W3C traditions are with regard to event 
constructors?

I believe events are generally generated by the platform (which does 
what the platform does, and is not dependent on a Javascript-visible 
constructor) and by test scripts that want to inject events for testing 
event handling.

If that's correct, it should be OK to let it be "tester beware" - the 
platform can throw an "illegal argument error" when it doesn't have the 
information needed to construct the event, or fill in default values if 
that's its desire; it's only going to be done in tests anyway. No need 
to convolute the WebIDL.

But as I said - anyone who knows what the tradition actually is should 
chime in.


On 08/15/2014 05:17 AM, Jan-Ivar Bruaroey wrote:
> On 8/14/14 2:35 AM, bugzilla@jessica.w3.org wrote:
>> [Constructor(DOMString type, optional ImageCaptureErrorEventInit
>> imageCaptureErrorInitDict)]
>> interface ImageCaptureErrorEvent : Event {
>>      readonly    attribute ImageCaptureError imageCaptureError;
>> };
>>
>> How could imageCaptureError be non-null if imageCaptureErrorInitDict is
>> optional?
>
> I assume you mean non-nullABLE. Is your point that it needs to be:
>
>     readonly    attribute ImageCaptureError? imageCaptureError;
>
> or there's a question what the value is when constructed without 
> ImageCaptureErrorEventInit?
>
> We're inconsistent at least.  I had the opposite question [1] a while 
> back on MediaStreamEvent where the attribute IS nullable, but I came 
> around when I found the alternatives more complicated.
>
> So +1 on making it nullable.
>
> .: Jan-Ivar :.
>
> [1] http://lists.w3.org/Archives/Public/public-webrtc/2014Jul/0015.html
>
>
Received on Friday, 15 August 2014 11:35:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:29 UTC