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

Re: Survey ready on Media Text Associations proposal

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 05 Mar 2010 16:51:41 +0800
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Michael Smith" <mike@w3.org>, "Eric Carlson" <eric.carlson@apple.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u826wfbvatwj1d@philip-pc.oslo.opera.com>
On Fri, 05 Mar 2010 16:18:46 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

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

We have talked about requiring an end tag for <track> (i.e. it is not a  
void element) in case we eventually need <source> for the same purpose as  
in <audio> and <video> -- providing different representations of the  
*same* resource (i.e. not different languages or similar). I'm saying that  
if we need media="" for anything related to <track>, it would be more  
consistent to have it on <source> element. Example:

     <track src="just-one.srt"></track>
       <source src="for-???.srt" media="???">
       <source src="default.srt">

I don't really know what "???" should be or if we need media="" at all.

If we put media="" on <track>, should track that don't match the current  
environment be hidden from the MediaTracks collection, or should it just  
be impossible to activate them?

I'd prefer to not introduce <source> at all or have to answer the above  
questions, so perhaps we should first make explicit what the use case for  
media="" is here. If we have none, we can drop it.

Again, I would prefer throwing this at the HTML WG ASAP so we can get some  
fresh perspective on all of this before ironing out all the details.

Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 5 March 2010 08:52:29 UTC

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