16920 2012-05-03 14:55:56 +0000 <track> Should run "rules for updating the text track rendering" when cue properties or styles have changed 2013-07-02 22:22:30 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#media-playback P3 normal Unsorted 1 contributor ian ian mike silviapfeiffer1 zcorpan contributor oldest_to_newest 67290 0 contributor 2012-05-03 14:55:56 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#media-playback Complete: http://www.whatwg.org/c#media-playback Comment: Should run "rules for updating the text track rendering" when cue properties or styles have changed Posted from: 88.131.66.80 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.229 Version/11.62 67291 1 zcorpan 2012-05-03 15:00:00 +0000 When the following properties have changed for an active cue, the rules for updating the text track rendering should be run: the properties corresponding to the 'font' shorthand, including 'line-height' 'white-space' When an active cue gets one of the following properties changed, the rules for updating the text track rendering should be run: vertical snapToLines line position size align text Also when changing startTime and endTime we might want to check if the cue should be currently active or not. This should be done even if the video is paused, except if video playback hasn't ever started yet. 67473 2 zcorpan 2012-05-08 10:48:09 +0000 Also when the native controls become visible or not visible. 70835 3 contributor 2012-07-18 17:35:50 +0000 This bug was cloned to create bug 18184 as part of operation convergence. 71537 4 ian 2012-07-26 23:31:20 +0000 Not sure I agree about doing it when the controls appear/disappear, but I guess we should at least allow it. 75131 5 ian 2012-10-02 22:45:51 +0000 Turns out the spec already does it for when the controls appear/disappear. Still need to do startTime/endTime changes. Actually, it's more than that, because it looks like we don't yet handle showing captions when they're added while the video is paused, either. 75132 6 ian 2012-10-02 22:47:05 +0000 (Not quite sure how to fix that.) 75133 7 contributor 2012-10-02 22:48:08 +0000 Checked in as WHATWG revision r7430. Check-in comment: Updating cues' styles and properties dynamically should be visible immediately http://html5.org/tools/web-apps-tracker?from=7429&to=7430 86219 8 ian 2013-04-15 18:14:09 +0000 I'm not 100% sure this fix (see diff in next comment) really works, so if you see a problem with it please don't hesitate to reopen this bug (or file a new one). 86220 9 contributor 2013-04-15 18:15:42 +0000 Checked in as WHATWG revision r7835. Check-in comment: Make adding a cue, or changing its timings, work when the video is paused. http://html5.org/tools/web-apps-tracker?from=7834&to=7835 86274 10 zcorpan 2013-04-16 08:06:21 +0000 I think you overlooked this part in the two commits above: "This should be done even if the video is paused, except if video playback hasn't ever started yet." Otherwise it looks good I think. 86466 11 silviapfeiffer1 2013-04-22 12:59:11 +0000 I also think that this line was changed by error: -<!-- EDITOR NOTES -*- mode: Text; fill-column: 100 -*- +ne<!-- EDITOR NOTES -*- mode: Text; fill-column: 100 -*- 88661 12 ian 2013-06-04 20:52:08 +0000 zcorpan: What's the right way to trigger this when paused-but-not-started? Just call "time marches on" in the paragraph that adds the stuff to "list of newly introduced cues" when the element is paused, unless its "show poster flag" set is set? 88688 13 zcorpan 2013-06-04 23:06:07 +0000 Yeah... or maybe bail out of "time marches on" as the first step if "show poster flag" is set. 89203 14 contributor 2013-06-12 19:38:37 +0000 Checked in as WHATWG revision r7965. Check-in comment: Make cues that are added while a video is paused get rendered before it gets unpaused. http://html5.org/tools/web-apps-tracker?from=7964&to=7965 89208 15 zcorpan 2013-06-12 20:42:51 +0000 Don't the cases that invoke "time marches on" in http://html5.org/tools/web-apps-tracker?from=7834&to=7835 (except the first one) also need to check the show poster flag? Does the new commit add anything that wasn't already required? 89531 16 ian 2013-06-19 00:34:03 +0000 In answering your questions, I concluded that this was a big mess, and I tried fixing this all over again. Take a look at the next text, let me know what you think. Thanks! 89555 17 zcorpan 2013-06-19 06:37:55 +0000 http://html5.org/r/7990 89557 18 zcorpan 2013-06-19 07:04:21 +0000 + false, queue a task to fire a simple event named <code + title="event-media-play">play</code> at the element, queue a task to fire a + simple event named <code title="event-media-playing">playing</code> at the element, and + then, if the element's show poster flag to false, first set it to false and then + run the time marches on steps. "then" being after the tasks have been queued? Or after they have run? If the latter, maybe it would be clearer to queue a third task? Also s/to false/is true/ Otherwise it looks good, I think. 90159 19 ian 2013-07-02 22:22:22 +0000 I meant it to happen synchronously, before the tasks run, after they're queued. Normally I'd queue them last, but then it's unclear if the queuing depends on the flag or not, etc. Anyway I made this better by using a list instead of a single paragraph. Thanks for reviewing it! 90160 20 contributor 2013-07-02 22:22:30 +0000 Checked in as WHATWG revision r8012. Check-in comment: Clarify how autoplay and subtitles interact. Mostly editorial cleanup, though I change a 'false' to a 'true', so not entirely. http://html5.org/tools/web-apps-tracker?from=8011&to=8012