Re: [blink-dev] WebVTT vs TTML Features

On Wed, Dec 11, 2013 at 9:45 AM, Glenn Adams <glenn@chromium.org> wrote:
>
> On Wed, Dec 11, 2013 at 5:36 AM, David Singer <singer@apple.com> wrote:
>>
>>
>> On Dec 10, 2013, at 12:56 , Glenn Adams <glenn@chromium.org> wrote:
>>
>> > * 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.
>>
>> No, that’s a non-sequitur.  You asked why we don’t simply assume HTML,
>> CSS, and Javascript and do titling using XMLHttpRequest, or the like.  That
>> assumes an *implementation* using HTML.
>
>
> Since VTT is normatively defined as a mapping to HTML/CSS and we are
> preparing to do this for TTML, and since TextTrackCue assumes that a
> rendered form of a cue implements getCueAsHTML() which returns a renderable
> HTML/CSS mapping, then someone already appears to be making this assumption
> (that *some* implementation uses HTML... not that every implementation
> *must* use HTML).

Right.


>> The simple expression needs to express what we need in captioning,
>> independent of the implementation thereof.  Why does it need to be a
>> ‘superset’ of anything?
>
>
> If both VTT and TTML (via new work in TTML2) are going to define their
> normative rendering semantics using HTML/CSS, then either HTML/CSS needs to
> be a superset of their intended rendering or some rendering will be
> incomplete, yes?

Yes, the features in VTT can all be represented by some HTML/CSS
combination, except for the line balancing, for which there is a
discussion at the CSS WG whether that would be a useful feature to
introduce and how to make it not have exponential complexity.

Silvia.

Received on Tuesday, 10 December 2013 22:51:56 UTC