W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2015

[whatwg] W3C Timed Text Working Group proposal for HTMLCue

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 10 Sep 2015 21:57:03 +0000
To: "whatwg@whatwg.org" <whatwg@whatwg.org>, "jer.noble@apple.com" <jer.noble@apple.com>, "eric.carlson@apple.com" <eric.carlson@apple.com>, "silviapfeiffer1@gmail.com" <silviapfeiffer1@gmail.com>, "philipj@opera.com" <philipj@opera.com>
Message-ID: <D217C919.274D1%nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
[Resending after subscribing to WHATWG list - apologies for the noise]

Dear WhatWG, Jer, Eric, Silvia, Philip,

W3C Timed Text Working Group kindly requests you to consider the following
proposal:

---------------------
What?
---------------------
We propose to specify an implementation of the text track cue API where
the format of the cue data is HTML. The "cue type" is called in the
following "HTMLCue".

The default onenter() handler in the HTMLCue interface would attach the
cue data to the target element; conversely the default onexit() handler
would clear the target element's inner HTML.

---------------------
Why?
---------------------
Different file formats are used for the distribution of subtitles and
captions in the HTML ecosystem. Currently only WebVTT has a defined Cue
concept that is implemented by Web Browsers. It would extend the reach
of accessible content greatly if the text track API could be used by any
subtitle format.

Options for a solution:

1) Mapping of other formats to VTTCues
Although this may be a short-term option a lossless mapping is often not
feasible and requires considerable knowledge of the source and the
destination format. It would also need continuous alignment of each of
the subtitle formats with WebVTT and vice versa.

2) Define a cue type for every subtitle format
Even if these different cue type specifications would exist it is
unlikely that browsers will support all different cue "specializations".

3) Define a generic cue type
This cue type should be easy to implement by browsers and it should be
possible to map the semantic to the scope of different existing formats.

We think an HTML cue as a variant of the third option is the best
solution.

The strength of a  generic  HTML cue type is that, assuming that the way
to render these cues is clearly defined somewhere, basically any kind of
subtitle format that can be translated into HTML could be supported, as
long as the browser, a client side JS   or a server based solution does
the translation work somewhere. One way to make use of the doc fragment
is to place the doc fragment as an overlay over the video.

The HTMLCue could be defined as an HTML extension. The HTML5 Spec itself
does not need to be changed.

It may be worth noting that under the hood some browsers already
translate WebVTT to HTML and some client side JS solutions translate
TTML to HTML.

=> Next Steps?
We would appreciate learning your opinion about this with the goal of
advancing this activity during W3C TPAC in October 2015. Please send

any emails to public-tt@w3.org - if you would rather respond in private
please reply directly to me at this address.

Kind regards,

Nigel Megitt, co-chair, W3C Timed Text Working Group





Received on Thursday, 10 September 2015 21:58:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:35 UTC