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

On Thu, Jun 13, 2013 at 6:07 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Thu, 13 Jun 2013 09:50:57 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Thu, Jun 13, 2013 at 5:02 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>>
>>>
>>> I don't think trying to split the interfaces for WebVTT cues make sense,
>>> since the kind can be changed dynamically,
>>
>>
>> The @kind is a readonly attribute - I don't think it can be changed
>> dynamically. If you know of a way to change the @kind dynamically, I
>> think we should stop that possibility. I don't think it makes sense
>> to, e.g., have cues with image content be able to dynamically convert
>> to descriptions or other types of cue content.
>
>
> HTMLTrackElement.track is writable, and TextTrack.kind "must return the text
> track kind of the text track that the TextTrack object represents." so in
> effect TextTrack.kind can change at any time.

Right, that's a problem. I suggest making it readonly, or
alternatively have that re-parse the whole file and re-build a new
TextTrack object.


>>> and the actual content of a
>>> WebVTT file can be the same regardless of the kind. For example, what
>>> would
>>> happen if the kind is changed while the WebVTT files is being received
>>> and
>>> parsed? And if the kind is changed later, should the file be re-parsed?
>>
>>
>> If you wanted cues to end up on a track of a different kind, you'd
>> have to copy them to a different cue type first and then add them to
>> that track. I think that's a reasonable requirement given the vastly
>> different types of content that can end up in a cue.
>
>
> But they're not vastly different, every WebVTT kind can contain the exact
> same markup. Adding new interfaces just hides some of the information,
> right?

If you are not authoring captions/subtitles, you would not use any of
the caption-specific cue settings. It's not just about hiding
information - it's about providing accurate, useful attributes for the
type of object that is being handled.

The alternative would be to just add attributes to a common Cue object
every time we define new cue format. That's like saying: why don't we
just throw all the attributes that any HTMLxxxElement ever needs onto
the Element object.

It's simply a poor way to deal with structured data - by ignoring
structure completely.

Silvia.

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