- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 09 Sep 2013 11:12:27 +0200
- To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "Glenn Adams" <glenn@skynav.com>
- Cc: "Brendan Long" <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, "Eric Carlson" <eric.carlson@apple.com>, Philip Jägenstedt <philipj@opera.com>
I just wanted to pop in and say that I basically agree with Glenn. On Sun, 08 Sep 2013 06:21:25 +0200, Glenn Adams <glenn@skynav.com> wrote: >> > You appear to be assuming that one needs a text attribute to mutate a >> cue. >> > As you probably know, a DocumentFragment may be mutated. The latter >> will >> be >> > much more effective in the case of TTML. Indeed. It means the DocumentFragment has to be live. I would suggest to use an IDL attribute annotated with [SameObject] to define it (in TTML2). > That's not because its the right thing to do or because it should be > maintained. They implemented it that way because they were working with > interface definitions (i.e., TextTrackCue in HTML5 CR1) that failed to > recognize the existence of non-VTT text tracks. In other words, they > applied the principle "If all you have is a hammer, everything looks > like a > nail." That seems likely, yeah. Easy to do, but with information loss and is obviously "wrong". > That won't work. The attributes of TextCue as based on VTTCue are not > sufficient and don't align with the attributes or semantics of other > formats. Indeed. For instance I think some formats do pixel-based positioning which WebVTT intentionally doesn't support. >> I'm just trying to find a solution that satisfies all user needs and >> will be implemented by browsers. >> > > Then I suggest we stop talking and you do the following: > > (1) change HTML 5.1 nightly's definition of TextTrackCue to align with > WHATWG flavor of the day, i.e., remove the constructor and text > attribute; > this solves the spec fork problem for this interface; Yes. > (2) define in HTML 5.1 nightly a new interface: > > [Constructor(double startTime, double endTime, DOMString text))] > interface UnparsedCue : TextTrackCue { > attribute DOMString text; > } > > if you don't like the name UnparsedCue, then change it to something else; Yes. For browsers that only support WebVTT and nothing else, this seems pretty useless since the same thing can be achieved using VTTCue as metadata, but I agree that it's "wrong" to use that interface for cues that are not in fact WebVTT and it's cheap to use a dedicated interface, and moreover script authors can use it for media time-aligned stuff that aren't captions without having to learn or think about WebVTT, so I support having it. > (3) if you wish, change VTTCue to inherit from UnparsedCue into order to > inherit its text attribute; No, I think that's confusing. Scripts should be able to do var unparsed = cue instanceof UnparsedCue; to detect that a cue is not taken care of by the UA. If VTTCue inherits from it, that doesn't work. > otherwise, define a text attribute directly on > VTTCue; Yes. > If you do these changes, then I think we can stop going round in circles, > and instead promote that UA implementers adopt these changes. -- Simon Pieters Opera Software
Received on Monday, 9 September 2013 09:05:57 UTC