Re: Displaying multiple lines in WebVTT

I strongly support spec'ing/implementing balanced line wrapping a the  
default for WebVTT. As for line-wrapping, I'm inclined to agree that  
requiring <br> will have long-term benefits and will not object to it.  
However, I expect we will initially also see some SRT content ported to  
WebVTT without manual intervention, causing some cues like this to end up  
on a single line:

00:32.000 --> 00:35.000
- What should we do?
- Let's go shopping!

Philip

On Thu, 19 Apr 2012 01:52:08 +0200, David Singer <singer@apple.com> wrote:

> OK, I am cool.  I was just leaning towards simplicity, but these are  
> good arguments.  Others?
>
>
> On Apr 18, 2012, at 22:54 , Glenn Maynard wrote:
>
>> On Wed, Apr 18, 2012 at 1:23 AM, David Singer <singer@apple.com> wrote:
>> I think some have argued that author line-breaks should not be  
>> permitted or possible in the content itself.
>>
>> (I don't think anyone is arguing that.)
>>
>> We're not writing paragraphs, such as in HTML, where inserting line  
>> breaks in the source is sometimes desirable to make the source  
>> readable, and then they need converting to whitespace. Cues need to be  
>> 'short'.
>>
>> So I am not sure we need (a), which means we don't need (b), which  
>> means, for me, that (c) is fine; if you author a line-break, you meant  
>> it.
>>
>> Again, the problem with this is that it will result in a huge number of  
>> caption files being manually word wrapped.  It will cause people to  
>> hand-wrap captions where there's no need for it, which will make many  
>> WebVTT files break when viewed in larger fonts than the author happened  
>> to be using.  Using explicit <br> will make it clear to authors that,  
>> like HTML, you should usually be leaving wrapping to the UA and only  
>> use <br> when you explicitly need a break for reasons other than  
>> word-wrapping.
>>
>> I'm pretty confident in this prediction; many VTT users are going to be  
>> previous SRT users.  With SRT you *were* required to do word wrapping  
>> yourself, which I think is obviously unacceptable on the Web, where you  
>> can never make hard assumptions about users' font sizes (or other  
>> aspects of font rendering).
>>
>> We can fix this easily now, by making the intuitive usage of the format  
>> the correct one, or we can give ourselves headaches trying to convince  
>> people to stop doing things incorrectly later (which doesn't work on  
>> the Web).
>>
>> --
>> Glenn Maynard
>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>


-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 19 April 2012 09:11:40 UTC