Re: Draft for summary of an HTMLCue proposal

Thanks Silvia, that makes sense. I'd agree that authoring and serialising
HTML as cues doesn't have a strong use case, but parsing a format that
works for a particular set of semantics and converting it into HTML as a
lingua franca for presentation seems like a) easy to implement in browsers
and b) a nice way to separate the concerns.

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

In advance of requesting a brief joint meeting with the HTML WG at TPAC it
would be good to see how far we can get with implementation on any of the
browsers Glenn mentioned.

Cheers,

Nigel
 

On 13/08/2015 09:53, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

>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 09:08:36 UTC