- From: John Foliot <john@foliot.ca>
- Date: Wed, 21 Mar 2012 17:18:16 -0700
- To: "'David Singer'" <singer@apple.com>
- Cc: "'Sean Hayes'" <Sean.Hayes@microsoft.com>, <janina@rednote.net>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, '"'"'xn--mlform-iua@målform.no'"'"' <xn--mlform-iua@xn--mlform-iua.no>, <rubys@intertwingly.net>, <laura.lee.carlson@gmail.com>, <mjs@apple.com>, "'Paul Cotton'" <Paul.Cotton@microsoft.com>, <public-html-a11y@w3.org>, <public-html@w3.org>
David Singer wrote: > > (sketching furiously here) > > <video…> > <track…> > <link rel="longdesc" href="…" /> > <link rel="transcript" href="…" /> > <div rel="alt" lang="cn-US">alternative text</div> > </video> > So, originally I had suggested child elements inside of the <video> element, as I (and seemingly you too) subscribe to the basic XML dictate that suggests that Elements are better than Attributes* - another endless debate that has clogged the interwebs in the past. However, last fall at TPAC more than one browser engineer involved with implementing <video> suggested that adding more children elements inside of <video> was computationally heavy and that they would prefer not to do that - attributes where easier to support and add support for. While I remain a fan of elements, in this case I will take what I can get, and getting support for attributes versus fighting for support for elements seemed pointless to me, even though I acknowledge attributes weak points. * - Elements are better than attributes; for semantics, javascript, css - If something needs to be referenced you should normally make it an element, with an id attribute. - If something represents a separate entity, make it an element: you might want to add attributes later > Similarly the tracks could indicate timed accessibility alternatives > via their "kind" label. Ya, there was some discussion around extending the number of @kind values, that got derailed and derided by some browser engineers (at least that is what *I* recall). I believe that (Comcast? CableLabs?) had asked for either more, or an extensible mechanism to reference more and that it was met with resistance. We could perhaps again look at adding new @kind values: <track kind="transcript" src=""> <track kind="description" src=""> <track kind="posterdescription" src=""> If there were some indication of looking at those possibilities I would be open to them. > > And these are all useful for all users; a programmatic way to find the > transcript, description, and short text benefit all boats. I think keeping @alt and applying it to <video> is a strong pattern that has years of understanding from even mainstream, garden variety developers - so let's not mess with a good thing. As for the programmatic associations - that's code; what's clearly more important is support from User Agents JF
Received on Thursday, 22 March 2012 00:18:58 UTC