On Thu, 26 Aug 2010 09:58:29 +0200, Henri Sivonen <[email protected]> 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
