[whatwg] Media Player Seek Bars: Problems and Suggestions

[Hugh Guiney]

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