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 19:18:46 +1100
Message-ID: <2c0e02831003050018g3c2ea5f4lfefdbb25b0d90e58@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 5:36 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Fri, 05 Mar 2010 13:21:11 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> 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
>> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations#Resource_selection_algorithm
>> .
>> Do you think something is missing?
> That algorithm seems to conflict with what Eric is saying as it relies on
> the enabled attribute on <track>, so I was asking how Eric thinks it should
> work. That was more or less answered in subsequent mails though.
> Personally, I think the track selection should be something like this:
> For each group:
>  If there exists tracks with the enabled attribute:
>    Select the first such track.
>  Else:
>    Do nothing
> Server-side solutions can look at Accept-Language to add enabled="" on the
> appropriate <track>. I think Accept-Language is quite useless and see no
> reason why the same or a new language setting for captions/subtitles would
> be any better. Therefore, I suggest not inventing a new solution at all.
> For role="" I don't have much of an opinion at all, but am not optimistic
> about browser settings being very helpful -- since users don't change their
> settings sites will rely on other methods anyway.
> I don't think we need to resolve this before going to the HTML WG as I'm
> sure everything will get discussed all over again anyway.
>>> 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.
> Opera supports it and it would be easy to support it on whichever of the new
> elements we decide should use it as well.
> There are some examples in
> http://my.opera.com/core/blog/2010/03/03/everything-you-need-to-know-about-html5-video-and-audio-2
> Search for 'media=' to find the examples.
>>> 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
>> http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations#Resource_selection_algorithm
>> let us know.
> I'm inclined to say that the media="" attribute should be relegated to the
> <source> attribute, just like for <audio> and <video>.

The @media attribute is already on the track element (which is the one
that used to be called @source). What am I misunderstanding?

> Again, I don't think we need to resolve any of this before going to the HTML
> WG. Also, I assume this (and the other suggestion) will be presented to the
> HTML WG as a rough draft for further discussion rather than as a complete
> solution with consensus and all.

I also believe there will be much additional discussion over at the
HTML WG on these proposals. It would just be nice if we had a good
concensus here and discussed many of the details so there are more
people that can explain the logic behind the proposal details.

Received on Friday, 5 March 2010 08:19:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC