Re: Draft for summary of an HTMLCue proposal

All,

I had an action to update Andreas's proposal - please see additional
wording in the "What?" section below:

Nigel

On 12/08/2015 21:00, "Andreas Tai" <tai@irt.de> wrote:

>Dear all,
>
>One open task I had was to draft a summary for the HTMLCue proposal.
>This summary is intended as a base for discussion with other standard
>groups or with developers from the browser communities.
>
>The proposal could be discussed in tomorrows TTWG meeting (see agenda
>topic 9a)
>
>Best regards,
>
>Andreas
>
>"""
>---------------------
>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 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 a lot if the text track API can be used by any
>subtitle format.
>
>Options for a solution:
>
>1) Mapping of other formats to VTTCues
>Although this maybe 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 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 HTML extension. The HTML 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 to hear your opinion about this so that this
>activity can be started during TPAC in October 2015.
>"""
>
>-- 
>------------------------------------------------
>Andreas Tai
>Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
>R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
>Floriansmuehlstrasse 60, D-80939 Munich, Germany
>
>Phone: +49 89 32399-389 | Fax: +49 89 32399-200
>http: www.irt.de | Email: tai@irt.de
>------------------------------------------------
>
>registration court&  managing director:
>Munich Commercial, RegNo. B 5191
>Dr. Klaus Illgner-Fehns
>------------------------------------------------
>
>
>

Received on Thursday, 3 September 2015 14:00:58 UTC