This bug was already discussed in:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24315
but you're correct - I don't think it's completely finished yet.

So, where are we at.

Let's only talk about non-snap-to-lines cues for now.

In this case, cues are positioned between to top and the bottom of the video viewport based on percentage.

When I took over Ian's spec, line:L% led to y-position being calculated as y-position=L and the CSS that was applied would be to set "top" to 'y-position vh'. This means that, e.g. for 0%, the top of the cue box is aligned to the top of the video viewport (i.e. cue line alignment='start'), and also that for 100%, the line would end up just outside the video viewport (again cue-line-align='start').

However, then there is another step that changes these positions again, namely for y=L to position "the point y% along the height of the bounding box of the boxes in boxes is y% of the way across the height of the video's rendering area".

This means that the "cue line alignment" (as we call it now) is changed dynamically with the line position of the cue box.

This approach has been shown for authors to result in unpredictable and uncontrollable positioning (e.g. when the cue box height changes, the vertical position of the text will change). This is why we brought in the explicit "line alignment" setting for cue boxes so authors can control it if they want to.

Now, the current state of the spec still has both approaches, so nothing has really changed, because the adjustment step will overrule the "line alignment" setting.


Here's a suggestion on how to change it:

* the position adjustment in step 11 should not be executed when the "cue line alignment" is explicitly set

* thus, we should introduce a "cue line alignment" value of "auto" which does the position- and height-dependent adjustments

* to make the spec more readable, the handling of "auto" should get into step 7


FWIW: we can then apply similar logic to snap-to-lines cues with "cue line alignment" be a default of 'start' when the lines are positive, and a default of 'end' when they are negative.

That should leave only overlap handling to step 11, which is a good thing, IMO.


Does that work for you?

So that we are all on the same page, here are the use cases for non-snap-to-line positioning that I'm aware of:

 * Speaker identification, maybe if the two speakers are on two separate floors of the same building.

 * Providing a translation for something on screen, like a sign in Japanese. I've seen this on a DVD once, but can't remember what the movie was.

 * Avoiding overlap with something on screen without moving the text to the complete opposite side, or when there's something to avoid at both the top and bottom. The cue would have to appear just above or below the thing on screen and grow away from it.

For none of these, the existing (background-position-like) positioning mode seems very helpful. Is there a use case for it? If we know of a better default, I would not mind dropping this mode if the usage is sufficiently low.

So, my thought is to make the vertical percentage positioning work similarly to the horizontal positioning:

 * line:x% points out an anchor point
 * lineAlign or something like it controls the direction in which text grows from that point: up, down or centered

That would seem to satisfy the use cases, as much as position/align satisfies them in the horizontal direction.

I like Silvia's idea of tying this into the direction of growth for snap-to-line cues. I would go further and say that we could then unify the overlap avoidance for both modes, so that even non-snap-to-line cues follow the same stepping algorithm to find a free position. If minimizing movement is important, we could make the step size 1 in this case, but I'm not sure it is.