Alex Vincent [:WeirdAl] Reporter
	Description • 18 years ago

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.

	alexander :surkov (:asurkov)
	Comment 1 • 18 years ago

(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?

	alexander :surkov (:asurkov)
	Comment 2 • 18 years ago

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

	Paul Rouget [:paul]
	Comment 3 • 14 years ago

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.

	MrX1980
	Comment 4 • 14 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 14 years ago

Firefox 4 is in feature freeze.  This is not happening for Firefox 4.

	Jim Michaels
	Comment 6 • 14 years ago

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

	Jim Michaels
	Comment 7 • 14 years ago

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

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 8 • 14 years ago

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

	Jim Michaels
	Comment 9 • 14 years ago

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.

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 10 • 14 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 14 years ago

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

	Patrick Reiter Horn
	Comment 12 • 14 years ago

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.

	MrX1980
	Comment 13 • 13 years ago

A new draft (5 February 2011)
http://dev.w3.org/html5/spec/Overview.html#range-state
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#range-state


example:
http://slides.html5rocks.com/#rounded-corners
(for this example the sliders would be very helpful)

	Frank Yan (:fryn)
	Comment 14 • 13 years ago

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

	Alex Vincent [:WeirdAl] Reporter
	Comment 15 • 13 years ago

Take it.  I'm busy doing other things.  :)

	Alexei
	Comment 17 • 13 years ago

http://userscripts.org/scripts/show/101214 - user script for insert html5slider.js (required Greasemonkey)

	sfornengo
	Comment 19 • 13 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 20 • 13 years ago

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

	sfornengo
	Comment 21 • 13 years ago

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

	juliodetolosa
	Comment 22 • 13 years ago

Any news on this ?

	jb
	Comment 23 • 12 years ago

Hi Mozilla, has there been any updates on the native slider for range inputs? Thanks, James

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 24 • 12 years ago

Hi James, if there had been, you would have been able to find it in this bug.
Thanks, Mozilla

	peter@theta-g.com
	Comment 25 • 12 years ago

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?

	Tom Chiverton
	Comment 26 • 12 years ago

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) ?

	David Bruant
	Comment 27 • 12 years ago

(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?

	Boris Zbarsky [:bzbarsky]
	Comment 28 • 12 years ago

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.

	David Bruant
	Comment 29 • 12 years ago

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

	Wesley Johnston (:wesj)
	Comment 31 • 12 years ago

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

	Mounir Lamouri (:mounir)
	Comment 32 • 12 years ago

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 ;)

	Wesley Johnston (:wesj)
	Comment 33 • 12 years ago

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.

	Mounir Lamouri (:mounir)
	Comment 34 • 12 years ago

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.

	Frank Yan (:fryn)
	Comment 35 • 12 years ago

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" ?

	sfornengo
	Comment 37 • 12 years ago

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

	vulcain
	Comment 38 • 12 years ago

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.

	Wesley Johnston (:wesj)
	Comment 39 • 11 years ago

Been way to busy to work on this. Updating these to hand this off.

	Markus Popp
	Comment 46 • 11 years ago

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?

	Wesley Johnston (:wesj)
	Comment 47 • 11 years ago

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

	Markus Popp
	Comment 48 • 11 years ago

Filed bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=853670

	Markus Popp
	Comment 49 • 11 years ago

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.

	Mounir Lamouri (:mounir)
	Comment 50 • 11 years ago

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

	alexander :surkov (:asurkov)
	Comment 51 • 11 years ago

oninput event is fired whenever thumb is clicked (no value change). Is it known issue? Should I file a bug on this?

	alexander :surkov (:asurkov)
	Comment 52 • 11 years ago

another issue: input.value = "4" doesn't change a slider position (let me know if you need a bug for this too)

	Mounir Lamouri (:mounir)
	Comment 53 • 11 years ago

Alexander, you should open bugs on those issues. Worse case, they will be marked as WFM.

	alexander :surkov (:asurkov)
	Comment 54 • 11 years ago

done bug 863633 and bug 863634

	Jonathan Watt [:jwatt] Assignee
	Comment 55 • 11 years ago

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.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 56 • 11 years ago

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.

	Eric Shepherd [:sheppy]
	Comment 57 • 7 years ago

This has now been documented, at long last:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range

The mention on https://developer.mozilla.org/en-US/Firefox/Releases/23 has been updated to link to the above page.

And of course the information on the main <input> page has been updated as well.