On Fri, 22 Oct 2010 12:48:02 +0200, Silvia Pfeiffer
<[email protected]> wrote:
On Fri, Oct 22, 2010 at 8:45 PM, Simon Pieters <[email protected]> wrote:
On Fri, 22 Oct 2010 11:21:44 +0200, Silvia Pfeiffer
<[email protected]> 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
