W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 26 Aug 2010 00:58:29 -0700 (PDT)
Message-ID: <1204004504.386003.1282809509820.JavaMail.root@cm-mail03.mozilla.org>
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?

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.)

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Thursday, 26 August 2010 00:58:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC