Re: Unifying the rendering approach

On Mon, Mar 3, 2014 at 10:41 PM, Victor Carbune
<victor.carbune@gmail.com> wrote:
> On Mon, Mar 3, 2014 at 12:11 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>
>> Aha! I see. The first case is so as to keep the line counting correct
>> for snap-to-lines cues, I assume? Couldn't we make these two cases
>> into a single case if the line positioning both for snap-to-lines and
>> for non-snap-to-lines is done on the anonymous region that wraps each
>> cue? What's the advantage of splitting these two cases?
>
> If we throw non-snap-to-lines cues within regions it means that we
> need to support a rendering case for these cues within regions, and
> also support named regions on them.

I don't think so, since it will be the region that is placed, not the
cue. So, the cue inside the region is still placed "snap-to-line" even
if the line is basically just a single line (minus line wrapping and
newlines).

> The advantage of not having non-snap-to-lines cues within regions are:

I agree, we should not have non-snap-to-line cues inside regions. But
what if the region itself was placed non-snap-to-line, while the cue
inside it wouldn't.

> *) Simple rendering steps within a region (pretty much everything that
> currently is for snap-to-lines will just be moved within a region).

Agree.

> *) No need to think what happens if some percentage-positioned cue
> overlaps a line-positioned cue (see "underspecced overlapping
> positioning" bug)

We still have to deal with overlapping cues, no matter whether they
are in snap-to-lines regions or in non-snap-to-lines regions.

> *) No boxes in boxes. Only the text lines generated by CSS wrapping or
> manual author wrapping (snapped into numerical lines of a region).

They are boxes, too, but yes, I agree.

> *) Better abstraction: author can already obtain exactly the same
> positioning using regions that they can with percentage-positioned
> cues. Why integrate two different elements solving the same problem
> together, if we can keep only one?

Because it avoids another big case statement in the rendering
algorithm. This way we have all three cases in one branch rather than
2 different branches. Also, this is just about the rendering, since
we're still keeping the two different ways of specifying positioning
(cues with line cue setting and cues inside regions).

(Also: thanks for the deja vue - maybe this time with less
mis-understandings. ;-)


>>> *) User-defined regions & cues with region identifier and snap-to-lines=true.
>>>
>>> So there's no cue with snap-to-lines=false that ends up in a region.
>>
>> A named region, I assume. Since the second case has
>> snap-to-lines=false cues in an anonymous region.
>
> As I mentioned above, I don't see any value in having
> non-snap-to-lines and snap-to-line cues in a single region, no matter
> if it is the large default anonymous region for snap-to-lines cues or
> a named region. It means you have to specify a rendering algorithm
> that combines both.

Right, I never suggested that. However, I was clarifying your
statement that " there's no cue with snap-to-lines=false that ends up
in a region", which isn't true, since in your second non-snap-to-lines
cues do actually end up in a region.


> A more personal comment: I feel that non-snap-to-lines cues are hard
> to use for authors that want to actually position things precisely on
> top of the video, and I'm not aware of other use-cases for it, so I
> would even go as far as removing them as soon as we support regions.

I don't think we should. I think some people will find the anchors for
positioning easier and others will prefer the line/position cue
settings. I don't think we should remove either.

> But since they are already here, we can easily keep them for
> backwards-compatible purposes with wrapped anonymous regions
> fulfilling the same positioning behavior.

Agreed.

Silvia.

Received on Monday, 3 March 2014 11:54:31 UTC