Re: Unifying the rendering approach

Sorry for the late reply, I always put off thinking about regions
until it gets embarrassing.

On Mon, Feb 24, 2014 at 11:33 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Sun, Feb 23, 2014 at 6:48 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Sun, Feb 23, 2014 at 12:44 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>>> On Sun, Feb 23, 2014 at 4:14 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>>> I'd
>>>> like us to have an internal concept of constraining the size available
>>>> for layout that is honored for snap-to-line cues and that a region
>>>> simply establishes such a constraint. We don't need an anonymous
>>>> region because lack of a region is simply a lack of such a
>>>> constraint...
>>>
>>> Are you suggesting to completely drop the region rendering path and
>>> try to reconstruct it within the normal layout algorithm by
>>> constraining the available size for layout for snap-to-line cues? That
>>> would mean that this is the only difference between regions and
>>> non-regions? However, what do you do with the other "constraints":
>>> width, region anchor, viewport anchor, and the scrolling? You can't
>>> replicate scrolling unless you have an explicit box for the cues and
>>> for the regions. Just restricting the size for the background box
>>> doesn't resolve this IMO.
>>
>> Yes, the details are fuzzy, but that's exactly the path I think we
>> should take. As I've outlined in another mail, I think that scrolling
>> should be a property of individual cues, not something that they get
>> from being in a region.
>
> I think you're referring to:
> http://lists.w3.org/Archives/Public/public-texttracks/2013Nov/0012.html
> and
> http://lists.w3.org/Archives/Public/public-texttracks/2014Jan/0025.html
>
> I've previously given feedback in
> http://lists.w3.org/Archives/Public/public-texttracks/2014Jan/0038.html
> , but I am not sure I understood your approach correctly. I don't
> believe we should attribute scrolling to individual cues, but instead
> keep scrolling behaviour a property of a region as is the intent of
> what is currently specified. Let me see if I can explain.
>
> You wrote:
> "First position the cue in its preferred location. If it
> overlaps any other cue, it move it down until it does not overlap.
> Then it would be moved up, pushing along with it as many cues as are
> necessary to not cause (new) overlap. This "push" may be animated or
> not, subject to author stylesheet and user preference."
>
> Let me ask some clarifying questions based on an example of this.
>
> Rendered situation at which cue2 comes along:
> ---------
> |
> |
> |
> | cue1
> ---------
>
> cue2 it is moved "down" until it doesn't overlap any more, resulting
> in, I assume, a position off screen below cue1 (outside the viewport)
> as the first "free" position?
>
> Next it moves up into position -1, moving cue1 up, I assume resulting in:
> ---------
> |
> |
> | cue1
> | cue2
> ---------
>
> Question: which of the cues has a "scroll" setting? cue1? or cue2? or
> both? What happens if one of them doesn't have a "scroll" setting,
> e.g. cue1 doesn't have a scroll setting, but cue2 has? Will cue2 get
> stuck off screen or will it be displayed?

It is the properties of the cue being positioned that would determine
how overlap is handled, and since I want scrolling to be a mode of
overlap handling, this means that if cue2 has a overlap:scroll or
whatever setting, it would cause any overlapping cues (cue1) to move.

Note that making the scroll setting per-cue isn't integral to the
change I'd like to make, if it turns out that it would in any way
complicate layout (I don't think it would) then one could keep it per
region.

> Just to explain how the scrolling has been specified right now:
>
> The region gets the following CSS setting (amongst else):
> * the 'display' property must be set to 'inline-flex'
> * the 'flex-flow' property must be set to 'column'
> * the 'justify-content' property must be set to 'flex-end'
> If region's text track region scroll setting is 'up' and region
> already has one child, set region's 'transition-property' to 'top' and
> 'transition-duration' to '0.433s'.
>
> Then the 'top' property of the region is adjusted based on the number
> of lines rendered into it the region. I.e. the first one sets 'top' to
> the bottom of the region box plus the height of the number of lines
> rendered into the region. Once the region is "full" (e.g. when 3 lines
> are rendered into a region of height 3), then the "top" property
> doesn't change any more and cues simply scroll out of the region and
> disappear.
>
> I've implemented that here:
> http://html5videoguide.net/test/WebVTT-with-regions/player.html
> Just hit the "play" button.
>
> It has the advantage that you don't have to check for any overlaps for
> scrolling cues at all. You just deal with the region as an entity.

That's a great demo, and it verifies a suspicion I've had about the
transition. The transition is on the region top, which means that
scrolling is only smooth while the region is growing. After that point
the cues just pop into their new position. That doesn't seem
acceptable to me.

I think at this point what I need to do is to write up a demo of how I
would want the rendering algorithm to work.

Philip

Received on Friday, 7 March 2014 09:34:50 UTC