[whatwg] Timed tracks: feedback compendium

[Eric Carlson]

On Sep 9, 2010, at 6:08 AM, Silvia Pfeiffer wrote:

> On Wed, Sep 8, 2010 at 9:19 AM, Ian Hickson <ian at hixie.ch> wrote:
> 
> On Fri, 23 Jul 2010, Philip Jägenstedt wrote:
> >
> > I'm not a fan of pauseOnExit, though, mostly because it seems
> > non-trivial to implement. Since it is last in the argument list of
> > TimedTrackCue, it will be easy to just ignore when implementing. I still
> > don't think the use cases for it are enough to motivate the
> > implementation cost.
> 
> Really? It seems like automatically pausing video half-way would be a very
> common thing to do; e.g. to play an interstitial ad, or to play a specific
> sound effect in a sound file containing multiple sound effects, or to play
> a video up to the point where the user has to make a choice or has to ask
> to move on to the next slide. There's basically no good way to do this
> kind of thing without this feature.
> 
> Also, some text cues will be fairly long and thus certain users cannot read them within the allocated time for the cue. So, making a pauseOnExit() available is a good thing for accessibility.
> 
  I have never been a huge fan of pauseOnExit, but on reflection I agree that it is important because event latency will make it difficult or impossible to replicate the functionality in script.



>  > > On Fri, 31 Jul 2009, Silvia Pfeiffer wrote:
> > > >
> > > > * It is unclear, which of the given alternative text tracks in
> > > > different languages should be displayed by default when loading an
> > > > <itext> resource. A @default attribute has been added to the <itext>
> > > > elements to allow for the Web content author to tell the browser
> > > > which <itext> tracks he/she expects to be displayed by default. If
> > > > the Web author does not specify such tracks, the display depends on
> > > > the user agent (UA - generally the Web browser): for accessibility
> > > > reasons, there should be a field that allows users to always turn
> > > > display of certain <itext> categories on. Further, the UA is set to
> > > > a default language and it is this default language that should be
> > > > used to select which <itext> track should be displayed.
> > >
> > > It's not clear to me that we need a way to do this; by default
> > > presumably tracks would all be off unless the user wants them, in
> > > which case the user's preferences are paramount. That's what I've
> > > specced currently. However, it's easy to override this from script.
> >
> > It seems to me that this is much like <video autoplay> in that if we
> > don't provide a markup solution, everyone will use scripts and it will
> > be more difficult for the UA to override with user prefs.
> 
> What would we need for this then? Just a way to say "by the way, in
> addition to whatever the user said, also turn this track on"? Or do we
> need something to say "by default, override the user's preferences for
> this video and instead turn on this track and turn off all others"? Or
> something else? It's not clear to me what the use case is where this
> would be useful declaratively.
> 
> 
> You have covered all the user requirements and that is good. They should dominate all other settings. But I think we have neglected the authors. What about tracks that the author has defined and wants activated by default for those users that don't have anything else specified in their user requirements? For example, if an author knows that the audio on their video is pretty poor and they want the subtitles to be on by default (because otherwise a user may miss that they are available and they may miss what is going on), then currently they have to activate it with script. 
> 
> A user whose preferences are not set will thus see this track. For a user whose preferences are set, the browser will turn on the appropriate tracks additionally or alternatively if there is a more appropriate track in the same language (e.g. a caption track over the default subtitle track). If we do this with script, will it not have the wrong effect and turn off what the browser has selected, so is not actually expressing author preferences, but is doing an author override?
> 
  I agree. It is important for a page author to be able to mark the default in case none of the alternates match user preferences. FWIW this is the way that alternate track groups work in MPEG-4 and QuickTime files - one track in a group is enabled by default but is disabled if another track in the group is enabled.


>  
> > Alternatively, might it not be better to simply use the voice "sound"
> > for this and let the default stylesheet hide those cues? When writing
> > subtitles I don't want the maintenance overhead of 2 different versions
> > that differ only by the inclusion of [doorbell rings] and similar.
> > Honestly, it's more likely that I just wouldn't bother with
> > accessibility for the HoH at all. If I could add it with <sound>doorbell
> > rings, it's far more likely I would do that, as long as it isn't
> > rendered by default. This is my preferred solution, then keeping only
> > one of kind=subtitles and kind=captions. Enabling the HoH-cues could
> > then be a global preference in the browser, or done from the context
> > menu of individual videos.
> 
> I don't disagree with this, but I fear it might be too radical a step for
> the caption-authoring community to take at this point.
> 
> I think we have to get over the notion that the existing subtitling community is our target for this format. In fact, the new subtitling community are all the Web developers out there. They are the ones we should target and for them we should make things easier.
> 
+1


> On Mon, 26 Jul 2010, Silvia Pfeiffer wrote:
> > > On Thu, 16 Jul 2009, Silvia Pfeiffer wrote:
> > >> * the "type" attribute is meant to both identify the mime type of the
> > >> format and the character set used in the file.
> > >
> > > It's not clear that the former is useful. The latter may be useful; I
> > > haven't supported that yet.
> >
> > If the element is to support a single format in a single character set,
> > then there is no need for a MIME type. So, we need to be clear whether
> > we want to restrict our option here for multiple formats.
> 
> As specified the spec supports multiple formats, it just only talks about
> WebSRT currently. (If it becomes likely that browsers will have different
> sets of supported formats, we can add a type="" attribute to help browsers
> find the right files without checking each one, but that's not necessary
> unless that becomes a likely problem.)
>  
> OK, understood.
> 
"type"  will definitely be necessary if we use <track> for other media types, eg. for sign language video, descriptive audio, etc.


> On Mon, 23 Aug 2010, Philip Jägenstedt wrote:
> >
> > I don't expect that SVG, <canvas>, images, etc will ever natively be
> > made part of captions. Rather, I would hope that the metadata state
> > together with scripts is used. If we think that e.g. images in captions
> > are an important use case, then WebSRT is not a good solution.
> 
> Indeed.
> 
> Images in captions will be used, I can guarantee that.
> 
Images are already commonly used in chapter menus.

eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100910/80856476/attachment-0002.htm>