Re: A new proposal for how to deal with text track cues

On Fri, Jun 14, 2013 at 12:04 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Jun 12, 2013 at 12:12 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>
>> All of these new cue settings would end up as new attributes on the
>> WebVTTCue object. This is a dangerous design path that we have taken.
>
>
> Having a few unused attributes on an object is an effect, not a problem.

It looks like a few right now because we only have about 5 from the
caption WebVTT cues and none from the others. That will change though
with the introduction of more cue settings for other kinds of cues for
which the current cue settings are irrelevant.

>  I
> think your proposal adds significant complexity, without solving any real
> problems.  It means adding a bunch of new restrictions to the API:
> preventing developers from accessing .vertical, .size, etc., if they have
> some reason to do so (they're still parsed and exposed for metadata cues);
> making .kind readonly, where before it wasn't.

That's like saying we only need a single element to pull any
information into the browser - it's a step back to what the <embed>
element did. Yes, we can pull images, video, audio, animations etc all
into the browser with an <embed> element. But then we can't react to
the specifics of the content unless we make the HTMLEmbedElement have
all the attributes of all the types of content that can be pulled into
the browser through<embed>.


>> Once a WebVTT file is parsed into a list of cues, the browser should
>> not have to care any more that the list of cues came from a WebVTT
>> file or anywhere else. It's a list of cues with a certain type of
>> content that has a parsing and a rendering algorithm attached.
>
> If it has a rendering algorithm attached, then the browser does care that it
> came from a WebVTT file, since that's what that flag indicates.

The object is called WebVTTCue - thus the browser cares that it came
from a WebVTT encapsulation.
Also, right now we are splitting rendering algorithms for captions and
chapters into two. There will be another rendering algorithm for
kind=descriptions cues at minimum.
In future we will want different parsing algorithms, too.
Attaching all of these with a single object is madness.


>  I'm also
> confused that you're saying you want to split the interfaces for metadata
> and cues, but that if the platform supports a DVD bitmap caption interface
> in the future, you'd want those to use the same interface, even though their
> data and attributes would be completely different.

Right now, we have one catch-all type cue: cues of kind metadata.
Other cues have explicit parsing and rendering algorithms associated.

Think about it like that: we understand captions/subtitle cues, have
defined an explicit parsing and rendering algorithm. We are about to
do the same for chapter cues - and after that we will do the same for
description cues. These are similar to the <img>, <video>, <audio>
tags that we have defined to pull in embedded content. That leaves
metadata cues for which we don't define a parsing or rendering
algorithm - just like <embed>/<object> remains as a generic means to
pull other types of embedded content into the browser.

Regards,
Silvia.

Received on Friday, 14 June 2013 04:35:45 UTC