Re: Displaying multiple lines in WebVTT

On Mon, Apr 30, 2012 at 11:18 PM, Ian Hickson <ian@hixie.ch> wrote:

> That's why they have dialogue dashes in front of them.
>

> 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.

> > 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...

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.

> It'd also be nice to be able to have inline comment blocks
>
> 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.
>

This isn't anything new; it's using cue spans to implement inline comments,
which is what we landed on before and why I stopped pushing for a
specialized inline comment syntax.  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) and being able to view comments as
part of rendered captions (which is useful when reviewing captions).

(It should have been <c.comment>, I think.  Could use some more examples in
the spec...)

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)?  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.

-- 
Glenn Maynard