- From: Eric Carlson <eric.carlson@apple.com>
- Date: Fri, 5 Mar 2010 10:15:35 -0800
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Philip Jägenstedt <philipj@opera.com>, Michael Smith <mike@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Mar 4, 2010, at 9:21 PM, Silvia Pfeiffer wrote:
>
>
>> Do you still want to keep the
>> enabled *property* so that scripts can switch between different tracks of a
>> group, just like the browser context menu?
>
> I assume you are referring to the JavaScript API with *property*? If
> so, yes, I think a Web Developer should be able to set a default
> through the @enable attribute, and ask the track about its state
> through the enabled property, then be allowed to react accordingly.
>
I agree.
>> I am not very optimistic about UA
>> track selection being very useful being applying the 'media' attribute.
>
> Those media queries that apply to this (as well as the video element)
> actually still need to be defined. As with the JavaScript API, we
> could decide to leave the media attribute out for the moment and add
> it at a later state when we are sure that we actually have media
> queries that help in the resource selection process.
>
I think 'media' will be extremely useful for describing the accessibility affordances in optional external tracks.
<trackgroup media="accessibility(audiodescription:yes)" >
<track src="en.wav" lang="en" enabled >
<track src="fr.wav" lang="fr" >
<track src="de.wav" lang="de" >
</trackgroup>
> Incidentally - have any browser vendors implemented support for the
> @media attribute on the video and audio elements? I'd be curious about
> test cases there and whether they apply to external text associations.
>
WebKit supports media queries on the <source> element.
eric
Received on Friday, 5 March 2010 18:16:13 UTC