Re: Unifying the rendering approach

On 7 Mar 2014 20:34, "Philip Jägenstedt" <philipj@opera.com> wrote:
>
> Sorry for the late reply, I always put off thinking about regions
> until it gets embarrassing.

It's my turn to say sorry for the delay. I've still got to reply to your
other email with the list of issues. Just a quick one to some things in
here for now.

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

We can't have cues that are rendered in a fixed location to be able to be
pushed away by scrolling cues. So this won't work.

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

The purpose of the region is to define an area in which a group of cues
that are defined as scrollable can scroll independently of other cues. The
group of cues can also share a background color around their bounding box,
and can be moved together eventually. Making the scroll-setting per-cue is
counter-productive to all of this. It also introduces complexities such as
mixed scrolling / non-scrolling cues.

To be frank: there would need to be extremely compelling reasons and full
satisfaction of all region use cases before I would reconsider changing the
region syntax. We have discussed that region syntax for more than 1.5 years
and this syntax has proven to work well. The point of this thread was to
change the rendering part of the algorithm, but not the syntax.


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

Hmm... I hadn't noticed this before. That does require a different
approach. Adding at the bottom and moving the "bottom" property seems a
better idea. Is that what you had in mind?


> 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.
Yes, if you want me to reconsider the region syntax, you're going to have
to make a very compelling argument.

Cheers,
Silvia.