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

Sorry: only tested in Chrome.

Silvia.


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