[whatwg] Timed tracks: feedback compendium

[Simon Pieters]

On Fri, 22 Oct 2010 12:48:02 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Fri, Oct 22, 2010 at 8:45 PM, Simon Pieters <simonp at opera.com> wrote:
>> On Fri, 22 Oct 2010 11:21:44 +0200, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>>
>>> Since the attributes in <track> are a hint, probably what is available
>>> in the file should overrule what is in the <track> attributes. It is
>>> the same for the @charset attribute, which is overruled to utf-8 for
>>> WebSRT IIRC.
>>
>> No, charset="" overrules the encoding for WebSRT per spec.
>
>
> Hmm... that makes sense for legacy SRT files, but not for modern WebSRT  
> files.

The idea is to support the legacy SRT files.


>> I don't see why we can't just consume the legacy and support it in  
>> WebSRT.
>> Part of the point with WebSRT is to support the legacy. If we don't  
>> want to
>> support the legacy, then the format can be made a lot cleaner.
>
>
> I'd actually much prefer we make a clean new format that doesn't start
> with having to deal with all the legacy of SRT.

Why?

Do you think browsers will support vanilla SRT as well? If yes, then  
making WebSRT incompatible seems like doing the quirks mode/standards mode  
mistake again to me (and eventually we'll have to specify vanilla SRT  
anyway, but are also stuck with yet another format to support).


> It can still be
> inspired by it though so we don't have to change much. I'd be curious
> to hear what other things you'd clean up given the chance.

WebSRT has a number of quirks to be compatible with SRT, like supporting  
both comma and dot as decimal separators, the weird parsing of timestamps,  
etc.

-- 
Simon Pieters
Opera Software