[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Anne van Kesteren]

On Wed, 11 Aug 2010 13:35:30 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:
> On Wed, Aug 11, 2010 at 7:31 PM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> While players are transitioning to WebSRT they will ensure that they do  
>> not break with future versions of the format.
>
> That's impossible, since we do not know what future versions will look  
> like and what features we may need.

If that is impossible it would be impossible for HTML and CSS too. And  
clearly it is not.


> I'm pretty sure that several will break. We cannot just test a handful of
> available applications and if they don't break assume none will. In fact,
> all existing applications that get loaded with a WebSRT file with  
> extended features will display text with stuff that is not expected - in  
> particular if the "metadata" case is used. And wrong rendering is bad,  
> e.g. if it's
> part of a production process, burnt onto the video, and shipped to
> hearing-impaired customers. Or stored in an archive.

Sure, that's why the tools should be updated to support the standard  
format instead rather than each having their own variant of SRT.

(And if they really just take in text like that they should at least run  
some kind of validation so not all kinds of garbage can get in.)


>> I don't think so. It just makes things more complex for authors (learn  
>> two formats,
>
> I see that as an advantage: I can learn the simple format and be off to a
> running start immediately. Then, when I find out that I need more  
> features, I can build on top of already existing knowledge for the  
> richer format and can convert my old files through a simple renaming of  
> the resources.

Or could you learn the simple format from a tutorial that only teaches  
that and when you see someone else using more complex features you can  
just copy and paste them and use them directly. This is pretty much how  
the web works.


>> have to convert formats (i.e. change mime) in order to use new features
>> (which could be as simple as a <ruby> fragment for some Japanese track)
>
> If I know from the start that I need these features, I will immediately
> learn WebSRT.

But you don't.


>> , more complex for implementors (need two separate implementations as to
>> not encourage authors to use features of the more complex one in the  
>> less
>> complex one), more complex for conformance checkers (need more code),  
>> etc.
>> Seems highly suboptimal to me.
>
> That's already part of Ian's proposal: it already supports multiple
> different approaches of parsing cues. No extra complexity here.

Actually that is not true. There is only one approach to parsing in Ian's  
proposal.


> My theory is: we only implement support for WebSRT in the browser - that  
> it happens to also support SRT is a positive side effect. It works for  
> the Web - and it works for the existing SRT communities and platforms.  
> They know
> they have to move to WebSRT in the long run, but right now they can get  
> away with simple SRT support and still deliver for the Web. And they  
> have a
> growth path into a new file format that provides richer features.

This is the proposal. That they are the same format should not matter.


-- 
Anne van Kesteren
http://annevankesteren.nl/