W3C home > Mailing lists > Public > public-html@w3.org > June 2013

Re: A new proposal for how to deal with text track cues

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 14 Jun 2013 19:24:02 +1000
Message-ID: <CAHp8n2=yavywDb63eJjoCf448HAxW2-bjch2o-fs+qqxObtcUA@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: public-html <public-html@w3.org>
On Thu, Jun 13, 2013 at 1:01 AM, Glenn Adams <glenn@skynav.com> wrote:
>
> So, with regards to the TT cue interface(s), we need to decide if:
>
> * it is desirable to define a single common, cue interface that can serve the
> semantic needs of both TTML and VTT
> * or, whether two distinct interfaces should be created;
> * or, some combination of the above (i.e., a common base and separate
> sub-interfaces)
>
> From what I can tell, most folks seem to have the third option in mind:
> create a common base to the extent that is feasible, then create format
> specific sub-interfaces that address non-common features.

Agreed.

> At this point, I believe it would be wrong to characterize TTML and VTT as
> simply two different serialization formats of the same feature set.

Agreed for captions. I believe you will find that when you specify
chapters, descriptions, or general metadata in either of them, you
will get out the exact same data and therefore they are two different
serializations for the same data.

> That
> just isn't true, and I don't know if it will ever be true given the
> differences in goals and emphasis I cite above.  That leaves us with needing
> to identify a common semantic subset of features both formats support and
> then design a common cue interface on that basis.

Not necessarily. In fact, my proposal is that they provide two
different interfaces for captions/subtitles:
a VTTCaptionCue and a TTMLCaptionCue. I would, however, suggest they
should use the same interface for chapters, descriptions, and
metadata.


> As we go through that process, we may find it convenient to make changes to
> one or both formats over time in order to better support semantics that are
> only supported in the other format.

Agreed.

> I believe the TTWG has general consensus on undertaking such a process.

Good. My proposal here is creating the basis for this to happen.

> And
> that brings us back to the process question of where this work will take
> place. It is fine to discuss strawmans on this ML and the TTCG or TTWG ML,
> but we need a definite home for this work where consensus can be established
> and decisions taken.

The basic interfaces for the <track> element are in JavaScript and
need to be defined here in the HTML WG. The TTWG can build on them and
should right now review whether it is possible to build on them. But
they need to be part of the HTML specification. The TTWG should then
indeed create the TTMLCaptionCue JS API and other JS APIs as they
relate to TTML.

Best Regards,
Silvia.
Received on Friday, 14 June 2013 09:24:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:33 UTC