RE: Change proposals for issue-152

Yes, it’s the same selection process, in fact if it weren’t for the need to expose the cues as HTML, <cues> could just be <video> with a different codec.

To enable multiple <cues> is the same as enabling multiple <videos>, and positioning them is the same as positioning <video>, <audio> or even <div>; you can have as many as you want, it's all just CSS. Silvia and Eric worked out the attributes to select between tracks and to enable them; which works essentially the same as a radio group in a form. This works based on the name and kind attributes.

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Philip Jägenstedt
Sent: 22 March 2011 09:11
To: public-html@w3.org
Subject: Re: Change proposals for issue-152

On Tue, 22 Mar 2011 07:03:33 +0100, Sean Hayes <Sean.Hayes@microsoft.com>  
wrote:

> Dear WG chairs,
>
> Please find a change proposal at  
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal_2

>
> This is broadly similar to Silvia's change proposal however it reflects  
> concepts that were present in the discussion of the W3C Media  
> Accessibility Task Force at the time I had to leave; which were not  
> subsequently captured in Silvia's proposal. Namely that the handling of  
> text tracks should be unified with the handling of media tracks.

To clarify, do you intend that the resource selection algorithm of <cue>  
should work just like for <audio> and <video> and only select a single  
resource?

If yes, how does one handle multiple text tracks that can be enabled at  
the same time? If each track has a <cue> element, positioning these in a  
sane way seems rather difficult.

If no, please elaborate on what <source> means when it is a child element  
of <cue>.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 22 March 2011 12:27:37 UTC