[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Philip Jägenstedt]

On Thu, 26 Aug 2010 11:52:26 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:

>> > 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.
>
> If their app can ingest both WebSRT and legacy SRT (with WebSRT ingested  
> by whatever potentially spec-incompliant means), why would they not use  
> the same ingest code path for both?

I don't they should or would, I'm just saying that they'd probably be  
hesitant to use an HTML parser in that single code path, as there's very  
little benefit for them.

> If the app isn't capable of supporting any feature that's permitted in  
> WebSRT but not part of legacy SRT, how does failing at the point of  
> finding out that "this file claims to be WebSRT rather than SRT" make  
> things much better than failing at "I found stuff that I can't  
> handle/skip over in this SRT file"?
>
> In particular, it seems like a wrong optimization to make it possible  
> for apps that don't support any WebSRT features over legacy features to  
> fail early than to make apps that support at least one WebSRT-introduced  
> feature unify their processing of WebSRT and SRT by processing both  
> WebSRT and SRT as one format where legacy SRT files just don't happen to  
> use new features.
>
> To me, having different code paths for WebSRT and SRT is like IE adding  
> a new Trident snapshot with every release whereas supporting SRT by  
> treating it as WebSRT with no new features (if the app is supporting  
> even one WebSRT-introduced feature!) is like what the other browsers are  
> doing with HTML/CSS/DOM.

Is this in reply to something other than what you quoted? In any case, I  
agree.

-- 
Philip Jägenstedt
Core Developer
Opera Software