- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 3 Sep 2015 14:00:26 +0000
- To: Andreas Tai <tai@irt.de>, public-tt <public-tt@w3.org>
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