Re: Displaying multiple lines in WebVTT

On Tue, 1 May 2012, Glenn Maynard wrote:
> On Mon, Apr 30, 2012 at 11:18 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > Note that this may be a cultural thing. In some cultures, e.g. French, 
> > dashes are actually used pretty much wherever there is dialog, not 
> > just in captions ("quotation dash"). In English, I've only seen them 
> > in captions. This may account for our relative familiarity with the 
> > construct.
> 
> It must be, because I've never seen it in ten years or so of watching 
> subtitled video.

The example I gave earlier in this thread came from an English-language 
DVD of a major television franchise, so I don't think it's rare. I started 
watching the subtitles from where I was at in the episode, and only had to 
wait a few seconds before one of the cues had two lines with a quotation 
dash preceding each one.


> > > > Using <br> has some short-term benefits, but I tend to think that 
> > > > actual newlines will make more sense in the long term for a 
> > > > strongly line-oriented format...
> > >
> > > WebVTT is much more block-oriented than line-oriented.  For a 
> > > line-oriented captioning format, look at SSA.
> >
> > I don't really see what distinction you are drawing here.
> 
> He said it's a line-oriented format; I simply disagreed and explained 
> why. There's nothing more to read into it...

I don't understand what "line-orientated format" means if WebVTT isn't 
one. Can you elaborate on this, for my own edification?


> > This is the cruck of the argument I would make against <br>. It's not 
> > great syntax, and it doesn't have any compelling advantages. People 
> > porting SRT habits to VTT isn't a huge problem, IMHO. At least, not as 
> > much of a problem as those introduced by <br>, such as having line 
> > breaks not match where the physical line breaks are in the source.
> 
> I don't see how that's a problem.  Newlines aren't (ordinarily) line 
> breaks in HTML; everyone's used to it and it works well.

I'm not sure I buy "it works well" about HTML. Also, I'm not sure I really 
understand HTML's relevance here. HTML is a tree-based structured markup 
language. VTT is a text language with some minor inline annotations.


> > So far, no compelling use cases have been made for inline comments at 
> > all, and some pretty compelling arguments have been made to discourage 
> > us from providing such a feature at all.
> 
> There are definitely compelling use cases (which I gave before): being 
> able to put comments at any point in a caption (so the comment is 
> contextual)

That's not a use case for the feature, that's the feature itself.


> being able to view comments as part of rendered captions (which is 
> useful when reviewing captions).

That's an argument for the inline syntax with CSS to hide things, not for 
inline comments.


> As an aside: do the rendering rules say what happens if the style of 
> cues is changed by script (or the UA, too, I suppose), causing it to 
> change size (spans losing display: none, changing font size, etc)?

Yes. Nothing happens to the boxes, but the resulting rendering would 
change. I expect this will change based on implementor feedback.


> I havn't fully parsed out the rendering rules (so this may not make 
> sense), but it seems like it would need to trigger "reset" in the 
> rendering rules (or clear the text track cue display state) so the cues 
> are laid out from scratch.

That's a possible way it might change. Doing that is awkward because we 
would have to define precisely what is to be considered a style sheet 
change that should trigger a reset. It would be unfortunate if someone 
tweaking a colour being animated in a completely non-video-related cue 
caused subtitles to keep jumping around.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 1 May 2012 05:42:50 UTC