Re: Unifying the rendering approach

On Tue, Jan 28, 2014 at 3:16 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 8:35 PM, Philip Jägenstedt <philipj@opera.com> wrote:

>> I wrote about how I think we should solve this in
>> http://lists.w3.org/Archives/Public/public-texttracks/2013Nov/0012.html
>
> Sorry I missed that. :-(
>
>> 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)
>
> This would be used for scroll=false. I like this, it meets with what I
> suggested above (in more complicated words).
> Since anonymous regions would have scroll=false, they get this
> behaviour, which meets with the existing overlap avoidance algorithm
> for snap-to-lines. So, the new thing would be that this also applies
> to percentage-positioned cues.

Oh, I hadn't thought about percentage-positioned cues. There's a bug
with a ton of comments on that topic:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22029

>> 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.
>
> Right, that's what happens when scroll=true right now already.

Well, approximately, but it's completely separate from the other
overlap avoidance mode. My suggestion is to make it part of the
"Adjust the positions of boxes according to the appropriate steps from
the following list:" steps.

>> The overlap avoidance mode would ideally be a property of the cue, to
>> relieve regions of that responsibility.
>
> Hmm, interesting. Scrolling would happen within the region, but it
> would take into account all other cues currently rendered?

I'm suggesting that moving other cues (possibly animated) be an
overlap avoidance mode, not dependent on regions at all. It would be a
per-cue thing, so that when a cue that has this mode is rendered, it
can move any other cue in order to get the position it wants. (You can
create interesting cases with cues being pushed back and forth, but I
don't expect this to be a problem since the algorithm handles the cues
in a deterministic order.)

>> Scrolling or not becomes a
>> matter for CSS, to animate the relevant property on the cues or not.
>
> That's already how it's specified.
>
> I think this can work...

Encouraging...

Philip

Philip

Received on Tuesday, 28 January 2014 08:40:11 UTC