Re: Survey ready on Media Text Associations proposal

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:

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

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