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

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.

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.


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


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


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

>>> so I would like to propose an alternative change to
>>> solve the only problem with the old model that I am aware of:
>>>
>>> Change the default position from 50% to "auto", which would maps to 0%
>>> for align:start, 50% for align:middle and 100% for align:right.
>>>
>>> I've created a bug for tracking this:
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25632
>>
>> This problem is already solved in the current spec. Search for this paragraph
>>
>> "
>> A text track cue has a default text track cue text position alignment
>> which is defined in terms of the value of the text track cue text
>> alignment:
>>
>> For left or start aligned cues: start.
>> For middle aligned cues: middle.
>> For right or end aligned cues: end.
>> "
>
> I see, you've put it in the parser, which takes care of the
> declarative case. For script-created cues, position will always have
> some specific value and the default logic is never hit. To make it
> work everywhere, auto needs to be a property of position, and the
> mapping from alignment to position needs to happen in the rendering
> section. Let's follow up in the bug.

Sure.

Cheers,
Silvia.

Received on Monday, 12 May 2014 12:50:01 UTC