Re: Survey ready on Media Text Associations proposal

On Fri, Mar 5, 2010 at 7:51 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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.


I think we wanted to keep the possibility of adding source elements
for the case where we have e.g. an external audio description track
both in Ogg and MPEG formats. This would need to be handled similarly
to a video element, but inside a track element and the @media
attribute would indeed be necessary on these source elements.

It may actually well be necessary to have @media on the source and
track elements - basically it should always be at the innermost
element.

As with the JavaScript API - I am not fussed if we don't introduce
@media at this stage. I think it might be more important to iron out
what media queries mean for such extra tracks, in particular for text
tracks actually.

Cheers,
Silvia.

Received on Friday, 5 March 2010 12:09:27 UTC