[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

Fri Aug 20 05:53:42 PDT 2010

On Wed, 18 Aug 2010 00:42:04 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Thu, Aug 12, 2010 at 6:09 PM, Philip Jägenstedt  
> <philipj at opera.com>wrote:
>
>> On Thu, 12 Aug 2010 02:11:55 +0200, Silvia Pfeiffer <
>> silviapfeiffer1 at gmail.com> wrote:
>>
>>  On Thu, Aug 12, 2010 at 1:26 AM, Philip Jägenstedt <philipj at opera.com
>>> >wrote:
>>>
>>>  On Wed, 11 Aug 2010 15:38:32 +0200, Silvia Pfeiffer <
>>>> silviapfeiffer1 at gmail.com> wrote:
>>>>
>>>>  On Wed, Aug 11, 2010 at 10:30 PM, Philip Jägenstedt  
>>>> <philipj at opera.com
>>>>
>>>>> >wrote:
>>>>>
>>>>>  On Wed, 11 Aug 2010 01:43:01 +0200, Silvia Pfeiffer <
>>>>>
>>>>>> silviapfeiffer1 at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>   Going with HTML in the cues, we either have to drop voices and  
>>>>>> inner
>>>>>
>>>>>> timestamps or invent new markup, as HTML can't express either. I  
>>>>>> don't
>>>>>> think
>>>>>> either of those are really good solutions, so right now I'm not
>>>>>> convinced
>>>>>> that reusing the innerHTML parser is a good way forward.
>>>>>>
>>>>>>
>>>>>
>>>>> I don't see a need for the voices - they already have markup in HTML,
>>>>> see
>>>>> above. But I do wonder about the timestamps. I'd much rather keep the
>>>>> innerHTML parser if we can, but I don't know enough about how the
>>>>> timestamps
>>>>> could be introduced in a non-breakable manner. Maybe with a data-
>>>>> attribute?
>>>>> Maybe <span data-t="00:00:02.100">...</span>?
>>>>>
>>>>>
>>>> data- attributes are reserved for use by scripts on the same page,  
>>>> but we
>>>> *could* of course introduce new elements or attributes for this  
>>>> purpose.
>>>> However, adding features to HTML only for use in WebSRT seems a bit  
>>>> odd.
>>>>
>>>
>>>
>>> I'd rather avoid adding features to HTML only for WebSRT. Ian turned  
>>> the
>>> <timestamps> into ProcessingInstructions
>>>
>>> http://www.whatwg.org/specs/web-apps/current-work/websrt.html#websrt-cue-text-dom-construction-rules
>>> .
>>> Could we introduce something like <?t at="00:00:02.100"?> without
>>> breaking
>>> the innerHTML parser?
>>>
>>
>> It appears that the innerHTML parser in at least Opera and Firefox  
>> handles
>> PIs in some manner, see test at <
>> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/587>
>>
>
> Chrome and Safari don't though.
>
>
>>
>> However, it isn't valid HTML, validator.nu says "Saw <?. Probable cause:
>> Attempt to use an XML processing instruction in HTML. (XML processing
>> instructions are not supported in HTML.)"
>
>
>
> Yeah, so the only conforming solution is probably to use CSS3
> transition-delay property. That may not be the most elegant solution,  
> but it
> works.

So, it seems clear that in order to use an HTML parser we have to  
sacrifice some features or make them more verbose. The whole of the WebSRT  
parser isn't very big or complicated, so I don't think implementation cost  
is a strong argument for reusing the HTML parser, especially since at  
least the timing syntax needs a separate parser.

>>  OTOH, if you say that it will take a short time for popular software to
>>> start ignoring the extra WebSRT stuff, well, in this case they have
>>> implemented WebSRT support in its most basic form and then there is no
>>> problem any more anyway. They will then accept the new files and their
>>> extensions and mime types and there is explicit support rather than the
>>> dodgy question of whether these SRT files will provide crap or not.  
>>> During
>>> a
>>> transition period, we will make all software that currently supports  
>>> SRT
>>> become unstable and unreliable. I don't think that's the right way to  
>>> deal
>>> with an existing ecosystem. Coming in as the big brother, claiming  
>>> their
>>> underspecified format, throwing in incompatible features, and saying:  
>>> just
>>> deal with it. It's just not the cavalier thing to do.
>>>
>>
>> I agree that it seems (and is) quite selfish, but am not sure the
>> alternatives are any better, see below. About "unstable and  
>> unreliable", I
>> think there are really only two kind of errors we will see:
>>
>> 1. Some cues being ignored due to trailing settings after the timestamp.
>>
>
> Some files may decide at this point that the files are not conformant and
> fail.
>
>
>>
>> 2. Markup being interpreted as plain text.
>>
>> Both already can and do happen with existing use of SRT, which is  
>> annoying
>> but better than no subtitles at all.
>
>
> It's a bit more than just annoying to users. If there are automated
> processes involved that print that stuff on tape for example, you can  
> burn
> through a lot of material and money before realising that your input  
> files
> are "broken" and if you cannot get software support for the new files
> implemented, you may need to implement costly manual checking of the  
> files.

SRT as it is today can and does contain broken timestamps, missing  
linebreaks and at least <i>, <b>, <u> and <font ...> markup, some of which  
is broken. If anyone is able to to rely on their input as being  
well-formed enough as to be put through automatic but costly processes,  
they'd have to have very good control of where their input comes from. I  
can't see how WebSRT would change that.

>> The core "problem" is that WebSRT is far too compatible with existing  
>> SRT
>> usage. Regardless of the file extension and MIME type used, it's quite
>> improbable that anyone will have different parsers for the same format.  
>> Once
>> media players have been forced to handle the extra markup in WebSRT  
>> (e.g. by
>> ignoring it, as many already do) the two formats will be the same, and  
>> using
>> WebSRT markup in .srt files will just work, so that's what people will  
>> do.
>> We may avoid being seen as arrogant format-hijackers, but the end  
>> result is
>> two extensions and two different MIME types that mean exactly the same
>> thing.
>
>
> It actually burns down to the question: do we want the simple SRT format  
> to
> survive as its own format and be something that people can rely upon as  
> not
> having "weird stuff" in it - or do we not. I believe that it's important
> that it survives. WebSRT can have absolutely anything in it, including  
> code
> and binary data, even if that stuff would not be interpreted in a  
> browser,
> but handed on to the JavaScript API for a JavaScript routine to do  
> something
> with it. It is a great extensible platform. But the advantage of SRT is  
> that
> it is simple and reliably simple. We completely remove this option by
> stealing the format.

I've collected some statistics on existing SRT content that I intend to  
publish soonish. For now, I'll just note that >50% contain some form of  
markup. Adding to this various ways in which the files could be broken, it  
seems to me that SRT as deployed is neither really simple nor reliable.  
Private use of SRT is of course simple and reliable, but that will be true  
in the future too.

Aside: WebSRT can't contain binary data, only UTF-8 encoded text.

>>  Since browser vendors get all the benefits and none of the problems it
>>>> would be a mistake to only listen to us, of course. It might be
>>>> worthwhile
>>>> contacting developers of applications like VLC, Totem or MPlayer and  
>>>> ask
>>>> precisely how annoyed they would be if suddenly one day they had to  
>>>> tweak
>>>> their SRT parser because of WebSRT.
>>>>
>>>
>>>
>>> Some of them have already spoken:
>>> http://forum.doom9.org/showthread.php?p=1396576 "Extending SRT is a  
>>> very
>>> bad
>>> idea" etc etc. Also, I've had feedback from other subtitle  
>>> professionals
>>> that are also against extending SRT, the main reasons being to break
>>> existing working software environments.
>>>
>>
>> The only way to really avoid messing with the ecosystem is to invent a
>> completely new format. The choice is between something that won't work  
>> at
>> all in non-browsers and something that will mostly work.
>
>
>
> If you look at it realistically, we *are* inventing a completely new  
> format.
> WebSRT only on the surface has some resemblance with SRT. When you dig
> deeper, it is a completely different format with different aims and
> applications. Yes, it covers all the SRT aims and applications, but it  
> does
> so much more! Only some of it will work in non-browsers, others will  
> utterly
> fail and will completely disrupt an already working ecosystem. I think it
> may even have a really bad effect if we introduce WebSRT as SRT in that
> authoring software will refrain from implementing support for the richer
> features in order not to disrupt the existing software ecosystem. In the  
> end
> we might end up with a lot of unsupported features in WebSRT an no real
> progress. I much prefer having progress with a transition period with
> conscious decisions to support the extra features.

As long as WebSRT is similar enough to SRT that software developers can  
use the same parser for both, they will effectively become the same  
format. If we define WebSRT in a way that can handle >99% of existing  
content and degrade gracefully (enough) when using new features in old  
software, it seems reasonable to do. If lots of software developers cry  
foul, then perhaps we should reconsider. It seems to me, though, that  
actually researching and defining a good algorithm for parsing SRT would  
be of use to others than just browsers.

I'll be back with some statistics this weekend, hopefully.

-- 
Philip Jägenstedt
Core Developer
Opera Software