Re: Draft for summary of an HTMLCue proposal

That would indeed show that there is browser dev interest.


On Thu, Aug 13, 2015 at 10:52 AM, Glenn Adams <glenn@skynav.com> wrote:
> Rather than approaching them with nothing in hand (other than a spec or
> plans for a spec), it would be better to do an implementation of the
> extension in Chrome, Webkit, or Mozilla. Then it would be easy to show the
> triviality of the implementation as well has having a platform to
> demonstrate utility of the feature.
>
> On Wed, Aug 12, 2015 at 3:18 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>>
>> Have you approached browser developers yet and got their thoughts on the
>> matter? This was an idea discussed in the html WG in the past and didn't get
>> very far.
>>
>> Best Regards,
>> Silvia.
>>
>> On 13 Aug 2015 6:06 am, "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 Thursday, 13 August 2015 01:11:38 UTC