John, please help to loop in WebVTT spec folks.

Want to understand first whether this is working as intended.

Fredrik, can you comment?

This issue appears to be related to changes for https://bugs.chromium.org/p/chromium/issues/detail?id=551245

+silvia +fs can you comment on whether the behavior described here is a bug, or as intended by the VTT spec?

The example appears to render per spec. The change made in CL (reflecting a spec-change from long ago) was to stop using an anchor point that followed the specified "line position" (like for the 'background-position' property) and rather always have static anchor point (which can be set via 'lineAlign', so "line:90%,end" as an example.)

Thanks.  So just to be clear, when you put line:90% in vtt, the browser is supposed to just start at 90% down the video and never mind if that forces a bunch of text off the bottom of the video element (and be invisible)?

I don't find the spec immediately clear to understand this.  And also noticed that Firefox positions the cue so all the text is within the video element in this case.

The relevant spec section is https://w3c.github.io/webvtt/#apply-webvtt-cue-settings - primarily steps 6 and 11.
I guess this could come down to sub-step 4 of the snap-to-lines==false branch of step 11 - i.e the "dodging step", which isn't implemented in Blink. Maybe it's implemented in Gecko. That part of the algorithm would most likely end up pushing the cue upwards in this simple single-cue case. That would make this a dupe of issue 314037.

The wording in the sub-step 4 of step 11 (snap-to-lines==false branch) is confusing. I had to understand it as this: if "not all the boxes would be within the video's rendering area" then the box "SHALL" be moved (if possible) as little as possible to achieve that "the boxes would be within the video rendering area"? 

Am I right or I missed something?

This conflicts with "Cues where the flag is false will be offset as requested (modulo overlap avoidance if multiple cues are in the same place)." text in the specification. But it makes sense. At least I don't see why browser would display something that is not desired but can be fixed.

The spec would benefit from some revision. The definition of "WebVTT file using only nested cues" is wrong. (the example doesn't fit the definition). So it's very confusing to someone new to this like me.

The spec does require the cue not to be overlapped. But when it comes "does it require the cue be displayed within the video rendering area?", I think one spot in the spec says "no" but the other spot says "yes". So I doubt it is the exactly the same as issue "314037". However, they are closely related and similar in nature.

chrome implementation takes it as "no" but firefox implementation takes it as "yes"

So vtt file author must use "WebVtt cue line alignment" as "end alignment" in the case of snap-to-lines==false to display multiple line subtitle correctly within Chrome? 

> This conflicts with "Cues where the flag is false will be offset as requested (modulo overlap avoidance if multiple cues are in the same place)." text in the specification.

No, the "...modulo overlap avoidance..." bit is exactly this, so there's no conflict.

I don't see an issue with the "nested cues" section, but feel free to raise an issue at https://github.com/w3c/webvtt/issues/new.

I also don't see the ambiguity with "within the rendering area", but if you do please raise an issue on the spec - there should be no ambiguous behavior in the spec. The "new" spec behavior for snap-to-lines==false cues would seem to stress the overlap avoidance more than the "old" behavior though, which would suggest that issue 314037. I'm going to dupe this now since it seems that's the core issue here. (Any spec issues should be discussed in the spec issue tracker.)

And finally, different alignments will give different edge cases, so there will not be a one-size-fits-all value.

A quick note about "nested cues": look at that example, the definition says "given ANY two ...", Now we pick two cues "Topics" and "Presenters", NEITHER of two condition is true. But this is not relevant to the subtitle problem. 

So "modulo overlap avoidance" includes "avoiding cue displayed out of video rendering area"? I thought it only means that "avoid display more than one cue in the same area". 

I could hardly understand that subtitle cut off by the boundary of video is considered a kind of "overlap". 

regardless how to interpret "overlap", the complete text is
"Cues where the flag is false will be offset as requested (modulo overlap avoidance if multiple cues are in the same place)."

notice the text in the prethesis, in our case there is no multiple cues, so this exception doesn't apply. The above text from spec instructs to put the text as "requested" (even if it is cut off the boundary". )

So what we'd like to achieve here, i.e., avoid the test being cut off, is not "avoiding overlap", at least to someone who read this paragraph in the spec. This is the conflict I was talking about, and if not marked clearly this issue won't be resolved in the issue 314037. 

If you want the spec to be clarified ("...if multiple cues are in the same place or a cue overlaps the rendering area" or some such) you can raise an issue. This section of the spec is not overly interesting (informational rather than normative) from an implementation PoV though - the rendering steps are, and those are clear at least to me.

On chromecast the captions are cut off on boundary, and it is a critical issue to us. What I am more concerned with is that the issue is reported, acknowledged, and hopefully will be fixed soon.

Thanks.

Hi fs@opera.com, thanks very much for you advice! We are working on a workaround for now.