Re: How (horizontal) cue positioning works, or used to

On Mon, May 12, 2014 at 2:49 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Mon, May 12, 2014 at 9:58 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Mon, May 12, 2014 at 2:05 AM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> Hi Philip,
>>>
>>>
>>> On Fri, May 9, 2014 at 11:46 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>>> Hi all,
>>>>
>>>> There was a question off-list that I think is worth clarifying
>>>> on-list. This is how cue positioning used to work, for horizontal
>>>> left-to-right text, at the time it was implemented in Presto, which
>>>> also matches the current Blink/WebKit behavior:
>>>>
>>>> There are three settings that control the position and size of the cue
>>>> in the horizontal direction: position, size and align.
>>>>
>>>> The position is a point between the left edge (0%) and the right edge
>>>> (100%) at which the cue is anchored.
>>>
>>> This is how it is now. It didn't used to be like this. For rtl text,
>>> 0% was on the right edge of the viewport and 100% at the left edge.
>>> This is now changed and the text position only goes along the viewport
>>> axis from left to right. I'll explain more about the changes below.
>>>
>>>
>>>> The cue extends from the anchor point in a different direction
>>>> depending on the alignment:
>>>>  * align:left means that the text begins at the anchor point and
>>>> extends to the right of it.
>>>>  * align:middle means that the text is centered at the anchor points
>>>> and extends to both sides.
>>>>  * align:right means that the text ends at the anchor point and
>>>> extends to the left of it.
>>>
>>> This is where one of the key problems originated: we mixed the
>>> alignment of the text with the alignment of the cue box into which it
>>> was rendered. If I wanted a cue box that was positioned to start at
>>> 25% and was 25% wide, we had to specify "align:start position:25%
>>> width:25%". Now, if all we wanted to do is change the alignment of the
>>> text within that same box to be end aligned, we had to recalculate
>>> positioning as well and specify: "align:end position:50% width:25%".
>>> Now look at what happens to this when we change the text direction: it
>>> all flips over to the right half of the video. These are side effects
>>> that make no sense to an author.
>>
>> Yes, this was a side effect of having position always follow the text
>> direction, for ltr, rtl and vertical text. Since the main use case for
>> position is be aligning with or avoiding things in the video, it
>> doesn't seem helpful at all.
>>
>>> After looking at this problem long and hard, it was impossible to have
>>> "align" have all this impact on positioning. I had to make a clear
>>> change and separate that text alignment and cue box alignment from
>>> each other. More below.
>>>
>>>> Finally, size limits the width of the cue, so that you can for example
>>>> have a left-aligned cue that will never extend into the right half of
>>>> the screen by using position:0% size:50% align:left. If the size is
>>>> too large, the largest possible size is used instead.
>>>>
>>>> The defaults are position:50% size:100% align:middle
>>>>
>>>> Here's an image I made long ago illustrating this:
>>>> http://people.opera.com/philipj/2012/08/webvtt/position-opera-next.png
>>>
>>> This rendering is unchanged also in the current spec. However, it only
>>> shows the simplest cases. Things became hairy only when using a
>>> position setting that was not 0, 50 or 100.
>>> For example, try to render middle aligned text at the 20% position. It
>>> wouldn't work, because
>>>
>>>> While this model allows full flexibility in positioning the cue box
>>>> and the cue text within it,
>>>
>>> No, it didn't have full flexibility. The alignment and the positioning
>>> were interacting in undesired ways, see the example above.
>>
>> I mean that there's no rendering that was unachievable with the old
>> spec, it was just a bit weird.
>>
>>>> it has a problem: because position:50% is
>>>> the default just using align:left will not result in a left-aligned
>>>> text anchored at the left edge, instead it is a left-aligned text
>>>> starting at the middle of the viewport.
>>>>
>>>> This and many other issues was the topic of
>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20037
>>>
>>> Right, we fixed that in the spec and it is now working as desired.
>>
>> It doesn't work for script-created cues, but let's continue that
>> discussion in the bug.
>>
>>>> Some changes were made to the spec, including the introduction of
>>>> positionAlign. Silvia, can you explain what the new model is?
>>>
>>> Sure.
>>>
>>>
>>> There were numerous problems with the previous approach, not just the
>>> one you point out.
>>>
>>> All of the following bugs had input on the changes that were made:
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20037
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19178
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18501
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18769
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15859
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23404 (even though this
>>> was originally about vertical alignment)
>>> I may have missed some and should probably also cite some discussions on list.
>>> But rather than point you to history, I'll give you a summary.
>>>
>>>
>>> The main point of the changes that were made to the horizontal cue
>>> positioning were to separate the concepts of "text" from the "cue box"
>>> into which the text is rendered.
>>> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=20037 and
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23404 .
>>>
>>> This means that now are four settings that control the rendering of
>>> the cue in the horizontal direction:
>>> * the size of the cue box
>>> * the position the cue box is anchored to
>>> * the alignment of the cue box to the position (is it aligned to the
>>> middle / left / right of the position - this is positionAlign)
>>> * the alignment of the text within the cue box
>>>
>>> The size of the cue box is unchanged: it limits the width of the cue
>>> box into which the text is rendered.
>>
>> I would like to revert this, the old behavior is already implemented
>> and shipped:
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25660
>
> I am against reverting. The old behaviour is effectively unchanged by
> the changes, but the corner cases that were broken can now be fixed by
> an author by explicitly specifying positionAlign. Therefore I do not
> see a need to revert these changes.

This is not a corner case:

00:00.000 --> 00:01.000 position:75%
this text should be centered on the right half of the screen and wrap
at the edge of the video

That works in Presto, WebKit and Blink and isn't really broken, so why
change it?

> In fact, I do not understand your opposition to these changes when
> they were actually your proposals in the first place:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18501 - there you speak
> about two different alignment approaches.

In that bug I suggested changing position to work like
background-position in CSS and eventually narrowed the problem down
how align:left and align:right behave in the absence of an explicit
position setting. On that point we already agree that the default
position should depend on align.

>>> The position is changed in that it only goes from 0% at the left edge
>>> of the video to 100% at the right edge. This is now independent of the
>>> paragraph direction, which makes sense because when a text position is
>>> provided, it is for reasons of constraining text to a screen area.
>>>
>>> The alignment of the text within the cue box provides for control of
>>> the text display within the cue box: left, middle, right, start and
>>> end alignment. This allows to have text change its alignment when it
>>> is translated e.g. from the ltr to a rtl paragraph direction, but
>>> continue to be rendered in the same box.
>>>
>>> The alignment of the cue box now allows to specify a cue box anchoring
>>> with more control and independently of the text within the box. E.g.
>>> you can now specify a middle anchored cue box at the 30% mark of the
>>> video viewport of width 25% which has left aligned text inside it.
>>
>> The way to do it without positionAlign:
>> position:17.5% size:25% align:left
>
> OK, now use align:start instead and use rtl text and you have to
> redefine your text box to get the rtl text rendered into the same
> position.
>
> I'm not saying that you can't specify the cue box without
> positionAlign, but it removes some very unexpected surprises.

No, try that example in
http://people.opera.com/philipj/2014/05/vttposition/ and you'll find
that the box does not change with align:start.

>> The three additional ways to do it with positionAlign:
>> position:17.5%,left size:25% align:left (the default made explicit)
>> position:30%,middle size:25% align:left
>> position:42.5%,right size:25% align:left
>
> Correct. I don't see a problem in this. In fact, we can now finally
> deal with changing font sizes and adapting the box to em size
> increases.
>
> In the first case, the box would grow to the right until it hits the
> right edge, in the second case the box would grow both to the left and
> the right, and in the last case, the box would grow to the left until
> it hits that edge.
> We have an anchor point for the box.

This was discussed in the context of regions:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23865

I suggested doing it everywhere for consistency, but I don't know if
it's actually useful for cues. If it turns out that there are
compelling use cases that support the combination of em sizes and
anchor points, that would be a good time to add the feature.
Implementing it before that doesn't seem like a good idea, because the
risk is that the rest does not happen and we just end up with a more
complicated format for no benefit.

>>>> It doesn't seem to me that positionAlign actually adds any new
>>>> functionality,
>>>
>>> It actually does. I hope I've been able to explain.
>>
>> I agree with making position independent of writing direction and with
>> making the default position depend on align. This is a demo of how I
>> would do that:
>>
>> http://people.opera.com/philipj/2014/05/vttposition/
>>
>> That also allows you to define a box within which you can use
>> align:start without the box flipping with the text direction,
>> something I didn't understand when I filed bug 25632. Are there
>> additional problems which positionAlign solves? I understand that it
>> can be an authoring convenience to avoid some math, but there are also
>> costs involved: a parser change, additional API surface, and one more
>> input to positioning that authors will have to understand.
>
> See the font size increase above as extra functionality on top of the
> simplicity of the maths.
> You might find that the parser change is not big and the extra API
> surface sensible.
>
> As for the extra cue setting: only people with complex positioning
> needs will need to understand this. For all the normal cases, the
> default positionAlign makes sense.

In other words, a feature that we don't expect to be used much and
which is only a convenience when it is used.

Philip

Received on Monday, 12 May 2014 13:52:34 UTC