On Wed, Sep 4, 2013 at 7:38 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Jun 2013, Silvia Pfeiffer wrote:
On Thu, Jun 13, 2013 at 3:08 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 12 Jun 2013, Silvia Pfeiffer wrote:
As we continue to evolve the functionality of text tracks, we will
On Wed, 12 Jun 2013, Brendan Long wrote:
On 06/11/2013 11:11 PM, Silvia Pfeiffer wrote:
I suggest we rename WebVTTCue [1] to VTTCaptionCue and allow such cues
only on tracks of kind={caption, subtitle}.
Why VTTCaptionCue and not just HTMLCue? It seems like any cue that can
be
On Thu, Jun 13, 2013 at 3:08 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 12 Jun 2013, Silvia Pfeiffer wrote:
As we continue to evolve the functionality of text tracks, we will
introduce more complex other structured content into cues and we will
want browsers to parse and interpret them.
I
On Tue, Jun 18, 2013 at 12:57 PM, Brendan Long s...@brendanlong.com wrote:
On 06/17/2013 12:41 AM, Silvia Pfeiffer wrote:
Why VTTCaptionCue and not just HTMLCue? It seems like any cue that can
be rendered needs to be able to provide its content as HTML, and once we
have that, the browser
Hi all,
The model in which we have looked at text tracks (track element of
media elements) thus far has some issues that I would like to point
out in this email and I would like to suggest a new way to look at
tracks. This will result in changes to the HTML and WebVTT specs and
has an influence
