[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Henri Sivonen]

> > 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?

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.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/