- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 20 Sep 2013 20:29:40 +1000
- To: Glenn Adams <glenn@skynav.com>
- Cc: Philip Jägenstedt <philipj@opera.com>, Simon Pieters <simonp@opera.com>, Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, Eric Carlson <eric.carlson@apple.com>
On Fri, Sep 20, 2013 at 5:32 PM, Glenn Adams <glenn@skynav.com> wrote: > > On Thu, Sep 19, 2013 at 9:21 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> > wrote: >> >> On Thu, Sep 19, 2013 at 12:11 AM, Philip Jägenstedt <philipj@opera.com> >> wrote: >> > On Wed, Sep 18, 2013 at 4:05 PM, Glenn Adams <glenn@skynav.com> wrote: >> >> >> >> On Wed, Sep 18, 2013 at 2:42 AM, Philip Jägenstedt <philipj@opera.com> >> >> wrote: >> >>> >> >>> On Wed, Sep 18, 2013 at 9:59 AM, Silvia Pfeiffer >> >>> <silviapfeiffer1@gmail.com> wrote: >> >>> > On Tue, Sep 17, 2013 at 10:15 PM, Philip Jägenstedt >> >>> > <philipj@opera.com> >> >>> > wrote: >> >>> >> On Tue, Sep 17, 2013 at 2:11 PM, Silvia Pfeiffer >> >>> >> <silviapfeiffer1@gmail.com> wrote: >> >>> >>> On Tue, Sep 17, 2013 at 6:01 PM, Philip Jägenstedt >> >>> >>> <philipj@opera.com> >> >>> >>> wrote: >> >>> >>>> On Tue, Sep 17, 2013 at 12:52 AM, Silvia Pfeiffer >> >>> >>>> <silviapfeiffer1@gmail.com> wrote: >> >>> >>>> >> >>> >>>>> UnparsedCue can be created by JS and the JS could try to add it >> >>> >>>>> to a >> >>> >>>>> track that has a @kind=captions. >> >>> >>>> >> >>> >>>> Why do we need to allow scripts to create UnparsedCue at all? >> >>> >>>> That >> >>> >>>> will require some new API surface that isn't needed to solve the >> >>> >>>> original use case -- in-band metadata tracks which aren't just a >> >>> >>>> special-case of a captioning format. >> >>> >>> >> >>> >>> It also allows JS devs to create @kind=metadata cues without >> >>> >>> having to >> >>> >>> decide to use a more specific format such as WebVTT. >> >>> >> >> >>> >> Given that UnparsedCue would be a strict subset of VTTCue, that >> >>> >> doesn't sound at all worth adding APIs for. >> >>> > >> >>> > It avoids developer confusion, which is sufficient reason for me. >> >>> > >> >>> > Here's another use case: when a browser exposes in-band text tracks >> >>> > through a @kind=metadata TextTrack, this allows developers to make >> >>> > corrections to the list of cues - add cues if necessary to e.g. fill >> >>> > gaps. >> >>> >> >>> It turns out I'm not up to date with what the spec says. addCue and >> >>> removeCue are now on the TextTrack interface and take a TextTrackCue, >> >>> whereas there used to be a function which created *and* added a cue. I >> >>> thought we'd need a new such function, but it's only a question of >> >>> whether or not UnparsedCue has a constructor. >> >>> >> >>> I would prefer if UnparsedCue was only ever used for in-band metadata >> >>> tracks of an unknown kind, but if browsers are going to expose the >> >>> UnparsedCue interface anyway, then exposing a constructor by that same >> >>> makes no difference, and would indeed be more consistent. >> >> >> >> >> >> Would it be better to call this interface RawCue or RawTextCue, so that >> >> it >> >> doesn't necessarily imply that it is not parsed? This would be useful >> >> to >> >> permit a rendered cue interface type (that exposes getCueAsHTML) to >> >> inherit >> >> from Raw{Text}Cue in order to provide the text attribute. >> >> >> >> I have specified a RawTTMLCue to serve this function (as a base >> >> interface >> >> for TTMLCue) in [1]. >> > >> > Hmm, this makes we wonder what the property for accessing the data is >> > supposed to be. If it's a string, then it requires that the UA at >> > least know what the encoding of the text is, which seems like it might >> > not be true. RawCue and exposing the data as a typed array .data >> > property seems OK to me. The other option is to base64-encode cues >> > which are of an unknown encoding, I guess? >> >> ArrayBuffer .data works for me. >> Should we keep .text as well, because converting from ArrayBuffer to >> String can be inefficient, see >> >> http://updates.html5rocks.com/2012/06/How-to-convert-ArrayBuffer-to-and-from-String >> ? >> >> Also, I am not fussed about the naming - RawCue works for me just like >> UnparsedCue. >> >> However, I would suggest not to inherit TTMLCue from RawCue, since as >> Simon pointed out earlier, you'd like JS devs to be able to do >> >> var raw_cue = cue instanceof RawCue; >> >> to detect that a cue is not taken care of by the UA. If TTMLCue >> inherits from it, that doesn't work. > > > But cue instanceof RawCue && ! cue instanceof TTMLCue would work. However, I > don't particularly like tying the cue type to assumptions about UA based > rendering support. In generally, it should be possible for an application to > perform its own rendering independently of whether the UA is capable of > rendering a track's cues (or a specific cue). I feel we haven't quite > resolved the matter of whether @kind captions/subtitles are always (and > only) rendered by UA and @kind metadata are never rendered by UA. While I > concur that it doesn't make sense for a UA to render @kind metadata, just > because a UA can render @kind captions/subtitles doesn't logically imply > that it should do so, particularly if application logic wants to perform its > own rendering or modify cue content prior to UA rendering. Allowing JS devs to turn off browser rendering is a separate issue from whether @kind=captions/subtitles/descriptions/chapters always has browser rendering support. As a JS dev, you can always turn off track rendering and take the content from the cue interface and do something with it yourself. Silvia.
Received on Friday, 20 September 2013 10:30:28 UTC