Re: Survey ready on Media Text Associations proposal

On Sat, Mar 6, 2010 at 9:23 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>
> On Mar 5, 2010, at 1:26 PM, Silvia Pfeiffer wrote:
>
>> On Sat, Mar 6, 2010 at 5:15 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>>>
>>>  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>
>>
>> In this case, a @role attribute with the value "audiodescription"
>> would achieve the same effect.
>>
>> Thus far, media queries have been used not to describe what a resource
>> has to offer, but what device features the resource would be suitable
>> for. I believe that is a subtle but important difference.
>>
>  Ah, but this media query doesn't necessarily describe what is *in* the resource, is simply says that a resource is *appropriate* for a user that wishes to have audio descriptions.
>
>  "audiodescription" may have been a poor choice to use for an example, lets use avoidance of high contrast video instead. The proposed "accessibility()" media query can be triggered based on something that a user does *not* want, so to signal that a video is appropriate for users that prefer to not see high contrast video you could use something like this:
>
>    <video controls>
>        <source src="video_low_contrast.m4v" media="accessibility(high-contrast:no)" >
>        <source src="video_standard.m4v">
>    </video>
>
>  In the presentation David Singer made at the media accessibility workshop before TPAC we talked about using these on <source> elements only, but I think they will be equally useful as a way to choose <track> and <trackgroup> elements.
>

Do you have an example that applies as obviously to the track element
and doesn't repeat what the @role already provides?

I am assuming there will be and I am assuming we will have a need for
a @media attribute. But I also don't see any harm in not adding the
attribute now and waiting until the media subgroup has worked out the
specific media queries that we need to introduce for track elements.

I am actually not fussed either way, so it would be interesting to
hear what others think about adding/delaying a @media attribute.



>>>> 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.
>>
>> Out of curiosity: Do you have public test cases?
>>
>  Yes. Most of our media tests are here: http://trac.webkit.org/browser/trunk/LayoutTests/media. It looks like we only have one that only looks at "media", video-source-media.html, but video-source-error-no-candidate.html and video-source-error.html both use media queries to test somethings else.


Thanks. It's good to see that in action. It's good to see
min-device-width, screen and handheld as test cases for @media as
taken from your test cases and from what Philip linked to. Thanks -
really helps understand how it's mean to be used.


Regards,
Silvia.

Received on Friday, 5 March 2010 23:33:53 UTC