This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The data model for line positioning is defined in: http://dev.w3.org/html5/webvtt/#dfn-text-track-cue-line-position If line is auto (i.e. not set), then the line position is determined based on the other text tracks that are showing. I have several issues with this approach: Firstly, it assumes that each cue is only one line long and thus adds "1" to the line position of every track. This is a faulty assumption. Secondly, it would be better to have the same overlap avoidance that applies to multiple cues within a track applied to all cues that are active at a certain point in time. I'm therefore suggesting to remove steps 4 - 10 of that algorithm.
Also, the notion of "text track cue computed line position" is only used in the rendering section so it should be moved there completely.
(In reply to Silvia Pfeiffer from comment #0) > The data model for line positioning is defined in: > http://dev.w3.org/html5/webvtt/#dfn-text-track-cue-line-position > > If line is auto (i.e. not set), then the line position is determined based > on the other text tracks that are showing. > > I have several issues with this approach: > > Firstly, it assumes that each cue is only one line long and thus adds "1" to > the line position of every track. This is a faulty assumption. Assuming the cues are rendered in the correct order then even if they are multi-line they should move due to overlap avoidance, so they should end up in the correct order. However, if that's true, I'm not sure why they can't all be placed at -1 to let the overlap algorithm do all the work. > Secondly, it would be better to have the same overlap avoidance that applies > to multiple cues within a track applied to all cues that are active at a > certain point in time. I think this is already the case, the rendering section already considers all the tracks together. > I'm therefore suggesting to remove steps 4 - 10 of that algorithm. To help illuminate this issue, can you show an example where the rendered result would be different and how removing these steps is better? (If there aren't any cases where this matters then of course the steps can be removed.)
This is a 18 months old and the line numbers probably don't apply any longer. I'm going to close this, since we are now discussion on list how to integrate the rendering algorithms. Whatever we come up with there should be applied and not this.