RE: Change Proposal for Issue 194

Charles McCathieNevile wrote:
> 
> 
> In positive effects it claims to be better than longdesc - apparently
> because it can point to something in the page. Since longdesc can do
> that
> too, I don't see how that claim is justifiable - and anyway I don't
> think
> it is important to this case. It should simply be removed.

I concur, and I have taken the liberty of removing that line from the CP already, as I agree that it just muddies the water without adding any value to the proposal.


> 
> In talking to TV content producers who currently ship massive amounts of
> captioned content, they pretty clearly wanted the transcript to be
> inside
> the video element by default. What happens if the transcript element is
> placed inside the video element? Does it still need the transcript
> attribute? Or does it *have* to be placed outside the element?

It has been asserted that the <video></video> element creates a bounding box which contains/constricts any content within it to the physical size of that bounding box. I have (personally) not been able to prove or dis-prove that assertion, but I trust the feedback to be true until proven false. However, based upon that assertion, we've gone ahead and placed <transcript> outside of the <video> element.


> 
> IMHO (informed by people who would have to do this a lot) separating the
> two pieces and then having to put them together is something of an
> anti-pattern for authoring and maintenance, although for the sake of
> handling links to transcripts without duplication I think it is an
> acceptable compromise in this situation.

Chaals as you know we discussed this at some length, and based upon the above it meets the "I can live with it too" criteria: this does not fully eliminate the concern of orphaned "links to transcripts", however I think that because we have a new element called transcript that the likely hood of orphaning, while not zero, will likely be low. It is a lot harder to miss a <transcript> element when copy/pasting then it would a classic anchor tag with an ID value.


> 
> In the guidance about using the element to wrap links, it needs to be
> clear what happens if these are added for backwards compatibility and
> then
> hidden for design aesthetics. Experience suggests that people do that
> with
> anything they *think* is just for accessibility, and that they do it in
> ways that range from not very good to completely broken.

+1, although I suspect that this might also be addressed in an authoring guide (as opposed to the spec directly) - I'm good either way.


> 
> There is a URL API being developed in the Web Apps group - messy
> editor's
> draft at http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html but given
> this is relatively simple it should be finished before HTML 5. That
> might
> be better than rolling your own.

Hmmmm.... (JF runs off to read-up)

> 
> Thanks for doing the work on pulling together, and thanks to everyone
> who
> worked to get a reasonable agreement.

Thanks to you as well Chaals for dialing into the calls and offering your insights and guidance during those discussions. 

Team-work!

JF

Received on Tuesday, 22 May 2012 16:27:17 UTC