[whatwg] Fwd: Discussing WebSRT and alternatives/improvements
philipj at opera.com
Thu Aug 26 03:18:34 PDT 2010
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
>> 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
> 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
More information about the whatwg