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

On Sep 6, 2012, at 5:25 , Simon Pieters <simonp@opera.com> wrote:

> 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.

Great!  Good to hear we're roughly on the same page.  Sorry we missed FOMS… :-(  Thanks for all these carefully thought-out comments.  Keep them coming!

> 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.

Sure, some of what I wrote was to make sure there weren't awkward problems left (well, I am sure there are some, there always are, but make sure of obvious edges).

> 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.

Right, but on the other hand, it's good to have uniform 'vertical addressing' (for lines and regions) and I can't think what else % could mean.

> Also, the class seems unnecessary if we make the ID selectable from CSS.

We wanted to make sure that CSS was optional and that coloring windows was possible.  Silvia has a blog started on mapping 6/708 to VTT, and in there she suggests that UAs be able to behave 'as if' a 708 style sheet were available.  We don't want two windows with the same ID but we might want two with the same color, so that suggested that the class name should be possible. (It might be good to allow zero or more class names, in fact, if we want to be able to talk about border, shadow, etc. as separate 'CSS' classes.)

> (Cues are selectable from their ID but don't have a class.)

But text can.

> Do we need to support multiple scrolling directions or just up?

I think up is at least the 90% case.  I am not sure if anyone needs horizontal scrolling of vertical text (or even vertical text at all), and I agree, what I sketched for 'in character progression direction' scrolling is well under-specified, so I would prefer leaving that to a future version.  I wrote that paragraph merely to suggest that future specification of 'ticker tape' behavior was not completely excluded by this proposal.

There are some text effects that scroll down (e.g. sometimes credits do).  And…what goes 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?

Maybe implicit will do for now, but it's probably easier for editors if it can be explicit.  Textual order can be a pain on occasion; but that's what we suggest for two regions with the same explicit or implicit layer anyway.

> Do we need to be able to change the scrolling speed or can we use just e.g. 433 ms?

I think allowing an implementation that has CSS to make the transition explicit (using CSS transitions) is acceptable, and in the absence of either the stylesheet or the CSS engine, using 708 timing makes sense.

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

I tried to make that clear:  we propose that the positioning setting is *within the region*.  When no region is supplied, the region is the implicit 'whole viewport' region. 

> 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?

No, just that some people had said that introducing regions (windows) would invalidate existing files, and I wanted to say that that was not the case. Nothing more complex than that.


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 6 September 2012 16:23:48 UTC