This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Here are some thoughts I have about the rendering algorithm from section 3.5 (10.13 - case snap-to-lines is false) The algorithm seems to combine two different features (anchor point and anchor point position), under the same numerical values (x%, y%). It sets the to point (x%, y%) within the cue box at (x%, y%), which is a very legit approach for cues that don't have changing content (as pop-on captions), as it ensures that no content of the window will be outside the viewport. However, when it comes to cues that adjust their contents or size, things might get complicated because of the fixed combination, (this means, but is not limited to: font change, background change, content change - paint-on or roll-up). The effect is that (x%, y%) in the interior of the cue box will have different absolute values within the video viewport, creating a not very pleasant display effect, by moving the whole displayed cue (instead of keeping it fixed and append text to it - when text is changed dynamically, for paint-on, specifically). One solution I can think of is to keep these separate one from the other. The anchor point within the cue box would actually specify the direction in which the cue box expands, as content changes. Another solution might consist in specifying explicitly how paint-on captions are positioned when only a partial text from the full-text is visible, such that there is no room for interpretation (e.g. if I'm seeing 'ab' from text 'abcd' x%, y% should refer to the final 'abcd')
Cues currently can't change the content or size, so this seems moot.
Ian: What happens when the user changes the font or the font size in the middle of video playback? That seems to create a content change and is something that a browser has to deal with.
Hm, interesting point. I guess if there's an environment change of that nature we should wipe out the list of currently displayed cues (whatever we call it) and start over.
So it seems there are two issues here: (1) re-running the rendering rules when cue text or styleing or video viewport etc change (I think there's a separate bug raising this issue as well). (2) inability to position cues and knowing where e.g. the left edge will end up being if you don't know the cue text or the user's font size or whether it will wrap, and so forth. Currently the spec uses a "floating" anchor point when positioning a cue using the position and line setting (using %), like background-position in CSS, but this makes it hard to know where the cue will actually appear if you don't know what the size will be. It's not unlikely that people will want to have left-aligned cues that start from a certain point to the left and want that point to be the same for all cues, regardless of their size. In order to solve that problem, we could introduce a way to specify the anchor point for positioning cues.
(In reply to comment #4) > In order to solve that problem, we could introduce a way to specify the anchor > point for positioning cues. I would like to propose to extend this to specifying a rendering area into which one or several cues may be rendered. The rendering area would be defined by a percentage width (just like "size" currently works) and a number of lines height, and it would be anchored. This would help us solve several requirements: * we can exactly position the rendering area and the cues rendered therein * we can define a background color on the rendering area * with the defined height of the rendering area we can introduce a rollup feature such that adding cues to the rendering area will push previously added cues up or down within the n lines rendering area All three of these features, plus the concept of rendering areas are requirements in the FCC caption act (there, the rendering area is called a "window"). If we design this carefully, it can be an advanced feature that can fall back to current cue rendering rules for UAs that don't support the "window" concept.
BTW: the FCC order is at http://www.fcc.gov/document/closed-captioning-internet-protocol-delivered-video-programming-0
Silvia, rollup is off-topic for this bug.
(In reply to comment #1) > Cues currently can't change the content or size, so this seems moot. They can with the DOM API and style sheets.
(In reply to comment #7) > Silvia, rollup is off-topic for this bug. Agreed. My proposal was just trying to generalize the proposed solution and thus allow for a simple resolution of other issues as well. However, we can take it step by step if that's preferable.
(In reply to comment #8) > (In reply to comment #1) > > Cues currently can't change the content or size, so this seems moot. > > They can with the DOM API and style sheets. They can't change content or size even that way, since once a cue is being rendered, its boxes aren't recomputed. Only things like 'color' take effect. I couldn't find a bug asking for cues to be reset if the style sheet changes. If you would like that to happen (which is needed if you want style sheet changes to take effect when they resize the active cues), please file a bug. Note that doing this while the video is playing would be annoying for users, so maybe we should limit this to only when the video is paused. Regarding how %s work for positioning, I think we should just redesign the positioning mechanism.
*** This bug has been marked as a duplicate of bug 20037 ***