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 cue text rendering rules are different when snap-to-lines is set and when it is not set. When it is not set: 1. The first step recalculates x and y, although snap-to-lines has already been considered in step 9. I believe the results are the same, but it is confusing and a potential source of error if the two ever get out of sync. 2. But more important, the next step repositions the boxes, based on the current position value. This has a number of unfortunate effects: * If the author knows where the caption should be positioned, and that position is neither centered nor against the left or right edge, it is very difficult to calculate what value to set for position so that the adjustment yields the desired location. * For align:middle captions, it is impossible to position the cue anyplace but centered in the viewport, since the adjustment will always move the 50% position of the box to the 50% position of the viewport. So no centering captions in the left half of the viewport, for instance. * Captions that are positioned against either edge are not repositioned. Since this is a common case, the repositioning often isn't noticed or needed at all. Changing line position from line number to percentage should not have this effect on the text position. I request that when snap-to-lines is not set, the values of x and y be used as computed, without adjustment, then repositioned to address any overlaps.
You mean Section 3.5 (WebVTT cue text rendering rules), step 10 (run following substeps for each cue), substep 8 & 9 calculate the x-position & y-position for any cue, no matter whether snap-to-line or not, but then in substep 14 for snap-to-lines flag not set, we calculate the x & y positioning again? It is a bit confusing, but here is what I make of it. In substeps 8 & 9 we calculate temporary positions x-position and y-position, which we indeed apply to CSS as left and top in step 11. But step 14 is applied to line boxes, which are in an anonymous background box together with other node children. So, this is trying to move the individual lines within the background box to the right position. Assuming I understood correctly, that still does not address the problem that you are seeing, namely that position and alignment interact in an unexpected way such that it is not possible to e.g. center captions in the left half of the viewport. I think this is related to bug 18501.
I've given this a go and I think when snap-to-lines is false, we need to rewrite substep 14, subsubstep 2 from: 2. 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. To something like: 2. Position the boxes in boxes such that: * for left aligned or (start aligned & ltr) horizontal cues the 0% point 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, * for middle aligned horizontal cues the 50% point 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, * for right aligned or (end aligned & ltr) horizontal cues the 100% point 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.
Another thought on this: can we separate use of % for line position from whether snap-to-lines is true? My use cases seem to want snap-to-lines behavior, but use % values for line location. Perhaps, if snap-to-lines is true, line% could be automatically resolved to the closest line. I suppose this has the potential for mapping separate %-based lines to the same line number, but we probably already have rendering overlap happening if this is the case and we use absolute positioning.
*** This bug has been marked as a duplicate of bug 20037 ***
Reopening since this wasn't addressed in bug 20037
(In reply to Philip Jägenstedt from comment #5) > Reopening since this wasn't addressed in bug 20037 Can you explain what cases that are mentioned here aren't fixed? IMO, the bug - which is both about horizontal and vertical features - has been addressed in fixes around bug 20037 and bug 23404. Here are the mentioned examples and how they work now: * line alignment now has no effect any more on horizontal positioning * centering captions in the left half of the viewport is now possible with the following cue settings: align:center [provides for center aligned text] size:50% [provides for 50% videwport size] position: 25%,middle [provides for a cue box that is middle aligned around the 25% mark] * comment #2 is referring to the overlap avoidance algo, which we might want to separate out and work on in a separate bug * comment #3 is a new use case, where non-snap-to-lines cues are requested to snap to lines - we should deal with this separately. Loretta, if that is still an issue, can you open a new bug for that? Closing as fixed for now.
Comment 1 says "The cue text rendering rules are different when snap-to-lines is set and when it is not set" but the changes in bug 20037 and bug 23404 have to do with horizontal positioning and lineAlign (text track cue line alignment) only has an effect for non-snap-to-lines, so I gathered something must be missing. Loretta, what was the core problem in this bug and has it been addressed?
Note bug 24038
The core problem was the confusing interaction between size and position, and line and computed height, for non-snap-to-line cues. The addition of positionAlign and lineAlign solved that problem for me, since then it was possible to explicitly control the anchor points. If we are going to drop those attributes, we should be sure that this problem is still addressed.
(In reply to Loretta Guarino Reid from comment #9) > The core problem was the confusing interaction between size and position, > and line and computed height, for non-snap-to-line cues. The addition of > positionAlign and lineAlign solved that problem for me, since then it was > possible to explicitly control the anchor points. If we are going to drop > those attributes, we should be sure that this problem is still addressed. Do you see a need for positionAlign even with the updated positioning model? The demo I made lets you try how all of the models work, with no positionAlign: http://people.opera.com/philipj/2014/05/vttposition/ lineAlign does solve a problem when you're trying to avoid overlap with something above or below the cue text. I think the name is a bit non-obvious, but I now accept that the use case is worth supporting in some way or another.
I'm reopening this again because as Silvia found in https://github.com/w3c/webvtt/pull/92 the original problem is still in the spec. To summarize, when snap-to-lines is set, it changes the positioning model in both axes, not just in the up/down direction (for horizontal text). The bounding box of the text (already rendered in a temporary position) is positioned in a manner similar to CSS background-position. AFAICT, positionAlign is only tangentially related, it would be weird with or without it.
An additional problem is that this section still makes the interpretation of position depend on the (calculated) text direction. In http://foolip.github.io/webvtt/ I merged those two cases, so obviously that's what I think should be done.
(In reply to Philip Jägenstedt from comment #12) > An additional problem is that this section still makes the interpretation of > position depend on the (calculated) text direction. In > http://foolip.github.io/webvtt/ I merged those two cases, so obviously > that's what I think should be done. Oh, this was actually silently fixed in https://github.com/w3c/webvtt/pull/92 (will request that it is fixed separately)
I have a proposed fix at https://github.com/w3c/webvtt/pull/100
The patch was committed, but Philip noticed that it created a new bug, now registered and followed up with in bug 26056 .