- From: Francois Daoust <fd@w3.org>
- Date: Thu, 09 Jul 2015 15:27:53 +0200
- To: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
- CC: public-webtiming@w3.org
On 2015-07-09 12:03, Ingar Mæhlum Arntzen wrote: [...] > Proposal 3) > > > Timing objects are connected to timed data by integrating directly with > existing TextTrack objects. Essentially, you should be able to get a > TextTrack object from a TimingObject just the way you currently would > get one from a MediaElement. > > > We have some reservations with this proposal. In the bigger picture, we > seek loose coupling between timing objects and time-sensitive > components. In proposal 2 we see this pattern clearly as media elements > explicitly takes direction from an externally referenced timing object. > We would ideally like this to be the case also for the TextTrack > integration. So, instead of adding a .addTextTrack() method to the > TimingObject we would instead like TextTrack objects to be constructed > with a “timingsrc” attribute or similar. This could be achieved in many > ways. For example, we could make a new constructor for the > TextTrackObject that takes a timingobject as parameter, or we could make > a TimedTextTrackObject wich combines timing with a normal TextTrackObject I think you managed to convince me here :) Trying to convert your idea into an interface, I understand that you mean something like this: [ Constructor (TextTrackKind kind, optional DOMString label = "", optional DOMstring language = "") ] interface TimedTextTrack : TextTrack { readonly attribute TimingObject timingsrc; } This would work. The temptation is great to propose that as an extension to the current TextTrack interface instead (as for media element), but I don't think we should introduce a constructor there for the time being. Having a constructor in a derived class is more common (as for HTMLAudioElement that derives from HTMLMediaElement). I'm pondering that against the possibility to define a sort of "Sequencer" as you had proposed initially, meaning something that would look like a media element without media: [ Constructor (optional TimingObject timing) ] interface Sequencer : EventTarget { readonly attribute TimingObject timingsrc; readonly attribute TextTrackList textTracks; TextTrack addTextTrack(TextTrackKind kind,optional DOMString label = "", optional DOMString language = "") }; The controls (currentTime, play, pause, playbackRate) are de facto provided by the timing object, so do not need to be duplicated here, although they could be introduced later on if people think that's needed for more consistency with the MediaElement interface. The advantages of the later version are that it preserves the "spirit" of how text tracks come into existence (through a call to "addTextTrack"), where they can be found (in a TextTrackList) and how they are processed (through the "time marches on" algorithm, although it will probably still need a couple of adjustments). At the same time, it introduces an intermediary class that is not truly necessary. The advantages of the former version are that it shows clearly what extensions would be needed to the TextTrack interface (a constructor and a new timingsrc attribute). I guess I'll give it a shot with the former version. Let me know if you prefer the later. Francois.
Received on Thursday, 9 July 2015 13:28:05 UTC