16864 2012-04-26 10:14:18 +0000 [WebVTT] Allow using a smaller viewport for position/size of cues 2012-10-15 05:37:55 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All RESOLVED FIXED P2 normal --- 19536 1 zcorpan ian ian mike philipj public-texttracks silviapfeiffer1 dave.null oldest_to_newest 67103 0 zcorpan 2012-04-26 10:14:18 +0000 TVs with overscan would render cues outside the screen if they have their default position and the video is in fullscreen. This seems undesirable. I think it should be allowed to use a smaller viewport size for the purpose of text size and cue positioning of cues. 67133 1 ian 2012-04-26 22:27:03 +0000 Why would we allow video outside the screen if we don't allow text outside the screen? What if the video has a <div> overlaid on it with text on it? 67181 2 zcorpan 2012-04-30 09:15:54 +0000 > for the purpose of text size and cue positioning of cues. Possibly text size still needs to be calculated from the video's full size, so that the text doesn't appear too small on a TV without overscan if we think it has overscan. > Why would we allow video outside the screen if we don't allow text outside the screen? Allowing video outside the screen is the point of overscan. I'm not a fan of it myself, but it's a reality. It's quite possible to watch a video where the edges are cut off without losing any vital information. However, if all the subtitles are invisible, that's quite different. > What if the video has a <div> overlaid on it with text on it? I don't know what to do about that. 71357 3 ian 2012-07-24 05:56:25 +0000 I think we should just make overscan non-conforming for <video>. 71362 4 philipj 2012-07-24 08:56:55 +0000 Alternatively, we could just have some margins by default. Currently, the default line position is aligned perfectly with the bottom of the video, which looks rather bad, really. Having 1 or 2 line height margin by default would fix the overscan problem and make things look better (by default) on any device. 71868 5 ian 2012-08-06 23:06:46 +0000 Fair enough. How about making just one change, namely, allowing the snap-to-lines lines be positioned inset a bit if the user agent wants to, but leaving the %-positioned text and the default font size, etc, be unchanged? Would that work? 71870 6 silviapfeiffer1 2012-08-07 01:32:56 +0000 (In reply to comment #5) > Fair enough. How about making just one change, namely, allowing the > snap-to-lines lines be positioned inset a bit if the user agent wants to, but > leaving the %-positioned text and the default font size, etc, be unchanged? > Would that work? I would think the video height that is the basis for the % calculation then has to be reduced by that inset. 75732 7 ian 2012-10-09 21:48:24 +0000 Part 1: http://html5.org/tools/web-apps-tracker?from=7445&to=7446 75748 8 ian 2012-10-09 22:55:59 +0000 Part 2: http://html5.org/tools/web-apps-tracker?from=7446&to=7447 76094 9 philipj 2012-10-12 12:32:26 +0000 I've looked through the spec changes and it looks mostly good. It would be nice if a default (edge) margin were specified, e.g. 5vh. It would also be nice if it could be specified with CSS while still allowing a minimum to be enforced by the UA. However, I'm not sure on what pseudo-element and using which property specifying this would make sense. Something like ::cuebox { padding: 5vh; } looks OK, but it may seem strange that it's ignored for positioned cues (snap-to-lines is false).