Scrolling as overlap avoidance (Re: Alternative approach to scrolling, with demos)

Hi Philip,

I'm pulling out each of the issues in your "alternative approach"
thread into a separate thread, because I'd like to address the issues
individually.

On Sun, Mar 30, 2014 at 4:41 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>
> == Scrolling as an overlap avoidance ==
>
> Demo: http://people.opera.com/philipj/2014/03/vttscroll/simple.html
>
> When a cue overlaps, it's moved down until it doesn't overlap, then
> all the cues are moved up. Scrolling is implemented by moving cues,
> not their container.
>
> This approach makes things much more similar to the regular overlap
> avoidance. You will end up with cues occupying approximately the same
> space in both modes, the only difference is the order.

The VTT file that you associated with this approach is as follows:

==
WEBVTT

00:00:00.181 --> 00:00:07.120 position:15% size:70%
NOW THE ROLL-UP MODE.

00:00:02.884 --> 00:00:07.622 position:15% size:70%
THIS MODE IS NORMALLY USED

00:00:04.018 --> 00:00:08.789 position:15% size:70%
FOR TV NEWS PROGRAMS.

00:00:06.187 --> 00:00:10.124 position:15% size:70%
CAPTION LINES ROLL UP

00:00:07.120 --> 00:00:10.124 position:15% size:70%
FROM THE SCREEN BOTTOM

00:00:07.622 --> 00:00:10.124 position:15% size:70%
ONE LINE AT A TIME.

==

Your approach to this is to make a cue that would be rendered into the
place of an existing cue move that cue out of the way. That was my
original suggestion to Hixie on how to do this, too.

However, it was argued at the time - and I think there is merit - that:
* rendered cues should move as little as necessary, preferably not at all
* only rollup captions move existing rendered cues out of the way -
Karaoke captions don't, but instead find the nearest empty space to
render themselves into

Thus, it was determined that cues marked up as above will not move,
but every newly added cue will be added into a free space nearest to
the line that it is authored to be rendered into.

Since this has been the case for all of WebVTT since its inception, we
should not change this behaviour now.

Looking at the full demo that you are showing there, this syntax is,
however, not required. It would work just as well with the existing
region syntax.

The existing region syntax together with the region box satisfies the
following use cases that CEA708 has:
(1) there is a maximum number of rollup lines (assume that all your
cues end at 10.124 - how do you make sure there are never more than 4
lines of scrolling text on screen?)
(2) the background color on the width and height of the rollup area
needs to be changeable
(3) font size changes on the region need to make the region go bigger
centered out from the anchor point
(4) move all the cues in the region as a group to another location

(1) I know we could also put logic in to count the lines and not make
more of them appear than 4.
(2) I can see your backgroundTweak which is faking the region
background on the individual divs of each cue to get a combined
"region background" (did you notice that Chrome has a weird bug with a
gap between the lines?).
(3+4) We can also change the position of every individual cue by hand
when we change the fontsize or when we move the "region" to another
location.

But really: all of these are hacks to avoid introducing another box
that would take care of all this functionality more easily.



So, moving past the syntax to the scrolling algorithm that you implemented.

I think your approach to absolutely position the individual cues fixes
a bug in the spec (and my demo implementation) that makes cues not
roll up any more once the region is filled. However, it actually makes
absolutely positioned cues in an absolutely positioned box. I avoided
that by using max-height on the region box, which results in growing
the container box with the content.

I agree that my CSS is not fully working either, so I've tried to
adjust your approach in a hope to get there. In a first step, I've
turned the cueRoot div into the region container with the dimensions
and the location of the region and a fixed height of 4 lines of text.
Attached is the adapted js file and demo vtt file.

This now indeed stops cues from being displayed after 4 lines.
We can now also set the background color of the region in one go (use
settings.regionBg). You will, however, notice that with the cueRoot
being a fixed height, that results in too big a box also for lines
that are empty.

That's as far as I took it.

I will go back to my own demo implementation and see if I can fix the bug there.

Cheers,
Silvia.