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

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

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |WONTFIX

--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-08-09 23:42:16 UTC ---
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.

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

Received on Tuesday, 9 August 2011 23:42:18 UTC