Section 15.4.2.1, step 10.8:

"If the text track cue writing direction is horizontal, the text track cue  alignment is end, and direction is 'ltr'
...

Let x-position be the text track cue text position subtracted from 100."

Considering an example with text position 75, size 100, alignment 'end', writing direction 'horizontal' and direction 'ltr':

Step 5 computes 'maximum size' as 75.
Step 6 computes 'size' as 75.
Step 8 computes 'x-position' as 100 - 75 = 25

---

I would've expected 'x-position' to be computed to 0 - i.e, 'text position' - 'size' - which seems more in line with for instance the handling of 'middle'.

The position always overrides the size. As far as I can tell, this is acting as expected.

(In reply to comment #2)
> The position always overrides the size. As far as I can tell, this is acting as
> expected.

So the position should be considered from the right edge? That feels a bit unintuitive for LTR text.

I also note that the syntax section of the spec has a note:

"The WebVTT text position cue setting is given as a percentage, calculated from the edge of the frame that the text begins (so for left-to-right English text, the left edge)."

Which in a way indicates that positions should be considered from the left for LTR text.

Hm, well, clearly if the spec contradicts itself _something_ is wrong!

The intent was to have the position start from the alignment edge, which is why text with end alignment that is ltr starts from the right, and vice versa.

I'll fix the note to be more precise.

A related thing that sprung to mind... If the position starts from the alignment edge - will that position align with the same "alignment edge" on the cue box? I.e, using the same example (values) would the right edge or the left edge of the cue box be at 25? This would seem to impact the max-size calculation.

Something like: |<--+            | vs. |   +----------->|

('+' is the position)

The current spec text has it as on the right above IIUC.

This may be the intended behavior too, just thought I'd point it out... and show that I find it confusing, so wouldn't mind additional text about it. Non-normative would be fine.

> will that position align with the same "alignment edge" on the cue box? 

I am not sure what you mean here.

(In reply to comment #6)
> > will that position align with the same "alignment edge" on the cue box? 
> 
> I am not sure what you mean here.

I think (it's been a while) that this was about whether the computed position would be the start-edge or the end-edge of the box - i.e, in the (ltr) example used previously, would the start-edge (the left edge) be at the computed (x-)position, or would the end-edge (the right edge) - because of the end alignment.

Another way to put it may be:

"pos" is computed position,
"." is outside cue box,
"-" is inside cue box,
[] is viewport edge,
| is cue edge.

dir:ltr, pos:25, align:start ->
start-edge at 25, text "grows" to the right : [...|Text--------]

dir:ltr, pos:25, align:end ->
start-edge at 25, text "grows" to the right : [...|--------Text]

OR

dir:ltr, pos:25, align:end ->
end-edge at 25, text starts at start-edge (25-size) and "grows" to the right : 
|--------T[ext|...........]

Better? Worse?

So I looked at this more closely, and you are right that the algorithm was wrong. The note was right. The idea is that the position gives the alignment edge, relative to the 'start' side of the video. (Start side as in left side for for ltr text, right side for rtl text.) And 'x-position' in the algorithm is always from the left side.

So text position 75, size 100, alignment 'end', writing direction 'horizontal' and direction 'ltr' should render as a 75%-wide box that goes from left:0 to left:75%, with text right-aligned in that box.

Checked in as WHATWG revision r7059.
Check-in comment: fix the alignment of end-aligned text cues
http://html5.org/tools/web-apps-tracker?from=7058&to=7059