Should line:100% render the cue offscreen?

[jonknowles]

The spec says that line "offsets the cue box from the top, the right or left of the video viewport". I understand this to mean that for horizontal cues, the top of the cue box is offset from the top of the viewport in proportion to the percentage value of the line setting (or by some factor of line-height for integer line settings). So a line:0% would be flush to the top of the viewport. If that is so, it seems like line:100% cues should be offset all the way offscreen at the bottom of the viewport, like so:

 ____________________________________________________________
|                         line:0%                            |
|                         line:10%                           |
|                         line:20%                           |
|                         line:30%                           |
|                         line:40%                           |
|                         line:50%                           |
|                         line:60%                           |
|                         line:70%                           |
|                         line:80%                           |
|_________________________line:90%___________________________| 
                          line:100%   

I noticed that Chrome will keep line:100% cues on screen, but Firefox lets them go offscreen. The videojs/vtt.js implementation seems to have logic to nudge the line:100% cue back onto the viewport here: https://github.com/videojs/vtt.js/blob/master/lib/process/move-box-to-line-position.js#L14:L40

But I don't see this behavior defined in the spec (maybe I'm overlooking something). I Is it expected that line:100% cues will be rendered offscreen?

[fsoder]

I think the repositioning is speced by step 10.4 (The "...WebVTT cue snap-to-lines flag is false" branch) in [1]:

4. If there is a position to which the boxes in boxes can be moved while maintaining the relative positions of the boxes in boxes to each other such that none of the boxes in boxes would overlap any of the boxes in output, and all the boxes in boxes would be within the video’s rendering area, then move the boxes in boxes to the closest such position to their current position, ...

[1] https://www.w3.org/TR/webvtt1/#processing-cue-settings

[jonknowles]

Excellent, thank you @fsoder for pointing that out, that section definitely seems to be the source for that vtt.js function, and it seems to imply that (even if there's only one cue box, I assume), it should be moved to the closest position onscreen.

[gkatsev]

I really need to go through the PRs against this repo...
That section is will be marked at-risk as part of #460 (https://htmlpreview.github.io/?https://github.com/gkatsev/webvtt/blob/at-risk-june/archives/2019-06-19/Overview.html). This is because there's basically no consistency between implementations. Also, an argument could be made that when snap-to-lines is false, it's up to the author of the captions to make sure that captions should be positioned properly to not overlap.
If step 10.4 when snap-to-lines is false is removed, this question actually should be answered.