- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 22 Oct 2010 13:04:37 +0200
On Fri, 22 Oct 2010 12:48:02 +0200, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > On Fri, Oct 22, 2010 at 8:45 PM, Simon Pieters <simonp at opera.com> wrote: >> On Fri, 22 Oct 2010 11:21:44 +0200, Silvia Pfeiffer >> <silviapfeiffer1 at gmail.com> wrote: >> >>> Since the attributes in <track> are a hint, probably what is available >>> in the file should overrule what is in the <track> attributes. It is >>> the same for the @charset attribute, which is overruled to utf-8 for >>> WebSRT IIRC. >> >> No, charset="" overrules the encoding for WebSRT per spec. > > > Hmm... that makes sense for legacy SRT files, but not for modern WebSRT > files. The idea is to support the legacy SRT files. >> I don't see why we can't just consume the legacy and support it in >> WebSRT. >> Part of the point with WebSRT is to support the legacy. If we don't >> want to >> support the legacy, then the format can be made a lot cleaner. > > > I'd actually much prefer we make a clean new format that doesn't start > with having to deal with all the legacy of SRT. Why? Do you think browsers will support vanilla SRT as well? If yes, then making WebSRT incompatible seems like doing the quirks mode/standards mode mistake again to me (and eventually we'll have to specify vanilla SRT anyway, but are also stuck with yet another format to support). > It can still be > inspired by it though so we don't have to change much. I'd be curious > to hear what other things you'd clean up given the chance. WebSRT has a number of quirks to be compatible with SRT, like supporting both comma and dot as decimal separators, the weird parsing of timestamps, etc. -- Simon Pieters Opera Software
Received on Friday, 22 October 2010 04:04:37 UTC