RE: discussion of video transcript - issue 194

Benjamin Hawkes-Lewis wrote:
> 
> <transcript>
> <video id=v1 src=video.mp4></video>
> <p>This is a on-page transcript.</p>
> </transcript>

Yech. From an authoring perspective, that is a very ugly and confusing pattern to propose, even if it would technically be viable. It seems to suggest that the video is a child of the Transcript, which is both false and *really* confusing. I've re-authored your proposal to take advantage of indented nesting, which more clearly illustrates what I mean:

<transcript>
  <video></video>
  <p></p>
</transcript>

I might also note that most transcripts will not be "on-page" due to their size and volume of content. They will most likely be external documents in (hopefully) HTML, but also quite possibly PDF, Doc/Open Office, perhaps even Daisy - all viable and possible options today.

I am not a big fan of that at all.

> 
> There might be rationale to make the following work as well:
> 
> <video id=v1 src=video.mp4></video>
> <transcript>
> <p>This is a on-page transcript.</p>
> </transcript>

This seems to insist that the link to the transcript be an on-screen text link, which many of us feel is too simplistic a response.  If you want to take your analogy of <label> further, I ask you - how often do we currently see 
<label class="CSS_off_screen_because_onscreen_is_ugly">?

(I will suggest the answer is Very Often)

My concern is that using such a blunt work-around is hardly elegant, and once again might suffer from the orphaned link-to-transcript problem when authors cut and paste a <video> all the stuff </video> block - remembering that what *they* want is the video first.

My preference then would be that any solution discussed sees the vehicle for including the transcript be included inside the opening and closing <video> 'tags' (which @transcript, <track>, and apparently <transcript> would provide). 

>From the 'elegance' perspective, my preference would also be for something that could easily be incorporated into both the native as well as author-scripted controls that HTML5 offers. This would consistently follow a precedent already established by media players today, that expose a "CC" button inside of the controls bar whenever Closed Captions are available. While this would by no means restrict other presentation/delivery patterns, I would go so far as to suggest it might be recommended as the default way of doing so.


Cheers!

JF

Received on Thursday, 10 May 2012 16:24:26 UTC