[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Silvia Pfeiffer]

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.



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



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



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

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100818/5720bcde/attachment-0002.htm>