RE: Change proposals for issue-152

Since I've been waiting to see this algorithm moved from the specification to finally close Bug 11207 I admit I haven't given it all that much attention. Since it is marked as destined for a CSS editor, it seems that at least in the past this idea of "fix at time of layout and avoid overlaps" was deemed to be in scope for CSS.  Now that I see the example, I have a hard time imagining any kind of scenario where it would give a usable experience for captioning or subtitling. There is no indication that A and C are from different caption sources, and since they occupy the same location in the layout a strong indication that they are not.  It's also not predictable where the next caption from source A will be placed if comes in before B and C are done; if it's one line it goes between B and C, and if I'm reading it correctly if two line it goes above. 

+--------------+
|    aaaa aaa   
|      aa a
|    BBBBBB 
|          
|     CCCC    
+--------------+

So if the next from b is one line and the next from C two lines, the C will end up above a

+--------------+
|    aaaa aaa   
|      aa a
|    
|     bb bbb bb     
|     CCCC    
+--------------+

+--------------+
|    ccc cc ccc   
|      ccc ccc
|    aaaa aaa   
|      aa a
|    
|     bb bbb bb     
|         
+--------------+

+--------------+
|    ccc cc ccc   
|      ccc ccc
|    
|      
|    
|     bb bbb bb     
|      AAA A  AA   
+--------------+

I have to say that having streams A, B and C target fixed rectangles looks a lot saner to me. Having subsequent captions jump around is as bad as having the original caption move; there is not even continuity of content.


-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch] 
Sent: 22 March 2011 19:47
To: Sean Hayes
Cc: Philip Jägenstedt; public-html@w3.org
Subject: RE: Change proposals for issue-152

On Tue, 22 Mar 2011, Sean Hayes wrote:
>
> Well I don't agree that the "whole point of having multiple text tracks 
> is that the user agent can intelligently avoid overlapping cues while 
> ensuring that a single cue doesn't move around when other cues are added 
> or removed at the same time" is true, in fact I'm not sure I even 
> understand what you mean by that; why is there a need to fix a caption 
> once placed?

You don't agree with it but you don't know what it means? :-)

I mean a case where caption A (a long caption) is from time 0s to 4s, 
caption B is from 3s to 5s, and caption C is from 4s to 8s.

At times 1s, 3.5s, 4.5s, and 6s, in the absence of any explicit 
positioning, the IMHO ideal renderings would be:

 1s
 +--------------+
 |              |
 |              |
 | AAA AAAA AAA |
 |  AAA AAA AA  |
 +--------------+

 3.5s
 +--------------+
 |              |
 |    BBBBBB    |
 | AAA AAAA AAA |
 |  AAA AAA AA  |
 +--------------+

 4.5s
 +--------------+
 |              |
 |    BBBBBB    |
 |              |
 |              |
 +--------------+

 6s
 +--------------+
 |              |
 |    BBBBBB    |
 |              |
 |     CCCC     |
 +--------------+


> If you are saying that captions are going to be selected in and fixed in 
> space in temporal order; that makes no sense, as you will end up with 
> different streams interleaved. it's actually far more likely you would 
> want to assign each caption output a fixed distinct region, since the 
> 80% use case for multiple simultaneous cue tracks is mixed language 
> subtitling like Bollywood where they subtitle in both Urdu and Hindi, 
> one individual reader is only going to be looking at one of the streams 
> so they want to always flick eye-gaze directly to where those captions 
> are going to appear.

Certainly by default streams should appear in the same place as other 
cues from the same stream. However, we never want cues to jump around. 
This is a stateful temporal issue which is out of scope for CSS. We should 
use CSS for styling, but not for things it isn't suited for. (Another 
example of what we shouldn't use CSS for is semantics.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 23 March 2011 05:38:47 UTC