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

On Fri, 14 Jun 2013 06:45:08 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> 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.

It's not a problem for implementors, in fact it's simpler.

Having TextTrack.kind frozen at parse time and potentially in disagreement  
with the associated HTMLTextTrack.kind also seems like potential source of  
confusion, albeit not a huge one.

Making the parser depend on attributes on the track element is unnecessary  
coupling, and requiring later re-parsing means that the WebVTT file must  
be pinned in cache, even if the HTTP cache headers don't approve. Note  
also that re-parsing would throw away all existing cues together with any  
modifications made by scripts.

>>>> 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.

Unless you're suggesting preventing (by means of parsing errors) any of  
the WebVTT syntax from being used depending on the kind, it's a certainty  
that people *will* use all settings and syntax for all kinds, and hiding  
that just doesn't seem useful. In fact there's even a use case for  
positioning chapter cues: they can then be debugged by changing kind  
without interfering with the caption/subtitle cues.

> 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.

I think a better alternative is to leave WebVTTCue as it is and to add  
interfaces for other formats that represent the details of those formats  
well.

(I disagree that this is like the HTMLxxxElement example, I think it's  
more like putting HTMLImageElement and SVGImageElement behind common  
interface even though they differ in important ways.)

-- 
Philip Jägenstedt
Opera Software

Received on Friday, 14 June 2013 06:40:52 UTC