Re: discussion of video transcript - issue 194

On Tue, May 15, 2012 at 8:39 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On May 10, 2012, at 12:58 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>
>>
>>
>> Here is the first draft of a proposal that we've recently started
>> discussing at Google:
>>
>> http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP
>>
>> Please read with an open mind and feel free to make suggestions for improvement.
>
> Implementor feedback and with chair hat off:
>
> It is much more efficient, implementation-wise, for the video to link to the transcripts, than for the transcripts to link to the video. Often, the engine will want to perform an operation where it has the video element as a starting point, and it wants to find all associated transcripts. For instance, it may wish to find all tanscripts to build a menu. Or it may be running with an assistive technology enabled which gives the user the ability to go straight to the transcript when the acessibility point of regard (e.g. the VoiceOver cursor in VoiceOver) is at the video.
>
> If the video links to transcripts by id, then this is straightforward. The engine simply does a getElementById() for each associated transcript ID, an operation which is already optimized to return in average-case amortized constant time in browser engines.
>
> However, the other way around is much more expensive. If you are at a video and need to find all transcripts linking to it with @for, you have the choice of one of:
>
> 1) Walk the whole document to find all <transcript> elements, and collect ones with the right @for association. This can be slow for a large document, enough to be unacceptable for interactive response to a user operation.
>
> 2) Maintain an extra data structure on the side which knows about all <transcript> elements and all media elements currently in the document, and maps the forward association; this would cost extra memory, and would require a lot of care to handle dynamic updates properly (when elements get added/removed, when ids change, when for attributes change, etc).
>
> It is not clear to me what advantage there is to <transcripts> linking back to the <video> or <audio>, instead of forward linking from the media element to associated transcripts. Unless there is a compelling advantage, I would suggest switching to forward linking.
>
> Regards,
> Maciej
>
> P.S. In this regard I believe the design of the <label> element and its @for attribute is poor, and the design of aria-labeledby is superior.
>

This is an excellent argument for the @transcript approach - I had
already hinted at that in our meetings, but you've made it much
clearer.

In our discussions, we also identified other advantages of this design
approach, in particular that there is an actual attribute on the video
element that has the "knowledge" about transcripts such that browsers
can decide to add transcript controls to their video controls should
they want to.

So, I agree - the final version of this CP will use @transcript rather
than @for.

I'll make these changes to the CP after our next meeting to make sure
it will have all the feedback included, should we decide to make it
our consensus CP.

Best Regards,
Silvia.

Received on Tuesday, 15 May 2012 11:29:50 UTC