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

Re: TextTrackCue discussions

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 17 Sep 2013 14:15:53 +0200
Message-ID: <CAMQvoC=Q_hVpLAvwbR=XgERNzddEa-TF+K+gsUEb-_XfXKYkZA@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Simon Pieters <simonp@opera.com>, 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>
On Tue, Sep 17, 2013 at 2:11 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Tue, Sep 17, 2013 at 6:01 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Tue, Sep 17, 2013 at 12:52 AM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> UnparsedCue can be created by JS and the JS could try to add it to a
>>> track that has a @kind=captions.
>> Why do we need to allow scripts to create UnparsedCue at all? That
>> will require some new API surface that isn't needed to solve the
>> original use case -- in-band metadata tracks which aren't just a
>> special-case of a captioning format.
> It also allows JS devs to create @kind=metadata cues without having to
> decide to use a more specific format such as WebVTT.

Given that UnparsedCue would be a strict subset of VTTCue, that
doesn't sound at all worth adding APIs for.

Received on Tuesday, 17 September 2013 12:16:24 UTC

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