Re: [blink-dev] WebVTT vs TTML Features

On Wed, Dec 11, 2013 at 5:08 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

>
> On 11 Dec 2013 07:56, "Glenn Adams" <glenn@chromium.org> wrote:
> >
> >
> > On Wed, Dec 11, 2013 at 3:34 AM, David Singer <singer@apple.com> wrote:
> >>
> >>
> >> On Dec 9, 2013, at 11:36 , Glenn Adams <glenn@chromium.org> wrote:
> >>
> >> > But not as well as you could it would seem: on Chrome, WebVTT is
> simply translated to cues referring to a CSS styled HTML fragment. Why not
> simple define an HTMLCue, and dispense entirely with VTTCue and the WebVTT
> parser. The WebVTT could be translated to a sequence of HTML cues on the
> server or using client JS.
> >> >
> >>
> >> This is probably stating the obvious, but you asked.
> >>
> >> for at least two reasons:
> >>
> >> * we want this to be only one of many possible implementation choice
> >> and
> >> * we want there to be a simple expression of the timed cues that is not
> dependent on an implementation choice
> >
> >
> > Which would require the "simple expression" to be a semantic/stylistic
> superset of formats, which HTML/CSS is, but WebVTT isn't.
>
> Allowing all of html and css in cues is madness.
>

I don't recall ever saying to allow "all" of html/css. The fact of the
matter is that VTT implementations translate VTT cues to some subset of
HTML/CSS. We are also defining a mapping from TTML to some subset of
HTML/CSS.

This process begs the question of whether any translation from an input
format like TTML or VTT into HTML/CSS should be implemented in the browser
rather than in, say, JS client code. Going one step further, it is natural
to ask if it makes sense to have servers deliver cues using HTML/CSS
directly, thus even avoiding the need for JS client translation.


> Why did ttml not do that either?
>
The current cue system defined in HTML5 is a new concept and mechanism.
That it is defined in terms of getCueAsHTML() for rendering purposes begs
the question of whether to use HTML in the first place.

It has recently been suggested (very strongly indeed) that clients need not
directly support TTML rendering since JS client code could perform
translation into HTML/CSS fragments.  That is not an unreasonable
suggestion, but it is inconsistent with saying that a client should
directly support VTT to HTML/CSS translation, while saying a client
shouldn't do this for TTML.

My purpose in suggesting the potential utility of defining an HTMLCue as
such is to demonstrate that one *could* dispense with any direct client
support for VTT or TTML other than fetching or demultiplexing VTT/TTML
content and passing it to client JS code to be translated into HTMLCue
instances.



> Authors of captions need something that works for the use case, ie.
> captioning, and not for publishing. If you want all of html+CSS, you don't
> need a new format - you just write a web page.
>

I never said "all of HTML/CSS". Note that at present, VTTCue.getCueAsHTML()
doesn't explicitly limit what HTML is contained in the returned fragment.

If we wanted, we could finish the process of formally defining the VTT to
HTML/CSS mapping, do the same for TTML, then constrain the fragments
returned from getCueAsHTML() to the subset of HTML/CSS that is sufficient
to render these formats.

> Silvia.
>