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

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

> 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

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

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

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

Philip

Received on Monday, 12 May 2014 11:59:18 UTC