W3C home > Mailing lists > Public > public-html@w3.org > September 2013

Re: TextTrackCue discussions

From: Simon Pieters <simonp@opera.com>
Date: Mon, 16 Sep 2013 13:01:21 +0200
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Glenn Adams" <glenn@skynav.com>, "Brendan Long" <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, "Eric Carlson" <eric.carlson@apple.com>, Philip Jägenstedt <philipj@opera.com>
Message-ID: <op.w3h3kjucidj3kv@simons-macbook-pro.local>
On Mon, 16 Sep 2013 04:57:35 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> OK, we've come all the way round back to what I proposed in
> http://lists.w3.org/Archives/Public/public-html/2013Aug/0152.html ,
> but with s/GenericCue/UnparsedCue/  and VTTCue not inheriting from
> UnparsedCue.
>
> It seems that we now have agreement on this from several people
> including voices from Opera, Mozilla, and Chrome, but with concerns
> raised from Apple and Microsoft.
>
>
> Here are some remaining open issues from the discussion:
>
> * what is the browser supposed to do for a UnparsedCue on a track with
> @kind="captions" ?

Just expose it to scripts?

> * could / should we enforce that UnparsedCue is always the
> TextTrackCue interface for @kind="metadata" ?

I don't think we should. For WebVTT, one might want a metadata track to  
download but not render, and still want to use the WebVTT-specific stuff  
(e.g. the cue settings).

> * to allow a browser to expose in-band text tracks as UnparsedCue when
> it doesn't want to render the cues, we need to change the algorithm to
> expose in-band text tracks at
> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#steps-to-expose-a-media-resource-specific-text-track
> : the text track's @kind always has to be "metadata" and the semantics
> need to become part of the "text track in-band metadata track dispatch
> type". Is this the preferred approach?

I don't have an opinion about this point.

-- 
Simon Pieters
Opera Software
Received on Monday, 16 September 2013 11:01:55 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:05 UTC