This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22085 - possibility to shrink the rendering area for timed text (webvtt) using CSS
Summary: possibility to shrink the rendering area for timed text (webvtt) using CSS
Status: NEW
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Silvia Pfeiffer
QA Contact: This bug has no owner yet - up for the taking
Whiteboard: v2
: 22075 25637 (view as bug list)
Depends on: 22075
  Show dependency treegraph
Reported: 2013-05-18 02:42 UTC by Silvia Pfeiffer
Modified: 2015-06-27 13:40 UTC (History)
14 users (show)

See Also:


Description Silvia Pfeiffer 2013-05-18 02:42:42 UTC
+++ 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 */
Comment 1 Ian 'Hixie' Hickson 2013-06-10 21:27:08 UTC
Did you mean to file this on HTML? It seems like a WebVTT bug (or maybe CSS).
Comment 2 Silvia Pfeiffer 2013-06-10 22:21:19 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2013-06-14 18:52:31 UTC
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.
Comment 4 Silvia Pfeiffer 2013-06-15 04:53:16 UTC
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.
Comment 5 Simon Pieters 2013-06-17 08:33:22 UTC
I don't have anything to add that I didn't already say in Bug #22075.
Comment 6 Ian 'Hixie' Hickson 2013-07-02 19:53:10 UTC
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.
Comment 7 Silvia Pfeiffer 2013-07-13 08:59:04 UTC
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?
Comment 8 Silvia Pfeiffer 2013-07-13 08:59:47 UTC
*** Bug 22075 has been marked as a duplicate of this bug. ***
Comment 9 Simon Pieters 2013-08-07 12:47:13 UTC
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.
Comment 10 Loretta Guarino Reid 2014-02-19 18:15:14 UTC
We agree that a CSS solution like this is preferably to the Javascript proposal in bug 17273.
Comment 11 Philip J├Ągenstedt 2014-10-17 21:21:55 UTC
*** Bug 25637 has been marked as a duplicate of this bug. ***
Comment 12 Philip J├Ągenstedt 2015-06-24 15:35:48 UTC
A request for better control over this has come up for Chromecast:
Comment 13 Silvia Pfeiffer 2015-06-27 13:40:22 UTC
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)