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

OK, I have updated my demo implementation, see
http://html5videoguide.net/test/WebVTT-with-regions/player.html .

I have had to introduce a second absolutely positioned box inside my
region box, such that the outer box has a fixed height (which limits
the number of lines) and the inner box can grow with the number of
cues. However, the cues are NOT absolutely positioned. The scrolling
works on the height of the inner absolutely positioned box, which
changes with the cues inside, so that works well.

Source code is here:
https://github.com/silviapfeiffer/WebVTT-with-regions (in particular
in https://github.com/silviapfeiffer/WebVTT-with-regions/blob/master/dom_construction.js).

Background color for the region is set on the inner absolutely
positioned box (since its overlap is hidden and it grows with the
number of cues).

I will have to think again about what effect that has on the render
algorithm simplifications that Victor and I discussed, but I believe
this is somewhat orthogonal.

Cheers,
Silvia.



On Tue, Apr 8, 2014 at 4:57 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> 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.

Received on Tuesday, 8 April 2014 10:22:52 UTC