On Thu, 26 Aug 2010 11:52:26 +0200, Henri Sivonen <hsivo...@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