Re: Yet Another Scroll-Up Idea (YASUI) in VTT

On Wed, 05 Sep 2012 23:15:15 +0200, David Singer <singer@apple.com> wrote:

> (with apologies to the Japanese for the acronym)
>
> We are noticing that not only roll-up, but colored windows, are  
> mentioned in some regulations, and some wonderful people have the  
> exalted goal of replicating the TV experience.  So, having looked at the  
> options on the Wiki for roll-up, we added Yet one more.
>
> <http://www.w3.org/community/texttracks/wiki/RollupCaptions#10._Define_.27windows.27_.28building_on_8_above.29>
>
> Basically, this tries to preserve the random-access nature of VTT, the  
> optionality of CSS, and the validity of existing files, while adding the  
> concept of windows, including roll-up windows, to VTT. It should work n  
> live scenarios, as well.
>
> The syntax is there just as an example; I am quite sure we can improve  
> on it, but I know some people find it easier to understand given an  
> example.
>
> We built on pieces of many other proposals, most notably 8.
>
> The only thing we noticed that would be hard would be live conversion of  
> a 708 stream, because you don't know when new windows might be defined  
> or erased.  But we don't believe that that is a goal.
>
>
> Comments (and especially improvements) welcome…

We discussed rollup at the FOMS workshop earlier this week. We looked at  
the requirements and concluded that something like #8 or #10 above, i.e.  
using named windows (or regions), would address the requirements best.

What I'd like to do is for the first version try to trim it down to the  
absolute minimum and then add more features (if needed) when the first  
version has implementation experience. Which features are "nice to have"  
rather than "addresses the requirements"? For instance, height with number  
of lines is required but height with % is, I think, not. Also, the class  
seems unnecessary if we make the ID selectable from CSS. (Cues are  
selectable from their ID but don't have a class.) Do we need to support  
multiple scrolling directions or just up? Do we need to be able to specify  
the layer or can we rely on implicit layering from the order of which the  
regions are defined? Do we need to be able to change the scrolling speed  
or can we use just e.g. 433 ms?

If a cues both specifies a region and uses positioning settings, should we  
ignore the positioning settings or ignore the region setting?

I don't understand this part:

"(+) existing files remain completely valid"

All proposals do that, surely (since existing files don't use the proposed  
syntax)? Or did you mean something else?

-- 
Simon Pieters
Opera Software

Received on Thursday, 6 September 2012 12:26:18 UTC