Re: [blink-dev] WebVTT vs TTML Features

On Tue, Dec 10, 2013 at 2:49 AM, David Singer <singer@apple.com> wrote:

>
> On Dec 8, 2013, at 19:16 , Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>
> >>> I fully expect that more than half of these
> >>> features are not encodable or translatable to WebVTT, or if they are,
> then
> >>> have the added disadvantage of having to maintain a separate CSS style
> sheet
> >>> containing rules that apply to specific VTT files.
> >
> > Why is that a disadvantage? Separating the styling from the content
> > has been a driving design principle of the Web and has been part of
> > the cause for the success of HTML. I don't see how that would be a
> > disadvantage.
>
> I think that many think of this as an *advantage*; that VTT re-uses and
> leverages the web platform, including CSS.
>

Since by and large, TTML uses CSS properties as is, with the same (value)
syntax and semantics, it certainly leverages the platform. Three properties
used by TTML were not defined by CSS at the time TTML was published:

   - displayAlign
   - showBackground
   - writingMode

The first and third of these was defined by XSL-FO at the time TTML was
published, and the second was defined by SMIL at that time. Since first
publishing, CSS has added writingMode.

The real requirement from TTML, and the major source of disadvantage for
the current WebVTT approach is that it forces the distribution of
information that applies to a WebVTT "document". In essence, it prevents a
WebVTT "document" from being self-contained.

Self-containment (i.e., no external references or dependencies) was a hard
requirement in the design of TTML, and the inclusion of all style
information within a TTML document was formed on that basis.  Furthermore,
TTML doesn't enforce inline styling, but permits referential styling as
well as inline styling, as the author prefers.

My original comment, about translation of TTML to WebVTT, was intended to
indicate that there is a marked disadvantage with respect to that
translation since it prevents self-containment. This becomes particularly
problematic with respect to in-band track content, since it requires the
page that references a media container resource to track the relationship
between that resource and additional style resources. Alternatively, it
would be necessary to support in-band delivery of style sheets along side
an in-band delivery of a WebVTT track.

Another significant design difference between TTML and WebVTT comes into
play here as well: TTML was designed for smart authoring systems and dumb
clients, while WebVTT was designed for dumb authoring systems and smart
clients. TTML supports having the style and formatting and layout choices
made at authoring time with no intervention in the client, while WebVTT
support minimal (or no) authored style and formatting, but with automated
client layout behavior, e.g., overlap avoidance, text breaking differences,
etc.

That these design choices are very different will continue to stymy efforts
to unify the two intentionally different expressions of timed text content.

As for separation of content and form, TTML simply relied on existing usage
by SVG, SMIL, and XSL-FO to incorporate style information using the same
syntax as the content itself.