Implement <input type="range">

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
11 years ago
2 months ago

People

(Reporter: WeirdAl, Assigned: jwatt)

Tracking

(Blocks: 4 bugs, {dev-doc-complete, html5, relnote})

Trunk
dev-doc-complete, html5, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 23+)

Details

(URL)

Attachments

(9 obsolete attachments)

(Reporter)

Description

11 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.
(Reporter)

Updated

11 years ago
Assignee: general → ajvincent

Updated

11 years ago
No longer blocks: 344616
Depends on: 344616

Comment 1

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

Comment 2

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

Updated

9 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general

Updated

7 years ago
Blocks: 559764

Updated

7 years ago
Blocks: 566348
Keywords: html5
OS: Windows XP → All
Hardware: x86 → All

Comment 3

7 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.
Depends on: 549475
Keywords: dev-doc-needed
No longer blocks: 566348

Comment 4

7 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
Firefox 4 is in feature freeze.  This is not happening for Firefox 4.

Comment 6

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

Comment 7

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

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

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

Comment 13

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

Comment 14

6 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. :)
(Reporter)

Comment 15

6 years ago
Take it.  I'm busy doing other things.  :)
Assignee: ajvincent → fryn

Updated

6 years ago
Duplicate of this bug: 649963

Comment 17

6 years ago
http://userscripts.org/scripts/show/101214 - user script for insert html5slider.js (required Greasemonkey)
Duplicate of this bug: 656496

Updated

6 years ago
Assignee: fryn → nobody

Comment 19

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

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

Comment 22

6 years ago
Any news on this ?

Comment 23

5 years ago
Hi Mozilla, has there been any updates on the native slider for range inputs? Thanks, James
Hi James, if there had been, you would have been able to find it in this bug.
Thanks, Mozilla

Comment 25

5 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?
Blocks: 748250
No longer depends on: 344616

Comment 26

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

Comment 27

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

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

Updated

5 years ago
Duplicate of this bug: 782165
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).
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 ;)
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.
Attachment #666577 - Attachment is obsolete: true
Attachment #671334 - Flags: feedback?(mounir)
Blocks: 802882
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.
Attachment #671334 - Flags: feedback?(mounir)

Comment 35

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

Updated

5 years ago
Duplicate of this bug: 810234

Comment 37

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

Comment 38

5 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.
(Assignee)

Updated

5 years ago
Created attachment 701418 [details] [diff] [review]
Path 1 - Content pieces

Been way to busy to work on this. Updating these to hand this off.
Attachment #671334 - Attachment is obsolete: true
Created attachment 701419 [details] [diff] [review]
Patch 2 - New range frame type
Created attachment 701420 [details] [diff] [review]
Patch 3 - Mouse/Touch handling
Created attachment 701421 [details] [diff] [review]
Patch 4 - Native theming for Linux
Created attachment 701423 [details] [diff] [review]
Patch 5 - Native theming for Windows
Created attachment 701424 [details] [diff] [review]
Patch 6 - Native Theme OSX
Created attachment 701425 [details] [diff] [review]
Patch 7 - Support for theming the active part of the slider on linux
Attachment #701425 - Attachment is patch: true
(Assignee)

Updated

5 years ago
Assignee: nobody → jwatt
(Assignee)

Updated

5 years ago
Depends on: 830851
(Assignee)

Updated

5 years ago
Blocks: 833742
(Assignee)

Updated

5 years ago
Depends on: 834302
(Assignee)

Updated

5 years ago
Depends on: 836314
(Assignee)

Updated

4 years ago
Depends on: 838256
(Assignee)

Updated

4 years ago
Depends on: 840820
(Assignee)

Updated

4 years ago
Blocks: 841948
No longer blocks: 841948
Depends on: 841948
Depends on: 841942, 841946, 841950
Depends on: 842021
Depends on: 842158
Depends on: 842163
Depends on: 845808

Comment 46

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

4 years ago
Filed bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=853670
Depends on: 853670

Updated

4 years ago
No longer depends on: 853670

Updated

4 years ago
Depends on: 853670
(Assignee)

Updated

4 years ago
Attachment #701418 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #701419 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #701420 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #701421 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #701423 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #701424 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #701425 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Depends on: 854133

Comment 49

4 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.
(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.
Blocks: 855149
(Assignee)

Updated

4 years ago
No longer depends on: 842021
(Assignee)

Updated

4 years ago
No longer depends on: 841942
(Assignee)

Updated

4 years ago
No longer depends on: 841946

Comment 51

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

Comment 52

4 years ago
another issue: input.value = "4" doesn't change a slider position (let me know if you need a bug for this too)
Alexander, you should open bugs on those issues. Worse case, they will be marked as WFM.

Updated

4 years ago
Blocks: 863633

Updated

4 years ago
Blocks: 863634

Comment 54

4 years ago
done bug 863633 and bug 863634
(Assignee)

Updated

4 years ago
No longer blocks: 863634
(Assignee)

Comment 55

4 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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Keywords: relnote
Resolution: --- → FIXED
relnote-firefox: --- → 23+

Updated

4 years ago
Depends on: 874215
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.
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.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.