On Sep 9, 2010, at 6:08 AM, Silvia Pfeiffer wrote: > On Wed, Sep 8, 2010 at 9:19 AM, Ian Hickson <i...@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
