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

On Fri, Jun 14, 2013 at 4:40 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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.

I'm confused: are you saying what I'm suggesting would be simpler to
implement or what's currently there is 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.

What I'm suggesting would solve that, right?


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

I think those are all positive consequences: changing the @kind on a
<track> should not become something that programmers frequently use -
I don't see a common use case for it. If it requires re-fetching the
WebVTT file, then so be it. And re-parsing makes sense, because you
may have made changes because you thought the cues were of a
particular type, but they are not, so it's better to reset that.


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

It's easier to simply turn off all other tracks when debugging a
specific track than having to edit each cue of a WebVTT file just to
debug its content.

Note also that we're about to write a rendering algorithm for
chapters, so there's no need to turn them into captions/subtitles just
to make them visible.


>> 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 think we're in agreement - I was indeed suggesting that we need to
add interfaces for other cue formats than the WebVTT caption cue
format.

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

You're confusing me - are you supporting the introduction of other
interfaces for other cue formats?

Don't get me wrong, though: I still believe that TTMLCaptionCue will
get created and it will get created, because it follows a different
caption model than VTTCaptionCue. However, VTTChapterCue and
TTMLChapterCue should not be different and should instead just result
in a ChapterCue object, because we want chapters represented the same
way independent of what serialisation introduced them into the
browser.

Silvia.

Received on Friday, 14 June 2013 07:31:38 UTC