This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ 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 */ }
Did you mean to file this on HTML? It seems like a WebVTT bug (or maybe CSS).
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.
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.
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.
I don't have anything to add that I didn't already say in Bug #22075.
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.
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?
*** Bug 22075 has been marked as a duplicate of this bug. ***
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.
We agree that a CSS solution like this is preferably to the Javascript proposal in bug 17273.
*** Bug 25637 has been marked as a duplicate of this bug. ***
A request for better control over this has come up for Chromecast: https://code.google.com/p/chromium/issues/detail?id=503233
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)