Last Comment Bug 344618 - Implement <input type="range">
: Implement <input type="range">
Status: RESOLVED FIXED
: dev-doc-needed, html5, relnote
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 66 votes (vote)
: ---
Assigned To: Jonathan Watt [:jwatt] (back in October - email directly if necessary)
:
Mentors:
http://www.whatwg.org/specs/web-apps/...
: 649963 656496 782165 810234 (view as bug list)
Depends on: 549475 830851 834302 836314 838256 840820 841948 841950 842158 842163 845808 853670 854133 874215
Blocks: html5forms html5test 855149 863633 559764 ringmark-ring1 833742
  Show dependency treegraph
 
Reported: 2006-07-13 17:32 PDT by Alex Vincent [:WeirdAl]
Modified: 2013-11-11 23:59 PST (History)
98 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
23+


Attachments
Early WIP (51.26 KB, patch)
2012-10-01 09:10 PDT, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
More WIP (84.78 KB, patch)
2012-10-15 00:29 PDT, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
Path 1 - Content pieces (10.48 KB, patch)
2013-01-11 23:06 PST, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
Patch 2 - New range frame type (23.90 KB, patch)
2013-01-11 23:07 PST, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
Patch 3 - Mouse/Touch handling (10.92 KB, patch)
2013-01-11 23:08 PST, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
Patch 4 - Native theming for Linux (16.27 KB, patch)
2013-01-11 23:09 PST, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
Patch 5 - Native theming for Windows (12.39 KB, patch)
2013-01-11 23:11 PST, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
Patch 6 - Native Theme OSX (3.47 KB, patch)
2013-01-11 23:12 PST, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review
Patch 7 - Support for theming the active part of the slider on linux (21.19 KB, patch)
2013-01-11 23:13 PST, Wesley Johnston (:wesj)
no flags Details | Diff | Splinter Review

Description Alex Vincent [:WeirdAl] 2006-07-13 17:32:43 PDT
I'm willing to take a shot at implementing <input type="range"> as described in Web Forms 2.0.

Marking dependency on bug 344616 as range currently derives from number.
Comment 1 alexander :surkov 2006-08-17 20:46:43 PDT
(In reply to comment #0)
> I'm willing to take a shot at implementing <input type="range"> as described in
> Web Forms 2.0.
> 
> Marking dependency on bug 344616 as range currently derives from number.
> 

Working draft says:
"Same as number, but indicates that the exact value is not important, letting UAs provide a simpler interface than they do for number. For instance, visual UAs may use a slider control."

Why dependency on bug 344616? Don't you like to have slider control?
Comment 2 alexander :surkov 2006-08-17 20:55:28 PDT
If you like to see input[@type="range"] like slider then xforms probably can be useful. Allan Beaufour implemented xforms:range by html:canvas using. Now I'm trying to pick out html slider widget implementation from xforms:range (bug 348439). That's widget or it's implementation idea can be useful for input[@type="range"].
Comment 3 Paul Rouget [:paul] 2010-06-08 09:20:07 PDT
For what I've been told, it's one of the most asked form element, especially because it brings a really useful control to the web platform.
Comment 4 MrX1980 2010-10-02 17:24:25 PDT
Hello
a new HTML5 Working Draft is out:
Draft Standard — 1 October 2010
http://www.whatwg.org/specs/web-apps/current-work/
http://www.whatwg.org/specs/web-apps/current-work/#range-state

It would be nice to have this in Firefox 4.0 too

Thanks
Comment 5 Boris Zbarsky [:bz] 2010-10-02 18:00:11 PDT
Firefox 4 is in feature freeze.  This is not happening for Firefox 4.
Comment 6 Jim Michaels 2010-10-07 21:56:09 PDT
is there any way we can have this in 3.6.x then?
I would REALLY like to have this.  chrome already displays this control correctly.
but you can't javascript chrome. :-(
Comment 7 Jim Michaels 2010-10-07 22:50:04 PDT
by the way, <input type="range" value="2" min="-5" max="5" step="1">not supported</input> displays as if it were a standard text box, as if it were something like this: 
<input type="text" value="2"></input>

http://www.w3.org/TR/2010/WD-html5-20100624/
specifies that this element has flow content, which if I understand correctly means that it has open and close tags.
in w3schools.org they say in the html training that to future-proof your html, you should always close your tags, as the w3c is moving in that direction..
Comment 8 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-10-07 23:01:38 PDT
<input> never has, and never will have, an end tag. Trying to introduce end tags would break a lot of pages out there, so that won't ever happen.

But yes, <input type="range" value="2" min="-5" max="5" step="1"> will display like <input type=test value=2>.

Unfortunately there is no way that Firefox 3.6 or even Firefox 4 will have support for <input type=range>. Hopefully it will happen in the next major version after FF4 though.
Comment 9 Jim Michaels 2010-10-08 01:28:46 PDT
like it or not, it's happening. it's just which *kind* of tag closing is the w3c implementing on their tags?
at w3schools, they teach that the html5 tag should look like <input />.  In fact, all singleton tags like meta on w3schools are closed with a /.  I am not talking about xhtml or xml.  this is html.  

so I guess I am a little confused between the w3schools' examples (which isn't always right), and my understanding of the meaning of "flow content".  so I don't know for sure whether it's supposed to be open and close tags like I think the specs say (no indicator otherwise in the specs that it's a singleton).
I will get back to you if I find out I was right that the input tag is going to have open and close.

they teach this for html 4 too.  gear up. everything is changing now.  and the validators don't validate right on option tags yet either, so you can't rely on those for perfection.  in html 4 option was a singleton.  in the html 5 spec it's still a singleton.  but the validator treats it like it has open/close.  go figure.
Comment 10 :Ms2ger (⌚ UTC+1/+2) 2010-10-08 02:23:01 PDT
(In reply to comment #9)
> like it or not, it's happening. it's just which *kind* of tag closing is the
> w3c implementing on their tags?
> at w3schools, they teach that the html5 tag should look like <input />.  In
> fact, all singleton tags like meta on w3schools are closed with a /.  I am not
> talking about xhtml or xml.  this is html.  

First, never ever trust W3Schools. Second, |<input />| is allowed in HTML and means exactly the same as |<input>|. |<input></input>| is not, and will never be, allowed in HTML. In XHTML, the XML rules are followed, so |<input>| is forbidden and |<input />| and |<input></input>| are equivalent. However, even in XHTML, |<input>Text</input>| is invalid.

> so I guess I am a little confused between the w3schools' examples (which isn't
> always right), and my understanding of the meaning of "flow content".

If we look at <http://www.whatwg.org/html/#the-input-element>, we see that the content mode is "empty". This means input must not have children: 
<http://www.whatwg.org/html/#element-definitions>

> so I
> don't know for sure whether it's supposed to be open and close tags like I
> think the specs say (no indicator otherwise in the specs that it's a
> singleton).

The definition of the HTML syntax (<http://www.whatwg.org/html/#elements-0>) is clear: input is a "void" element, and "end tags must not be specified for void elements".

> I will get back to you if I find out I was right that the input tag is going to
> have open and close.

You aren't.

> they teach this for html 4 too.  gear up. everything is changing now.  and the
> validators don't validate right on option tags yet either, so you can't rely on
> those for perfection.  in html 4 option was a singleton.  in the html 5 spec
> it's still a singleton.  but the validator treats it like it has open/close. 
> go figure.

Not sure what you're saying here.

I hope this clears up some confusion.

However, on the topic of this bug, no new features will be implemented for 3.6, as it has already been released, nor for 4.0, as we are in feature freeze. We want input type=range to be implemented, and to be implemented *well*. There's a good chance it will be implemented in Firefox.next, but no promises. Patches are always welcome in this bug; discussions about how unfortunate it is that we didn't get it ready in time for 4.0, not so much, that's what forums and newsgroups are for.
Comment 11 Boris Zbarsky [:bz] 2010-10-08 05:26:40 PDT
> has flow content, which if I understand correctly means that it has open and
> close tags.

You understand incorrectly.  "flow content" is just a category of tags, and the category is used for determining which parents the tag is allowed under; it has nothing to do with the kids of the tag.
Comment 12 Patrick Reiter Horn 2011-01-10 04:10:21 PST
I found a nice MIT-licensed implementation here:
https://github.com/fryn/html5slider
Uses -moz-appearance to apply a style to an extra hr element.

That script hooks into DOMContentLoaded, so it seems to me like that this could serve as a starting point for an extension at least.
Comment 14 Frank Yan (:fryn) 2011-04-12 21:13:39 PDT
Alex, are you still working on this? If I don't get a response by the weekend, I'm going to take this bug and start at least investigating it.

(In reply to comment #12)
> I found a nice MIT-licensed implementation here:
> https://github.com/fryn/html5slider
> Uses -moz-appearance to apply a style to an extra hr element.
> 
> That script hooks into DOMContentLoaded, so it seems to me like that this could
> serve as a starting point for an extension at least.

I wrote that. :)
Comment 15 Alex Vincent [:WeirdAl] 2011-04-12 21:18:43 PDT
Take it.  I'm busy doing other things.  :)
Comment 16 Robert Longson 2011-04-14 05:08:14 PDT
*** Bug 649963 has been marked as a duplicate of this bug. ***
Comment 17 Alexei 2011-04-15 18:51:36 PDT
http://userscripts.org/scripts/show/101214 - user script for insert html5slider.js (required Greasemonkey)
Comment 18 Kevin Brosnan [:kbrosnan] 2011-05-11 16:48:28 PDT
*** Bug 656496 has been marked as a duplicate of this bug. ***
Comment 19 sfornengo 2011-07-31 03:58:56 PDT
what about render html5 input type=range as a slider ?
it seems nobody works on it although firefox is far behind the other browsers on smart rendering of html5 inputs.
Comment 20 Boris Zbarsky [:bz] 2011-07-31 07:31:51 PDT
> although firefox is far behind the other browsers on smart rendering of html5
> inputs

Yeah, we've focused on actually making them behave correctly instead for now, something other browsers decided to skip on.  Matter of priorities, I suppose.
Comment 21 sfornengo 2011-07-31 12:01:38 PDT
> Yeah, we've focused on actually making them behave correctly instead for now, > something other browsers decided to skip on.  Matter of priorities, I suppose.

I understand this point of view... I just notice that even simple html5 tutorials are poorly rendered under firefox (eg http://webhole.net/2010/04/24/html-5-slider-input-tutorial/), so early html5 adopters are redirected to others browsers.
I love firefox but testing the future (beta, aurora, nightly), seeing slider always not working and seeing nobody works on it make me sad...
Comment 22 juliodetolosa 2011-11-17 06:27:20 PST
Any news on this ?
Comment 23 jb 2012-04-10 04:40:25 PDT
Hi Mozilla, has there been any updates on the native slider for range inputs? Thanks, James
Comment 24 :Ms2ger (⌚ UTC+1/+2) 2012-04-10 04:42:36 PDT
Hi James, if there had been, you would have been able to find it in this bug.
Thanks, Mozilla
Comment 25 peter@theta-g.com 2012-05-08 01:24:39 PDT
Keeping an eye on this. I've just been brought onto a site whose jQuery sliders don't work at all in iOS. What would you do?
Comment 26 Tom Chiverton 2012-08-09 06:07:43 PDT
Why isn't Mozilla seeing implementing this as a (higher) priority ?
Given http://caniuse.com/input-range suggests it's only FireFox and Opera Mini left who don't support it (even *IE* will have it next version) ?
Comment 27 David Bruant 2012-08-09 06:36:34 PDT
(In reply to Tom Chiv from comment #26)
> Why isn't Mozilla seeing implementing this as a (higher) priority ?
> Given http://caniuse.com/input-range suggests it's only FireFox and Opera
> Mini left who don't support it (even *IE* will have it next version) ?
From what I know, Mozilla is currently focusing on Firefox OS, including the WebAPIs (bug 673923). That and other things.
On the DOM side, there is a major refactoring of the DOM based on WebIDL (bug 580070) going on. This will yield better conformance and I'm confident DOM performance, likely security too I would guess.
Meanwhile, I agree, no new feature (like this bug) is being worked on. That's unfortunate, but it's a matter of priority.

This bug isn't the right place to discuss Mozilla priorities, but while I say that, I don't know what is the right channel to have discussions about that.
Does someone else know?
Comment 28 Boris Zbarsky [:bz] 2012-08-09 10:20:46 PDT
The right channel for priority discussions is probably dev-platform or dev-planning.

And you're wrong about no new features being worked on, even outside of webapi.
Comment 29 David Bruant 2012-08-09 10:25:52 PDT
(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #28)
> The right channel for priority discussions is probably dev-platform or
> dev-planning.
Links to find these mailing-lists:
https://lists.mozilla.org/listinfo/dev-planning
https://lists.mozilla.org/listinfo/dev-platform

> And you're wrong about no new features being worked on, even outside of webapi.
True, sorry about this misinformation; I don't know what I was thinking when I wrote "no new features". The "Firefox X for developers" pages list new and fixed features as in: https://developer.mozilla.org/en-US/docs/Firefox_15_for_developers . My point was that while people work on other things, they don't work on HTML5 forms for instance.
Comment 30 Makoto Kato [:m_kato] 2012-08-12 23:38:56 PDT
*** Bug 782165 has been marked as a duplicate of this bug. ***
Comment 31 Wesley Johnston (:wesj) 2012-10-01 09:10:12 PDT
Created attachment 666577 [details] [diff] [review]
Early WIP

This is a very early WIP. Works for a horizontal range (on Linux at least). Its a mashup of the progressFrame and sliderFrame as I learned my way through this.  Beginnings of mouse support. I figure keyboard support should be implemented in nsHTMLInputElement for number fields, so I didn't try and steal that from nsSliderFrame. Needs more love to get the basic theming right + vertical support, but working on this in my spare time and wanted to put it up as a base in case I don't have time to get back to it (and in case mounir had comments).
Comment 32 Mounir Lamouri (:mounir) 2012-10-04 02:38:31 PDT
Wesley, I think the best approach would be to begin with a patch implementing the element for the content. Which means you can create it and interact with it the way HTML specs explain it but without any UI.
After that, you can begin the layout work, without any widget work.
Finally, you can implement the widget for each platforms.

I think that way, the work will be incremental and each part will be done as best as possible and separately. I can even implement the content part if you want ;)
Comment 33 Wesley Johnston (:wesj) 2012-10-15 00:29:29 PDT
Created attachment 671334 [details] [diff] [review]
More WIP

Getting closer. This works fairly well on Linux. Doesn't support keyboard input (but we also need those for input[type="number"]?) Put some code in for native theming on non-GTK, but haven't tested any of it yet.

I added a moz-appearance: range/range-thumb type to handle switching between horizontal and vertical based on the element's size, and range-active to do some extra theming on Linux. I started playing with also adding tick marks and datalist support and realized that I'm not exactly sure how much we need for "basic" support here. Can you give me any feedback about that (and any other comments) mounir?

I'm going to get my windows machine up and test there a bit. OSX might be a bit harder for me.... Need to also test things like disabled states and what happens when native themes are overridden.
Comment 34 Mounir Lamouri (:mounir) 2012-10-24 08:20:41 PDT
Comment on attachment 671334 [details] [diff] [review]
More WIP

Wes, I think this patch is way too big now to do proper feedback. It looks generally good but you should probably split in different parts and ask for reviews.
Comment 35 Frank Yan (:fryn) 2012-10-24 15:10:14 PDT
I really appreciate you picking this up! :)

(In reply to Wesley Johnston (:wesj) from comment #33)
> Created attachment 671334 [details] [diff] [review]
> More WIP

In case you didn't catch this already, this doesn't build for me on OS X. I get the following errors:

/Users/frank/mozilla/widget/cocoa/nsNativeThemeCocoa.mm:2241:10: error: use of
      undeclared identifier 'NS_RANGE'
    case NS_RANGE:
         ^
Did you mean NS_THEME_RANGE?

/Users/frank/mozilla/widget/cocoa/nsNativeThemeCocoa.mm:2250:18: error: use of
      undeclared identifier 'nsIDOMHTMLInputElement'; did you mean
      'nsIDOMHTMLMenuElement'?
        nsCOMPtr<nsIDOMHTMLInputElement> inputElt = do_QueryInterface(content);
                 ^

#include "nsIDOMHTMLInputElement.h" ?
Comment 36 Robert Longson 2012-11-09 02:05:22 PST
*** Bug 810234 has been marked as a duplicate of this bug. ***
Comment 37 sfornengo 2012-12-04 02:05:39 PST
a date or version to see this feature finally arrive ? nothing new since my last visit 18 months ago and we always have to use polyfills to fill the gaps of firefox...
I am sad to see that firefox is the lame duck in the adoption of html5 forms...
Comment 38 vulcain 2012-12-04 02:26:15 PST
http://html5test.com/compare/feature/form-range-element.html
http://caniuse.com/#feat=input-range
say that IE 10, Safari 5.0, Opera 10, Chrome 6 could use input=range.
Comment 39 Wesley Johnston (:wesj) 2013-01-11 23:06:53 PST
Created attachment 701418 [details] [diff] [review]
Path 1 - Content pieces

Been way to busy to work on this. Updating these to hand this off.
Comment 40 Wesley Johnston (:wesj) 2013-01-11 23:07:41 PST
Created attachment 701419 [details] [diff] [review]
Patch 2 - New range frame type
Comment 41 Wesley Johnston (:wesj) 2013-01-11 23:08:20 PST
Created attachment 701420 [details] [diff] [review]
Patch 3 - Mouse/Touch handling
Comment 42 Wesley Johnston (:wesj) 2013-01-11 23:09:41 PST
Created attachment 701421 [details] [diff] [review]
Patch 4 - Native theming for Linux
Comment 43 Wesley Johnston (:wesj) 2013-01-11 23:11:58 PST
Created attachment 701423 [details] [diff] [review]
Patch 5 - Native theming for Windows
Comment 44 Wesley Johnston (:wesj) 2013-01-11 23:12:40 PST
Created attachment 701424 [details] [diff] [review]
Patch 6 - Native Theme OSX
Comment 45 Wesley Johnston (:wesj) 2013-01-11 23:13:49 PST
Created attachment 701425 [details] [diff] [review]
Patch 7 - Support for theming the active part of the slider on linux
Comment 46 Markus Popp 2013-03-21 13:33:50 PDT
I just played with <input type="range"> and found differences on how the onchange event is handled across browsers.

While IE10, Chrome and Opera trigger onchange events while the slider is dragged, Firefox only triggers an onchange event when dropping the slider to its new position. Which makes the onchange event rather unusable if the user should see the effect of moving the slider immediately.

It appears as the oninput event comes to the rescue, with that it works fine in Firefox, Opera and Chrome ... but unfortunately IE10 doesn't recognize it at all.

So to have a smooth implementation that works in Firefox, Chrome, Opera and IE10 it requires a mix of both onchange and oninput, which is not ideal of course.

Anything planned to fix this?
Comment 47 Wesley Johnston (:wesj) 2013-03-21 15:12:02 PDT
Probably best to file a separate bug, but based on the current HTML5 spec, I would say our behavior is right here and other browsers are wrong. That's not to say we can't fix the spec.

http://www.w3.org/html/wg/drafts/html/master/forms.html#event-input-input

"When the input event applies, any time the user causes the element's value to change, the user agent must queue a task to fire a simple event that bubbles named input at the input element."

"When the change event applies, if the element does not have an activation behavior defined but uses a user interface that involves an explicit commit action, then any time the user commits a change to the element's value or list of selected files, the user agent must queue a task to fire a simple event that bubbles named change at the input element."
Comment 48 Markus Popp 2013-03-21 16:10:49 PDT
Filed bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=853670
Comment 49 Markus Popp 2013-03-23 13:17:56 PDT
Reminder: while dom.experimental_forms_range is available in Aurora (21.0a2) and renders the range input element if enabled, it doesn't do anything (slider can't be moved). I guess that some patches still require an uplift.
Comment 50 Mounir Lamouri (:mounir) 2013-03-25 06:22:26 PDT
(In reply to Markus Popp from comment #49)
> Reminder: while dom.experimental_forms_range is available in Aurora (21.0a2)
> and renders the range input element if enabled, it doesn't do anything
> (slider can't be moved). I guess that some patches still require an uplift.

Markus, the feature is intended to work only on Nightly for the moment, this is why the flag is disabled by default on the current Aurora build. I do not think there is any need to uplift patches given that we do not intend to make this enabled by default on Beta and Release for the moment.

The next Aurora release will have the feature enabled by default as a sign of it being ready to be tested there.
Comment 51 alexander :surkov 2013-04-18 19:52:47 PDT
oninput event is fired whenever thumb is clicked (no value change). Is it known issue? Should I file a bug on this?
Comment 52 alexander :surkov 2013-04-18 20:00:06 PDT
another issue: input.value = "4" doesn't change a slider position (let me know if you need a bug for this too)
Comment 53 Mounir Lamouri (:mounir) 2013-04-19 01:49:13 PDT
Alexander, you should open bugs on those issues. Worse case, they will be marked as WFM.
Comment 54 alexander :surkov 2013-04-19 02:01:34 PDT
done bug 863633 and bug 863634
Comment 55 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2013-05-06 12:19:01 PDT
All done here and good to release. Baring any unforeseen blocking issues, <input type=range> will ship in Firefox 23.

Any further improvements or requests for changes should be filed as new bugs that are marked as blocking bug 853822, please.
Comment 56 Lukas Blakk [:lsblakk] use ?needinfo 2013-05-21 11:12:11 PDT
This has been noted in the Aurora 23 release notes:

http://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/

If you would like to make any changes or have questions/concerns please contact me directly.

Note You need to log in before you can comment on or make changes to this bug.