W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Use of "required" dictionary attributes for events

From: Olli Pettay <olli@pettay.fi>
Date: Tue, 09 Sep 2014 19:31:22 +0300
Message-ID: <540F2B5A.8000304@pettay.fi>
To: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
CC: Ian Hickson <ian@hixie.ch>
On 09/09/2014 05:17 PM, Boris Zbarsky wrote:
> Now that we have the idea of "required" dictionary attributes, it seems like they can be used to solve a long-lasting pain point with event constructors.
>
> Consider this IDL from the webapps spec:
>
>    dictionary TrackEventInit : EventInit {
>      (VideoTrack or AudioTrack or TextTrack) track;
>    };
>
>    [Constructor(DOMString type, optional TrackEventInit eventInitDict)]
>    interface TrackEvent : Event {
>      readonly attribute (VideoTrack or AudioTrack or TextTrack) track;
>    };
>
> with accompanying prose that says:
>
>    The track attribute must return the value it was initialised to.
>    When the object is created, this attribute must be initialised to
>    null. It represents the context information for the event.
>
> There's an obvious mismatch between the prose and the IDL here: The prose wants to init to null, but the IDL wants to claim that null is never
> returned.  Presumably this is because the actual uses of this event in the spec then go ahead and set the track attribute to a non-null value... but
> that doesn't help script that uses the constructor; in that situation the spec is just self-contradictory.
>
> Gecko resolves this problem at the moment by making the "track" attribute in both the dictionary and the interface nullable.
>
> However, now that we have the ability to require attributes in dictionaries it seems like we could do:
>
>    dictionary TrackEventInit : EventInit {
>      required (VideoTrack or AudioTrack or TextTrack) track;
>    };
>
> and remove the bits about null, since now the constructor will always have a track to work with.
>
> Making the attribute nullable, with a default value of null, means you can do this:
>
>    var ev = new TrackEventInit();

I assume you mean
var ev = new TrackEvent("foobar");


>
> without having to pass a dictionary.  On the other hand it also means that you can create a TrackEvent with a null track.  Making the attribute
> non-nullable but required means that you have to do something like:
>
>    var ev = new TrackEventInit({ track: something });
and here
var ev = new TractEvent("foo", { track: something });


But yes, sounds like a valid use case for 'required' in dictionaries.
(And now we need to update the event implementation codegenerator in Gecko to support required properties)


-Olli




>
> to create a TrackEvent, but guarantees that all TrackEvents have a useful .track...
>
> Do people have a preference for one or the other of these solutions in designing event APIs?  What about other constructor APIs that take dictionary
> arguments?
>
> -Boris
>
Received on Tuesday, 9 September 2014 16:31:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC