[whatwg] Media Player Seek Bars: Problems and Suggestions

On Fri, Jan 13, 2012 at 1:58 AM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> - 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.

I'd like either of these!  They'd be useful for lots of things other
than video seeking - knowing what value you're about to switch to is
useful in lots of things that use a range input.


> 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.

I support this, as it's also useful outside of video seeking.
Specifically, I support:

(a) the ability to specify multiple non-contiguous or overlapping
"progress" ranges on a range input
(b) exposing these ranges to CSS for styling

Implementing this by combining <input type=range> and multiple
<progress> elements isn't ideal, because you want the progress ranges
to display above the input's background but below the grabber.  (In
the typical UI pattern, you want them to appear in the track that the
grabber slides in.)

~TJ

Received on Tuesday, 17 January 2012 15:34:37 UTC