This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When adjusting the position of cue boxes, if a cue's text track cue snap-to-lines flag is not set, step 2 says "Position the boxes in boxes such that the point x% along the width of the bounding box of the boxes in boxes is x% of the way across the width of the video's rendering area, and 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, while maintaining the relative positions of the boxes in boxes to each other." I thought the line alignment and position alignment would be used to determine which point in the cue box is specified by the positions, rather than using the line and position values as the anchor points. Is the spec just lagging behind here? The alignment values are used above in step 7 when computing the x-position and y-position. However, when we get to the step of adjusting the boxes, these values appear to be discarded and we use the algorithm described above.
Not sure that we've found agreement on how the position is supposed to work yet, but we should get the story straight for v1 at least.
Yes, the rendering part still needs some clarifications.
Point 11 and 12 of the rendering algorithm (Processing Model section) relate to the overlap avoidance, but with some cruft left over in point 11. I'll need to spend some time wading through it.
Silvia, have you made any changes to the overlap handling? What is the cruft that is left over?