Re: Displaying multiple lines in WebVTT

On Tue, May 1, 2012 at 12:42 AM, Ian Hickson <ian@hixie.ch> wrote:

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

WebVTT is a series of blocks separated by empty lines.  If it was really a
line-oriented format, it'd seem odd to me that spans aren't reset at the
end of a line, for example.  The only thing that makes VTT seem
line-oriented is the white-space: pre-wrap; the actual cue data format
doesn't care.

In short, I don't think the argument "\n not acting as a line break is bad
because VTT is line-oriented" makes sense, because the very behavior of \n
acting as a line break is the main thing making it seem line-oriented in
the first place.

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

VTT is also a tree-based markup language, just a much simpler and less
expressive one.

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

I'm sure we've been over this; the point is for authors to be able to leave
notes for other editors, eg. notes (explanations of a translation, so
editors don't change things incorrectly) and editing requests ("this
translation is awkward, somebody fix it").

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

No, it's a use case for comments.  I want to be able to toggle whether
comments are displayed within the cue at runtime, or if I want to see the
captions as they'll normally appear to viewers.

(I'm not sure what you're arguing against.  I'm not asking for any new
feature; this is just using spans--an existing feature--to implement
comments.)

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

I guess I'd expect it to only reset the layout if the size of the contents
of the cues has changed.


On Wed, May 2, 2012 at 1:46 AM, Simon Pieters <simonp@opera.com> wrote:

> 'display' and 'font-size' is not in the list of properties that apply to
> ::cue or ::cue(). So 'display' cannot change. I think the only way
> 'font-size' can change is if the user changes the minimal font size setting
> (if it applies to cues, which I think it should) or has it set and the size
> of the video changes.
>

"display: none" should really be in there.

It probably shouldn't support every other display mode, though.  It's also
annoying that you'd have to carefully handle Ruby nodes when overriding an
earlier "display: none" rule.  This really wants to be its own property;
mixing "display: none" in with the rest of the display modes is one of the
more annoying mistakes from CSS history.

-- 
Glenn Maynard