- From: Alastor Wu via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Jun 2016 08:28:46 +0000
- To: public-texttracks@w3.org
alastor0325 has just created a new issue for https://github.com/w3c/webvtt: == The problem about recomputing cue's position == https://w3c.github.io/webvtt/#processing-model > If the last time these rules were run, the user agent was not exposing a user interface for video, but now it is, optionally let reset be true\. Otherwise, let reset be false\. tl;dr, the problem is "**two same cues may be rendered at different position**". Think about this situation, first, we let reset be true when the control interface changes from invisible to visible, and the control interface would be hided if user's cursor is moving out of video. Then we have two cues, and the writing direction is "horizontal". > 00:00:05.000 --> 00:00:08.000 > Cue 1 > 00:00:09.000 --> 00:00:10.000 > Cue 2 #### Step 1 : play video from 00:00:00 to 00:00:08 In the time 00:00:05, we assume the control interface exists when the cue1 is rendering. Therefore, we would move cue1's position up to avoid overlapping with the control interface, and these CSS position boxes are also stored in cue1's display state. In this moment, the cue1's display state has a set of CSS boxes, but cue2 doesn't. #### Step 2 : immediately seek back to 00:00:00 and play video to 00:00:10 In this case, we assume that the control interface is hiding in the time 00:00:05. Therefore, the reset is false and the cue1's display state isn't empty, so we don't recompute its position. [1] When rendering cue2, we still assume the control interface is hiding. Therefore, the cue2 position wouldn't be affected by control interface's CSS box. That means **_cue1's position would be higher than cue's position_**, and it's the problem we got. **Both cues are rendering without control interface, but their position is not the same.** Please correct me if my understanding is wrong :0 ---- In step2, Chrome would recompute the position of the cue1 to make sure it wouldn't be rendered at wrong position (the same position as step1). So, question is, is this behavior we want? If not, should we mention that the position of the cue1 must be recomputed in such kind situation? Thanks :) [1] Step 13 in https://w3c.github.io/webvtt/#processing-model Please view or discuss this issue at https://github.com/w3c/webvtt/issues/299 using your GitHub account
Received on Wednesday, 1 June 2016 08:28:49 UTC