This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24038 - [WebVTT] Cues with auto line position should default to cue line alignment of end
Summary: [WebVTT] Cues with auto line position should default to cue line alignment of...
Status: NEW
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Silvia Pfeiffer
QA Contact: This bug has no owner yet - up for the taking
Whiteboard: v1
Depends on:
Reported: 2013-12-09 21:23 UTC by Loretta Guarino Reid
Modified: 2014-05-13 13:31 UTC (History)
4 users (show)

See Also:


Description Loretta Guarino Reid 2013-12-09 21:23:23 UTC
This is related to bug 24037.

The cue line position description includes:

"If the text track cue snap-to-lines flag of the text track cue is not set, return the value 100 and abort these steps. (The text track cue line position is the special value auto.)"

The cue line alignment description says:
A text track cue has a default text track cue line alignment of start.

The box positioning algorithm will currently position the cue box with the bottom of the cue at 100%, but this contradicts the cue line alignment default. For auto-positioned cues, the default cue line alignment should be end.
Comment 1 Silvia Pfeiffer 2014-05-12 05:31:23 UTC
This bug was already discussed in:
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?
Comment 2 Philip Jägenstedt 2014-05-13 13:31:51 UTC
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.