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

Re: Resolving TextTrackCue issues

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 9 Sep 2013 11:27:17 +0200
Message-ID: <CAMQvoCmtQ=WLsw3Vc6BVDX4WKhF9Xh+BMQPzsTeoc-w-pr0jJQ@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>, public-html <public-html@w3.org>
On Sun, Sep 8, 2013 at 6:02 AM, Glenn Adams <glenn@skynav.com> wrote:
> On Sat, Sep 7, 2013 at 5:27 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>> I don't follow. Can you give an example of a serialized TTML document
>> entity ? I thought it was XML and not binary?

> (1) it can be encoded in either UTF-8, UTF-16, or any other encoding, and
> contains its encoding declaration, so this effectively requires binary
> (octet stream) transparency;

After parsing TTML, all attributes text nodes in the DOM would already
be decoded to the internal Unicode encoding (probably UTF-16) so
exposing any of the text from TTML would not require a binary

> (2) but more problematic, it contains, even if decoded into characters,
> contains LF and CR, which aren't permitted in WebVTT metadata text;

WebVTT files can contain CRLF line endings and so can script-created
VTTCues. What does happen is that the WebVTT parser normalizes line
endings. If one wanted to cram TTML into VTTCue (see below) one could
do something similar.

>> > 2. Because TTML is not related to VTT, and pretending that TTML is
>> > WebVTT
>> > metadata text just  confuses authors and implementers.
>> Agreed - some renaming would be necessary. VTTCue could be called TextCue.
> NO. Because VTTCue is not representative of all cue types and simply
> renaming it serves no purpose. It is still VTT based.

Yeah, exposing TTML using VTTCue doesn't make sense unless the TTML
rendering algorithm is a strict subset of WebVTT, and I'm pretty sure
it isn't.

Of course, a browser which doesn't care about rendering TTML properly
could transform it to some subset of VTTCue, but the whole reason that
VTTCue was split from TextTrackCue was to allow for other rendering
algorithms than WebVTT's.

This is going a little bit from the original problem, which is what to
do with in-band metadata tracks of potentially unknown kind and
whether or not any browser actually wants to expose subtitles/captions
to scripts without rendering them.

Received on Monday, 9 September 2013 09:27:46 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:05 UTC