Re: Unifying the rendering approach

On Fri, Jan 24, 2014 at 12:26 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Hi all,
>
> The introduction of regions created a second code path in the
> rendering spec with some duplication.
>
> At FOMS, several people voiced that they are unhappy about it.
> We discussed if it was possible to unify that.
>
> The proposal that we came up with was to put *all* cues into regions.
> A region is thus basically the background box into which cues are
> rendered.
>
> Cues that have no region reference will be put into an anonymous
> region that has:
> * no identifier,
> * the dimensions of the viewport (vw, vh),
> * no scroll,
> * a region anchor of (0,100),
> * a region viewport anchor of (0,100).
>
> The intent is to allow us to create a single rendering path for all cues.
>
> However, there are differences between cues that are currently
> rendered without a region and those that are rendered into a region
> and we have to work these out. We can either try to retain the
> previous behaviour or come up with a better, more integrated way of
> doing it.
>
> So, I've gone through and tried to identify the differences.
>
> * overlap avoidance: cues without a region have a means to deal with
> overlap and move cue positions. The approach here is different between
> snap-to-line positioned cues and percentage positioned cues. I'd like
> to come up with an algorithm that deals the same with all cues. Also,
> it needs to be deterministic for the JavaScript developer so they can
> potentially do even more repositioning if necessary. So, my thoughts
> are that we should just avoid placing cues into lines (for horizontal
> cues; rows for vertical cues) that are already occupied by another
> cue. That's basically the algorithm for snap-to-line positioned cues.
> It wouldn't apply to scrolling regions, but to all other ones.
>
> (BTW: I think we need two levels of overlap avoidance: one within a
> track and one that optimizes between all tracks, not just VTT tracks.
> So, we may need to create an algorithm for the HTML spec for this,
> too. But this is a discussion for another day.)
>
> * snap-to-lines: cues in a region don't have snap-to-lines
> positioning. When we place such cues into anonymous regions, we
> calculate the number of lines from the size of the region, which for
> an anonymous region is the size of the viewport. So, this should be
> fine.
>
> * title area: right now we have a means to specify a "title area" for
> snap-to-lines cues. I think we can remove that because we now have
> padding on the cue background box (which will be the region in
> future), so we have that covered for all types of cues.
>
>
> Are there any other issues I have overlooked?

I wrote about how I think we should solve this in
http://lists.w3.org/Archives/Public/public-texttracks/2013Nov/0012.html

To reiterate, I'd like to turn the scrolling into part of the overlap
avoidance, so that when a cue would overlap at its preferred position,
one of two things happen:

1. The cue (horizontal text at line -1) is moved up until a free space
is found and it is left there. (this is the current spec)
2. The cue is moved down until a free space is found. Then, this cue
is moved (optionally animated, i.e. scrolling) up to its preferred
position. Any cue it then overlaps is moved up by an equal amount. Any
cues that overlap in turn are also moved up, and so on until
everything has been moved.

The overlap avoidance mode would ideally be a property of the cue, to
relieve regions of that responsibility. Scrolling or not becomes a
matter for CSS, to animate the relevant property on the cues or not.

Philip

Received on Monday, 27 January 2014 09:36:21 UTC