Re: [blink-dev] WebVTT vs TTML Features

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

> On Wed, Dec 11, 2013 at 10:37 AM, Glenn Adams <glenn@chromium.org> wrote:
> >
> > On Wed, Dec 11, 2013 at 7:32 AM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com>
> > wrote:
> >>
> >> On Wed, Dec 11, 2013 at 10:26 AM, Glenn Adams <glenn@chromium.org>
> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Dec 11, 2013 at 6:59 AM, Silvia Pfeiffer
> >> > <silviapfeiffer1@gmail.com>
> >> > wrote:
> >> >>
> >> >> Some corrections inline since there seem to be some
> misunderstandings.
> >> >>
> >> >>
> >> >> On Wed, Dec 11, 2013 at 8:20 AM, Glenn Adams <glenn@chromium.org>
> >> >> wrote:
> >> >> >
> >> >> > 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.
> >> >>
> >> >> Yes, that's what we're doing with VTT when VTT is used in the browser
> >> >> - we map it to HTML and CSS for rendering. Non-browsers can decided
> to
> >> >> use a different approach for rendering.
> >> >>
> >> >>
> >> >> > 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.
> >> >>
> >> >> That makes browsers have to support all of HTML/CSS in cues, which,
> as
> >> >> I said above, makes no sense.
> >> >
> >> >
> >> > Repeat again: I did not say "all of HTML/CSS", and what I did suggest
> >> > does
> >> > not imply "all". If one were to define direct delivery of HTML/CSS
> based
> >> > cues, there is no reason it could not be a subset of HTML/CSS.
> >>
> >>
> >> Do you want to define a HTMLCue that supports all of HTML or a
> >> PartialHTMLCue? Since cues can be created by any authoring system,
> >> including by JavaScript in the browser, you can't just say that
> >> HTMLCue supports all of HTML/CSS, but you're only ever sending it a
> >> subset of HTML/CSS. That's not how it works.
> >
> >
> > It is if that's how you define it. Right now you have a method
> > getCueAsHTML() not getCueAsPartialHTML(). Whether it is everything or
> > partial is rather besides the point of this discussion anyway. My point
> is
> > there might be utility in defining some Cue type (I don't care what to
> name
> > it) that allows JS client code to populate a track's cues with HTML/CSS
> (at
> > whatever subset we want to enforce). Going beyond that, there may be
> utility
> > in defining a way to deliver such cues directly (without requiring client
> > JS).
>
> Maybe. I'm not opposed to a HTMLCue. It's not something that's useful
> for VTT, but it may be a useful addition to HTML. As I said: make a
> JavaScript implementation using DataCue and prove to the HTML WG that
> it's useful. This is not the right forum to discuss this.
>

Silvia, this is the second time you are suggesting this is the wrong forum
to discuss HTMLCue etc. I disagree with this line of thinking. This is
precisely the correct forum to be discussing this. Of course, we might
choose to start a new thread on this topic, but please don't suggest this
is the wrong forum.


>
> Regards,
> Silvia.
>