Re: Draft for summary of an HTMLCue proposal

Andreas, all,

I've done some digging in blink on this following our discussion yesterday
and Silvia's suggestion to think about this in a browser development
context. 

disclaimer: I'm not claiming to be 100% sure I've understood exactly how
it works just yet!

It does broadly look as though it works by generating an equivalent HTML.

VTTCue is derived from TextTrackCue, and the implementation code can be
viewed in a browser at
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebK

it/Source/core/html/track/vtt/VTTCue.cpp

The VTTCue::getCueAsHTML() method returns a fragment of HTML stored in the
private m_cueBackgroundBox private member pointer variable of the VTTCue
class, to cherry-pick an example.

It therefore looks as though it would be very straightforward to create an
HTMLCue class as per the proposal, that would have an HTML fragment
created on construction and simply return it when requested. We could
highlight this close alignment between the blink VTTCue implementation and
our proposed HTMLCue in our communications with the HTML WG and others,
for example.

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.
>
>---------------------
>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 Friday, 14 August 2015 16:26:53 UTC