[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Philip Jägenstedt]

On Thu, 26 Aug 2010 09:58:29 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:

> Silvia Pfeiffer wrote:
>> You misunderstand my intent. I am by no means suggesting that no
>> WebSRT
>> content is treated as SRT by any application. All I am asking for is a
>> different file extension and a different mime type and possibly a
>> magic
>> identifier such that *authoring* applications (and authors) can
>> clearly
>> designate this to be a different format, in particular if they include
>> new
>> features. Then a *playback application* has the chance to identify
>> them as a
>> different format and provide a specific parser for it, instead of
>> failing
>> like Totem. They can also decide to extend their existing SRT parser
>> to
>> support both WebSRT and SRT. And I also have no issue with a user
>> deciding
>> to give a WebSRT file a go by renaming it to .srt.
>>
>> By keeping WebSRT and SRT as different formats we give the
>> applications a
>> choice to support either, or both in the same parser. If we don't, we
>> force
>> them to deal in a single parser with all the oddities of SRT formats
>> as well
>> as all the extra features and all the extensibility of WebSRT.
>
> Why wouldn't it always be a superior solution for all parties to do the  
> following:
>  1) Make sure WebSRT never requires processing that'd require rendering  
> a substantial body of legacy .srt content in a broken way. (This would  
> require supporting non-UTF-8 encodings by sniffing as well as supporting  
> <font> and <u>, which would happen "for free" if my innerHTML proposal  
> were adopted.)
>  2) Make playback software that supports WebSRT only have a WebSRT code  
> path and use that code path for legacy .srt content as well.
> ?
>
> Specifically, if #1 is done, why would any pragmatic developer not want  
> to do #2 if they are supporting WebSRT in their software? Why would  
> anyone want to have a code path that turns off new WebSRT features if  
> they have a code path that supports WebSRT features?

I think many media player developers would be hesitant to include a full  
HTML parser just for parsing (Web)SRT, especially since they'd also need a  
layout engine to get anything more than they would get from a simpler  
parser.

I do think it's a good idea to make the WebSRT handle existing SRT content  
as well as possible. The encoding issue is easy to side-step by just  
saying that that's a preprocessing step.

> Or is #1 *impossible* due to the craziness of the legacy? (I thought any  
> given .srt consumer only has a single code path and implemetation-wise  
> there aren't already multiple .srt format even though doom9 spec-wise  
> there are at least two.)

There are some issues with the current WebSRT parser that I've been  
meaning to send mail about, but by my impression is that it's not  
impossible to define a parser which works well enough to replace existing  
ones.

-- 
Philip Jägenstedt
Core Developer
Opera Software