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

Re: Use of "required" dictionary attributes for events

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 9 Sep 2014 20:20:44 +0000 (UTC)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <alpine.DEB.2.00.1409092018380.28228@ps20323.dreamhostps.com>
On Tue, 9 Sep 2014, Tab Atkins Jr. wrote:
> On Tue, Sep 9, 2014 at 7:17 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> >
> >   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;
> >   };
> >
> > 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.

No, it's just because I come from a background of languages where all 
reference types are always nullable, so I always forget to mark things as 
nullable because the idea that something might not be is weird to me.


> It doesn't seem particularly useful to initialize a track event without 
> a track, so I'm fine with making track required and not nullable.

What about if you want to use this for an event like 'selected' which 
contains the currently selected track and it's possible to select none?

Events objects aren't only used for their original spec purposes, they are 
reusable by author code.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 9 September 2014 20:21:07 UTC

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