22085 2013-05-18 02:42:42 +0000 possibility to shrink the rendering area for timed text (webvtt) using CSS 2015-06-27 13:40:22 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC Windows NT NEW v2 P2 normal --- 22075 1 silviapfeiffer1 silviapfeiffer1 alexander.farkas brad caitlin.potter eric.carlson giles ian lorettaguarino mike philipj public-html-admin public-html-wg-issue-tracking public-texttracks silviapfeiffer1 zcorpan dave.null oldest_to_newest 87872 0 silviapfeiffer1 2013-05-18 02:42:42 +0000 +++ This bug was initially created as a clone of Bug #22075 +++ Authors need a way to shrink the rectangel in which the track cues are displayed using CSS. The webvtt features for positioning are not suitable here. A typicall usecase is a scripted custom styleable mediaplayer, where the controls are placed over the video rendering area. In this case the author needs a way to "reserve" this space for those controls. Due to the fact, that this is depending on the style of a webpage and not related to the contetnt of the vtt file, it has to be defined using CSS. For example: ::cuedisplay { top: 0; left: 0; right: 0; bottom: 40px; /* space is needed for overlaying custom styleable controls at the bottom of the video */ } 89023 1 ian 2013-06-10 21:27:08 +0000 Did you mean to file this on HTML? It seems like a WebVTT bug (or maybe CSS). 89030 2 silviapfeiffer1 2013-06-10 22:21:19 +0000 This is an alternative solution to the reserve() function in bug 17273, so I wanted to make sure you see it and consider it. Also see comments in bug 22075. It's not WebVTT specific, but general for displayed track cues. 89330 3 ian 2013-06-14 18:52:31 +0000 Ah, ok. Thanks for the heads-up. I don't have an opinion on whether we should do this with CSS or script (assuming there's even still any browser interest to do this, which isn't clear to me given the silence on bug 17273). If we want to do this in CSS, though, we should move this to the CSS component to get the CSS side done first, so we have something to hook into. 89345 4 silviapfeiffer1 2013-06-15 04:53:16 +0000 I think introducing a possibility to reduce the available rendering space for captions (as in: shrinking the video viewport) is important. If we had something like that, we could even remove the hooks that were put into WebVTT for overscan and make it a generic feature to change the rendering viewport. I would, however, put the use case in bug 17273 for creating "holes" on the viewport into the 20% bucket and leave it to JS devs. I'm adding Simon to this bug for comment. 89384 5 zcorpan 2013-06-17 08:33:22 +0000 I don't have anything to add that I didn't already say in Bug #22075. 90131 6 ian 2013-07-02 19:53:10 +0000 Silvia, I'm reassigning this to you to push this through the CSS working group, since it's not really an HTML thing. Please don't hesitate to reassign it back to me if there's something that needs to be done in HTML for this. 90704 7 silviapfeiffer1 2013-07-13 08:59:04 +0000 Simon, you're on the CSS WG - I'm wondering: is this similar to the ::cue pseudo-element in WebVTT, so can we just define it in the WebVTT spec, or should we take it to the CSS WG? 90706 8 silviapfeiffer1 2013-07-13 08:59:47 +0000 *** Bug 22075 has been marked as a duplicate of this bug. *** 91723 9 zcorpan 2013-08-07 12:47:13 +0000 Since it's a CSS feature it makes sense to keep the CSS WG in the loop but I think the WebVTT spec is a suitable place to put it. 100917 10 lorettaguarino 2014-02-19 18:15:14 +0000 We agree that a CSS solution like this is preferably to the Javascript proposal in bug 17273. 113397 11 philipj 2014-10-17 21:21:55 +0000 *** Bug 25637 has been marked as a duplicate of this bug. *** 121466 12 philipj 2015-06-24 15:35:48 +0000 A request for better control over this has come up for Chromecast: https://code.google.com/p/chromium/issues/detail?id=503233 121498 13 silviapfeiffer1 2015-06-27 13:40:22 +0000 Following the request in the bug, we'd need to introduce a "cue viewport" as a box inside the "video viewport" and then replace all mentions of "video viewport" with this "cue viewport" (or "cue display", but I think "viewport" works better). Then we can associate the proposed CSS with that "cue viewport". Obviously also needs introduction of a new pseudo-element ::cueviewport . I can specify that, but would browsers implement it? (Adding Eric & Ralph for this question)