[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Silvia Pfeiffer]

On Mon, Aug 23, 2010 at 6:55 PM, Philip Jägenstedt <philipj at opera.com>wrote:

> On Sat, 21 Aug 2010 01:32:49 +0200, Silvia Pfeiffer <
> silviapfeiffer1 at gmail.com> wrote:
>
>  On Fri, Aug 20, 2010 at 10:53 PM, Philip Jägenstedt <philipj at opera.com
>> >wrote:
>>
>>  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:
>>>>
>>>> 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.
>>>
>>
>>
>> That sounds like there are multiple problems, when in fact we are only
>> talking about the single use case of timestamps.
>>
>
> I was referring also to the voices markup which is made much more verbose.


Yeah, but that one actually makes sense to be integrated with existing ways
that class and CSS work.


I don't expect that SVG, <canvas>, images, etc will ever natively be made
> part of captions. Rather, I would hope that the metadata state together with
> scripts is used. If we think that e.g. images in captions are an important
> use case, then WebSRT is not a good solution.
>

I believe they will be. But since we are only looking at the ways in which
captions and subtitles are used currently, we haven't accepted this as an
important use case, which is fair enough. I am considering likely future use
though, which is always hard to argue.



> If we allow arbitrary HTML and expect browsers to handle it well, it adds
> some complexity. For example, any videos and images in the cue would have to
> be fully loaded and ready to be decoded by the time the cue is to be shown,
> which I really don't want to implement the logic for. Simply having an
> iframe-like container where the document is replaced for each cue wouldn't
> be enough, rather one would have to create one document per cue during
> parsing and wait for all of those to finish loading before beginning
> playback. I'm not sure, but I'm guessing that amounts to significant memory
> overhead.
>

I have to leave that discussion to others, since I don't know enough about
how the plumbing used in browsers works together. My expectation was that
most of the plumbing with innerHTML already exists and the loading/display
of the cue will be in parallel to the video playback, so it won't hold back
the main page, even if e.g. a img element cannot be loaded in time.



>
> Honestly, using the existing small mess around SRT as an excuse to turn it
>> into a huge mess doesn't seem a good argument to me.
>>
>
> I'm just saying that SRT isn't a plain text format today and anyone who's
> able to assume it is can only do so because they control the input.
>
> Deployed SRT uses <i>, <b>, <font> and <u>. WebSRT adds <ruby>, <rt> and
> <1>...<infinity>, extensions which are very much in line with the existing
> format and already "works" in many players (in the sense that they are
> ignored, not rendered). I wouldn't call that a huge mess.


And removes <font> and <u>. And adds a whole swag of other functionality,
which are not in line with the existing format. Just picking a part of the
WebSRT specification that may work if the software was written sanely isn't
really a fair argument for compatibility. But anyway, I think at this stage
we can only agree to disagree about whether SRT ad WebSRT are compatible.
:-)



>
>  Aside: WebSRT can't contain binary data, only UTF-8 encoded text.
>>>
>>
>>
>> It sure can. Just base-64 encode it. I'm not saying it's a good thing, but
>> if somebody really has an urge...
>>
>
> Sure, this would be a metadata track. Sites have no reason to offer
> download links to it, and if anyone gets hold of such a file it would
> quickly be evident that it's useless.


After a user has seen the crap on screen. I'm just saying: it's a legal
WebSRT file and really not compatible with any existing infrastructure for
SRT.



>  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.
>>>
>>>
>> How is that different from moving away from SRT. If everyone has to change
>> their parsing of SRT to accommodate a new spec, then that is a new format.
>>
>
> Not everyone has to change their parsers immediately, many will continue to
> work. However, if someone wants to support SRT in a compatible way, it's
> very helpful to have a spec, assuming that WebSRT is actually compatible
> enough with existing SRT content.
>
> This is quite similar to HTML4 vs HTML5. There are lots of mostly
> compatible HTML parsers, but HTML5 defines a single parsing algorithm, and
> slow convergence towards that is a good thing.
>

No, no, no! It is not at all similar to HTML4 and HTML5. A Web browser
cannot suddenly stop working for a Web page, just because it has some extra
functionality in it. Thus, the HTML format has been developed such that it
can be extended without breaking existing stuff. We can guarantee that no
browser will break because that is the way in which the format has been
specified.

No such thing has happened for SRT and there is simply no way to guarantee
that all new WebSRT files will work in all existing SRT software, because
SRT has not been specified as a extensible format and because there is no
agreement between all parties that have implemented SRT support as to how
extensions should be made.

We can introduce such a thing for WebSRT, but we cannot claim it for SRT.



> If the SRT ecosystem is so fragile that it cannot tolerate any extension
> whatsoever, then we should stay far away from it. It just seems that's not
> the case.


How do we know that everyone that uses SRT now really wants to use WebSRT
instead and wants to take part in the new ecosystem that we are introducing?
We make some pretty big assumptions about what everyone who is not a Web
browser vendor wants to do with SRT. That doesn't make the existing SRT
ecosystem fragile - but it makes it an existing environment that needs to be
respected.

Cheers,
Silvia.

P.S. I do wonder if anyone other than us is still following this thread. ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100824/1fd3a4fb/attachment-0002.htm>