- From: Hugh Guiney <hugh.guiney@gmail.com>
- Date: Fri, 13 Jan 2012 04:58:39 -0500
I'm currently creating a custom HTML video player UI. What I'm trying to achieve is a seek bar control?a horizontal slider that allows the user to seek to a specific point in time. Right now the basic functionality of this can be achieved using a range input with a max value set to the video's duration, and which sets the video's currentTime onchange. However, there are two problems with this: The first is that I'd like to be able to show the user, before selecting a point in the range, what point they are about to seek to. At present, even if there is an element that exposes currentTime to the user, there's no way to show them what currentTime *will* be until they actually select a point on the range. Although I realize range inputs are meant to be imprecise, it's often helpful to be able to see more precise values one at a time, so that if there is a value they're aiming for, they can find it or get close enough with less trial and error than blind selection. It has become a ubiquitous UI convention on the Web to provide time code and/or frame previews in a tooltip as the user scans the seek bar (but before seeking). This can be seen for example on YouTube, Vimeo, Hulu, blip.tv, Brightcove, Firefox, and many JS library players. And although the effect is most common in video players, it would be helpful in audio players, or any other situation where a user wants to browse available options within a range without committing to any right away and triggering an unwanted action. One solution would be to introduce some DOM interfaces, for instance: - A "preChange" event that fires while a range input is hovered over, as the coordinate of a pointing device is advanced in either direction along the input's axis. - A readonly attribute "preValue" that holds the value that corresponds to the input's currently pointed-to coordinate. That way, an author could write a script that modifies a range input's title attribute, etc., with the prospective time. The second problem is that at present, range inputs are not quite sufficient semantically for marking up seek bars. Seek bars typically display not only a thumb, but also a progress bar that displays what percentage of the video is loaded. Obviously, we have <progress> for this, and so theoretically one could use both a range input and a progress bar together, this falls short for a few reasons: - They are separate elements when seeking UI is almost universally represented as a single control. Although it's possible to position a range input on top of a progress bar using CSS, for users with CSS off, it takes up twice as much space as it needs to. - Seek bars typically have 3 distinct progress indicators: not buffered (transparent/no color), buffered (translucent color), and buffered + played (opaque color). Currently, progress bars can only display 2 styles: translucent and opaque. - When seeking to points that have not yet been buffered, some seek bars will leave the unbuffered portions translucent, starting the played + buffered color not from the minimum value point but from wherever the user seeks to. Advancements in CSS would not address this as there's only min, value, and max to work with; there's no way to specify [a] concurrent value(s) to represent the discontinuous progression. Possible solutions would be to address these shortcomings in <progress> and then somehow specify that a range input and a progress bar are connected and should be rendered as a single UI in supporting UAs and separately as fallback; or, more simply: introduce <input type="seek"> explicitly for controlling media elements. Thoughts welcome! -Hugh
Received on Friday, 13 January 2012 01:58:39 UTC