[Bug 13435] Editorial changes to The Video element (3 of 5)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13435

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #4 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-08-10 00:10:54 UTC ---
(In reply to comment #3)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale:
> 
> Doing this would be massively complicated. By the time we reach the point where
> the right video frame is not being rendered, the events have already fired on
> the cues to tell them that they're no longer active (that has to be the case so
> that pauseOnExit cues can work). This means the cues might have been changed
> (e.g. if the script is preparing cues behind the scenes in preparation for
> going back to play the segment of video, etc). I really don't see how we could
> cause the cues to display regardless — the captions might be being rendered
> by the script itself, so we'd have to do something crazily complicated like
> fake the currentTime back to the time of the last frame, but only for the
> captions not the buffering... It would be a huge gnarly mess.
> 
> However, all is not lost — indeed things here are nowhere near as bad as it
> may seem. In practice, there are two cases where this might happen: if the
> video runs out while playing, and if the user has seeked.
> 
> In the normal playback case, the only way this could be visible is if the very
> next frame after the last frame displayed was the one at which the captions
> would have gone away anyway. In that case, it really is not an accessibility
> problem, unless one is going to argue that there is some big accessibility
> difference between a video stalling at frame 302923 or at frame 302924, which
> seems unlikely.
> 
> In the seek case, the user probably explicitly moved the video playhead, so
> IMHO it's really hard to argue that the user still needs the captions in that
> case. If the user wanted the old captions, he could just have seeked to the
> point where those captions were present. Indeed if anything it makes the
> captioned experience better than the non-captioned experience since it means a
> user can scrub the seek bar and quickly scan through all the subtitles without
> having to wait for the video to load.


I think you're over-interpreting this bug to be asking for more than it is. The
request is actually very simple: when the video is paused and displays a video
frame, it should also display the associated caption text with that frame. I.e.
the request is that when pausing the video, the captions will not suddenly
disappear from the screen. If there is no caption text associated with the time
of that frame, then naturally there won't be any overlayed text.

I think this should be possible, even if we disregard potential slight timing
glitches between the video and the text track. This is more about not removing
the caption text when pausing than it is about getting the timing absolutely
correct.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 10 August 2011 00:10:56 UTC