If we made it apply to non-line-aligned cues, then you wouldn't know where stuff was going to be positioned, so you couldn't position cues precisely, which is the whole points of being able to position cues.

Is this because you expect edgemargin to be of different size between different players?

Edgemargin was introduced to avoid painting outside the visible area. So, if we position a cue explicitly and it lands outside the visible area, are you saying that's ok for explicitly positioned cues?

In my mind edgemargin reduces the viewport size to the visible area and anything that is explicitly positioned just gets squished a little, but still essentially sits in the right relative place, which is the important part. Cutting text off because it's outside the visible area is a worse solution in my opinion.

The spec says it's UA-defined.  That's what I'd expect, since most computer monitors and well-configured HDTVs have no overscan.  (Plus, nothing has overscan if you're in a window far from the edge of the screen.)  A smart implementation could disable overscan in these cases to avoid unnaturally large empty spaces on the edge of the screen/window.

(This also avoids baking overscan into WebVTT forever.  Overscan is much less of a problem than it used to be, and if it goes away completely in hardware some day, implementations should be able to define it as 0 and get rid of it.)

If you're precisely aligning cues to things on screen, you don't want your positions getting nudged around weirdly to fit within overscan.  If you're just saying "put this text near the top/bottom of the screen" then you do, but I guess the idea is that you wouldn't use percentages for that (though no doubt some people will anyway; if they do that may subvert this feature).

If that's the intention, then I don't understand why we make the application of edgemargin dependent on snap-to-lines set, which could also mean that somebody has explicitly set a "position" in the cue settings and that position could be positioning the cue in the left or right edge of the viewport, since exact positioning doesn't just happen in the "line" dimension.

I'm not sure how to deal with that, though. Maybe there needs to be an overlap avoidance with the edgemargin region in this case.

(In reply to comment #4)
> If that's the intention, then I don't understand why we make the application
> of edgemargin dependent on snap-to-lines set, which could also mean that
> somebody has explicitly set a "position" in the cue settings and that
> position could be positioning the cue in the left or right edge of the
> viewport, since exact positioning doesn't just happen in the "line"
> dimension.
> 
> I'm not sure how to deal with that, though. Maybe there needs to be an
> overlap avoidance with the edgemargin region in this case.

Only "line" sets snap-to-lines, not "position", right?

From what I can see, both "edge margin" and "snap-to-lines" are only relevant to positioning on the X axis[1].  They're only used when in "line-based" positioning, not in percent-based positioning, and the Y axis doesn't support line-based positioning in the first place.

(If it did--say, for CJK--then I expect it would have a separate flag, like "snap-to-columns", that respectively only affects the Y axis.)


[1] speaking in terms of horizontal text, of course

I was starting to write a reply, but then I realized that we can't do line-based positioning via "position" with anything but percentage. As you think with percentage positioning we should not apply an edge-margin, I concede, the spec is correct to your requirements.

(Note that I still maintain a different opinion: if there is an area of the screen where we are not able to read anything because of overscan, I maintain my opinion that we should not ever paint captions in there and rather move them out of there, no matter whether captions were explicitly positioned or not.)

No, I actually can't leave this alone. :-)

As currently specified, the edge margin is only applied to the left and right edges of the video (for horizontal cues). So, when we have overscan and are positioning in line -1, the left and right edges of the cue get the margin, but the cue still sits at the bottom boundary of the video viewport. (This is independent of whether the cue has a position value or not.)

Even given your condition that the edge margin is only applied to non-explicitly positioned cues - we still need to also apply it in y-position direction, not just in x-position dimension.

That all makes me wonder whether it wouldn't be easier to drop the whole idea of edge margin and instead tell players that need to avoid overscan to make use of the technique in bug 17273.

Gah, I implemented this and I double-checked it and I still didn't see it. There is a second section that does the y-position adjustment. So, forget that part of the last comment. (Sorry for the noise).

But the last idea may be a valid one still: to use viewport.occupy to achieve the same effect?

Yeah, we could potentially do that, it seems like it could make the implementation simpler.

I do not know what viewport.occupy means.

I don't understand the problem here.

Bug 17273. Sorry, the function is not called "occupy", but "add".

Having the UA add the area to the bug 17273 mechanism wouldn't work because it would not shift the lines up to abut the overscan area, instead it would shift the lines by an entire line-height.

FYI: the CEA-708 spec and its handling of overscan may be of interest
http://www.scribd.com/doc/70239447/CEA-708-B
in particular the image on pg 26

You'll see that it defines a "safe-image area" and the coordinates of the caption format are defined only on that area, including for explicitly positioned caption "windows" (as they call the rendering areas for cues).

Apparently they are not worried about position changes for explicitly positioned cues when the safe-image area differs between players and it's more important to make sure the captions end up in the "safe" area.

Yeah, but that standard dates from the 90s and drags into it stuff from decades prior. Overscan is a problem that will progressively go away, so we should plan ahead for when it's gone. If you position the cue precisely, why would be promptly go and ignore your settings?

CEA-708 was developed for Digital TV, originated in 1999, updated in 2002 and is only now being implemented in set-top boxes. I don't call that outdated.

The TV industry is a rather slower industry than the Web.

Considering that CEA-708 has more features than WebVTT and is born out of many years of experience with captions, we should look to learn from it, not ignore it.

Anyways - I am no longer fussed about this bug. It's always possible for players to define a smaller video viewport on which captions can be rendered if they have areas on the screen that need to be avoided. So I'm closing this bug as wontfix.