855149 - Make <input type=range> usable for media controls

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement)

Description

[Justin Dolske [:Dolske]]

Attachment: Screenshot of current video controls

I'd like to eventually switch Firefox's default video/audio controls to fully using HTML, instead of XUL. One part of this would be eliminating the current <xul:scale> (used for selecting the playback position), probably to a <input type=range>. This isn't currently possible because <input> isn't flexible enough. Maybe it never will be, but it seems like there's a lot of overlap and these things would generally be useful.

A few of the things I've found so far:

1) Putting a text label (showing the current time offset) in the thumb.

CSS could almost handle this:

  <input type=range currentTime="0:38">
  ::-moz-range-thumb::after {
    content: attr(currentTime);
  }

Except the CSS spec says you can only use 1 pseudoelement in a selector (but does add "Note: A future version of this specification may allow multiple pseudo-elements per selector.").


2) Allow vertical offsetting of ::-moz-range-thumb

Our video controls have a a pointy thumb that should just touch the top of the track. But -moz-range-thumb seems to force centering the thumb on the track. I can push it up, but my hacks either cause extra padding underneath the track or cause the image to be clipped at the top. (Notice in the screenshot how the thumb extends above the control bar)

    input::-moz-range-thumb {
      background: url(chrome://global/skin/media/scrubberThumb.png) top no-repeat;
      width: 33px;
      height: 28px;
    }


3) Allow ::-moz-range-thumb to overhang track

Note how the video control thumb is fairly wide. When the thumb is at the far left or right of the track, half of it should overlap. EG:

   _______                     _______
  (_00:01_)                   (_02:59_)
      v                           v
      =============================

(Alternatively allow using padding-left + padding-right on ::-moz-range-track without changing where the thumb is drawn? That seems more confusing, though.)


4) Separate styling of the track before/after the thumb.

To make the playback position even more obvious, we style the track differently to the left and to the right of the thumb. The screenshot shows this as a subtle effect; YouTube uses a bright red track to the left of the thumb. It would be nice to have ::-moz-range-track-beginning and ::-moz-range-track-end inherit style from a parent ::-moz-range-track, too?


[Additionally, the video controls current do some ugly hacks to suppress events fired by <xul:scale>, lest content see them and start relying on them. I think that's out-of-scope here, and maybe something WebComponents should deal with instead.]

Comment 1

[Mounir Lamouri (:mounir)]

(In reply to Justin Dolske [:Dolske] from comment #0)
> 4) Separate styling of the track before/after the thumb.

Would bug 854538 be enough?

Comment 2

[Jonathan Watt [:jwatt]]

Great feedback, thanks, dolske.

Comment 3

[Justin Dolske [:Dolske]]

(In reply to Mounir Lamouri (:mounir) from comment #1)

> > 4) Separate styling of the track before/after the thumb.
> 
> Would bug 854538 be enough?

I believe so! Awesome! :)

Comment 4

[:Gijs (he/him)]

Jonathan, what's required for (1) here? Can we implement that sanely without breaking the spec? Perhaps with a separate thing in the thumb that's display: none unless otherwise specified or something? Although I suppose we can only use content: () for pseudo frames... so getting content in it would be a little tricky (still possible now that we can navigate native anon content from JS, but even so).

Comment 5

[Jonathan Watt [:jwatt]]

I think we'd need another pseudo-element that is display:none, as you suggest. I expect we'd go through several iterations trying to decide on the layout mechanism that meets our needs under various styling scenarios though. I'd really prefer the new element not to be a child of the thumb because that complicates the frame construction, but it may be very trick to get things to lay out correctly if it's not. CC'ing dholbert in case he has any flexbox magic to suggest.

Comment 6

[Florian Bender]

Is there any plan to tackle in the near future?

Comment 7

[Ray Lin[:ralin]]

Hi, I'm interested in video control de-xul, but it seems hasn't been updated for a while.

I got a prototype here(http://people.mozilla.org/~ralin/video/), hope to be the first iteration for mechanism choosing.
I didn't try to make the whole UI look like xul version. Instead, it's a kind of demo shows how current spec could or couldn't achieve now.

Some missing but could be overcome parts:
1. flexible input width -> initiate process as long as video size changed
2. replace black rectangle with thumb icon -> background img + box model adjustment
3. convert range to time format -> some js works

Could you give me a feedback, any suggestion is welcome, thanks.

Comment 8

[:Gijs (he/him)]

I think if we accept having to use JS etc. and several elements where currently 1 will do, this is implementable in HTML. It's just a lot more work than if the HTML input types supported the same level of flexibility as the XUL ones. Nobody has stepped up to do the work of rewriting this to use manually (ie via JS) bound extra elements, and I'm sure in practice that would come with its own complications. I'm also not sure it's worth doing separately from rearchitecting the videocontrols to not use XBL either (and use web components instead - but they're not ready yet). It would be sad if we had to rearchitect the whole thing twice.

Comment 9

[Ray Lin[:ralin]]

Yep, also Bug 1271765 has a ongoing plan to change design... I agree things should be settled in the order that cost less duplicate efforts. Thanks for your feedback.

Comment 10

[Justin Dolske [:Dolske]]

I think incremental change is best -- HTML+XBL is a good step towards HTML w/o XBL.  And I suspect that getting rid of XUL is the worst part of it... We're not really doing anything complex with the XBL, it's just a handy tool for gluing together some JS and XUL/HTML. It's not like we're further locking ourselves into XBL. [Ok, technically we're doing some clever stuff with XBL to implement the time thumb, but that's what we're trying to get rid of with this bug anyway.]

There's no _requirement_ to use pure <input type=range>, I think we were just hopeful that it would be easy to have it be a drop-in replacement for <xul:scale>. The extra JS is fine.

That said... I am more worried now than I was originally about the last part of comment 0:

 [Additionally, the video controls current do some ugly hacks to suppress events fired by <xul:scale>, lest content see them and start relying on them. I think that's out-of-scope here, and maybe something WebComponents should deal with instead.]

The problem here is that if events from our UI leak outside of the XBL, they're exposed to the web and it becomes a compatibility problem (if web pages start relying on those events, they won't work in other browsers and can break when we change our UI code). In short, a page shouldn't be able to add an "input" event listener to a <video> tag and see the events from the <input type=range> within it. I'm... not sure of how to fix this. Maybe we need a hacky DOM fix to do so? Bug 1274520 added the ability to listen to special system group events, maybe we need a corresponding way to make the <input> only emit events to the system group? I really don't know.

(Also: awesome that you're looking at this!)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Other option is to add a flag which propagates events only in native anonymous content and then to chrome.  Almost like scoped in Shadow DOM. The question is which events need this behavior?

Comment 12

[:Gijs (he/him)]

(In reply to Olli Pettay [:smaug] from comment #11)
> Other option is to add a flag which propagates events only in native
> anonymous content and then to chrome.  Almost like scoped in Shadow DOM. The
> question is which events need this behavior?

Could we just do it for *all* events that target anything in the <videocontrols>, rather than the <video> itself? So clicks on buttons don't "show" 'click' events to outside consumers, but clicks on the <video> itself do?

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

No. mousemove, drag, touchmove, pointermove etc. need to propagate.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

But perhaps it would be easier to whitelist the events which don't need special handling.

And click is targeted already to the first non-native-anonyumous element - targeting isn't the issue here, it is whether event should propagate at all to the non-native-anonymous content.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Is there anything else needed to be worked on in this bug? HTML video controls from bug 1271765 have since shipped; bug 1327097 was fixed to deal with event propagation.

Please reopen if I don't understand this bug correctly.

Comment 16

[:Gijs (he/him)]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #15)
> Is there anything else needed to be worked on in this bug? HTML video
> controls from bug 1271765 have since shipped; bug 1327097 was fixed to deal
> with event propagation.
> 
> Please reopen if I don't understand this bug correctly.

The suppressChangeEvent binding is still used by the volume control and scrubber, and extends `<scale>`, which uses a XUL slider, so I don't think that's using HTML?

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It will go away in bug 1444489. You are right, I should keep this open until that bug lands.