Re: Draft for summary of an HTMLCue proposal

It was discussed in the context of authoring, which is not fully
relevant to the proposal here. Creating a format that has HTML
fragments as cues is just a bit too unspecific.

However, introducing a HTMLCue object into browser APIs may be viable,
since once a format is parsed and converted to a HTML fragment,
exposing it in a HTMLCue may make sense.

I'm just curious what browser devs have to say about it.

Cheers,
Silvia.


On Thu, Aug 13, 2015 at 6:33 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> Did anyone raise problems with the idea or was there merely a non-specific
> lack of enthusiasm?
>
> Kind regards,
>
> Nigel
>
> From: Silvia Pfeiffer <silviapfeiffer1@gmail.com> Date: Wednesday, 12 August
> 2015 22:18
>
> 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
>> ------------------------------------------------
>>
>>
>>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance
> on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------

Received on Thursday, 13 August 2015 08:54:21 UTC