Re: Unifying the rendering approach

On Tue, Jan 28, 2014 at 7:39 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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

I think the current algorithm is not deterministic enough, so we
should clarify it or replace it with something simpler.
We just introduce a z-index feature - which incidentally is what CEA708 does.


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

Hmm... I was hoping this was all going to get integrated and simplified.


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

That's how I understood it. All I am saying is that the cue would move
up within its region, not independently.

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

:-)

Silvia.

Received on Tuesday, 28 January 2014 11:02:38 UTC