|
|
|
|
|
|
by Chris_Newton
3779 days ago
|
|
|
In theory, yes, that’s how you’re supposed to do it. Unfortunately, part of the real world problem with switching to HTML5 media elements is that browsers have an awful track record in terms of quality of implementation. At various points, even quite basic events simply haven’t been firing properly in one browser or another. And with browsers updating every six weeks and frequently changing things like the default controls you get on a video element, you’re constantly aiming at unnecessarily moving targets as a developer. |
|
|
- Does the pause event fire?
- Does the seeking event fire? Or does it only fire when you move the mouse to drag the thumb to a new time?
- Does the seekend event fire? Does it fire every time you move the thumb to a new position without releasing the mouse button? Or does it only fire when you release the mouse button?
- Does the timeupdate event fire? Does it fire once? Or repeatedly for the same position where the thumb is?
Every browser has different answers.
As for the timeupdate event, it only fires once every 250ms, which is painfully slow for applications that need to synchronize something with the video (slides, subtitles, etc.)
And even if you decided to ignore all the events and write a requestAnimationFrame-powered loop to query only the changes in the currentTime property, there's a bug in Chrome on Android where the video.currentTime property becomes out-of-sync with the video if any long-running JS or complicated animation blocks the event loop for a few seconds - https://code.google.com/p/chromium/issues/detail?id=509010