Re: Resolving TextTrackCue issues

On Mon, Sep 2, 2013 at 5:20 PM, Glenn Adams <glenn@skynav.com> wrote:
>
> On Mon, Sep 2, 2013 at 2:20 AM, Philip Jägenstedt <philipj@opera.com> wrote:
>>
>> Am I correct to assume that GenericCue will never be rendered?
>
>
> It would be better to say "not automatically rendered by the UA without the
> intervention of JS client code". That is not to say it will "never be
> rendered".

Right, that's what I mean.

>> If so,
>> a format initially exposed using GenericCue can likely never be
>> "upgraded" to a fully functional interface, since scripts will have
>> come to assume that those formats aren't rendered by the browser.
>
>
> The purpose of the GenericCue is to expose the track content (in a text
> form) to JS client code, so that the JS client code can take further action.
> One of those further actions may be to interpret it and translate into some
> format the the JS client code wishes for rendering purposes.
>
> I'm not sure what you mean by "upgraded" to a fully functional interface,
> but one could, e.g., go on to define sub-interfaces of GenericCue, such as
> VTTCue, that do add UA based rendering support, e.g., by implementing
> getCueAsHTML() on top of GenericCue.

I mean the situation where a browser initially supports a format, say
in-band SSA in Matroska, using GenericCue, but later wants to support
it fully by adding an SSACue interface and native rendering support.
The problem is that if SSA were supported for a long time as
GenericCue, then it will be difficult to upgrade it to SSACue since
scripts will already be rendering it using scripts and assuming that
the browser does no rendering.

>> That
>> seems pretty bad to me, and a good reason for browsers to not stop
>> half way in supporting a format.
>
>
> I fail to see why this is bad at all. Rather, it seems the preferred design.
> The facts are as follows:
>
> (1) there are many and arbitrary text track formats, some of which have well
> defined rendering semantics, others do not;
>
> (2) it is desirable to have the UA render at least some of those formats,
> perhaps the most commonly used formats;
>
> (3) in case the UA does not render some format, or it is not generically
> renderable in the first place, then it is reasonable to expose that format
> to JS client code for further disposition, some possibilities of which
> include: having JS client code translate to a renderable form, e.g., for a
> non-common format for which native UA support does or likely will not
> appear, or in case of metadata not intended to be rendered, taking action as
> appropriate for the JS client/application in hand;

My concern is with text tracks which can in principle be rendered, as per above.

As for (in-band) metadata tracks which the browser can/should never do
anything with, a MetadataCue interface with a .data or .text member
sounds OK. In other words, I would be OK with GenericCue if it is
explicitly only for metadata, and preferably renamed to reflect that.

If there are indeed text track cues (not metadata) which some browsers
want to expose but not render, it would be interesting to know which
format that is.

[1] http://matroska.org/technical/specs/subtitles/ssa.html
[2] http://wiki.whatwg.org/wiki/Timed_track_formats

Philip

Received on Tuesday, 3 September 2013 09:26:16 UTC