W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2010

Re: Survey ready on Media Text Associations proposal

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 5 Mar 2010 16:21:11 +1100
Message-ID: <2c0e02831003042121j3c801d1ch47b6c6745e8d693f@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Michael Smith <mike@w3.org>, Eric Carlson <eric.carlson@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Fri, Mar 5, 2010 at 2:38 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Fri, 05 Mar 2010 01:36:23 +0800, Eric Carlson <eric.carlson@apple.com>
> wrote:
>> On Mar 2, 2010, at 10:48 PM, Michael(tm) Smith wrote:
>>> A survey is ready on the "Media Text Associations" draft change
>>> proposal.
>>>  http://www.w3.org/2002/09/wbs/44061/text-associations/
>> I generally agree with this proposal, but would like to see the following
>> changes before we submit it to the WG:
>> + We should not mandate DFXP at this time. It has many features that will
>> complicate implementation significantly which are not needed for this
>> proposal. I think we should help define a DFXP profile that is more suitable
>> for our needs.
> For the record, I still agree.
>> + The 'enabled' attribute on a <track> in a <trackgroup> should be
>> invalid, as the UA is responsible for selecting the most appropriate track
>> from the alternates.
> What should the track selection algorithm be?

I thought the spec explained that fairly well, see

Do you think something is missing?

> 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 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.

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.

> I
> also have a feeling we haven't completely thought through what kind of
> selection belong on the <trackgroup><track> level and what belongs in
> <track><source> (assuming we'll go with that, just like for <audio> and
> <video>).

If you have any suggestions of what needs to be added to
let us know.

Received on Friday, 5 March 2010 05:22:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:54 UTC