344618 - Implement <input type="range">

Status: RESOLVED FIXED

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

Description

[Alex Vincent [:WeirdAl]]

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 (:asurkov)]

(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 (:asurkov)]

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

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]

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 [:bzbarsky]]

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

Comment 6

[Jim Michaels]

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]

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]

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

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 (he/him; ⌚ UTC+1/+2)]

(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 [:bzbarsky]]

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

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

[MrX1980]

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

[Frank Yan (:fryn)]

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

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

Comment 17

[Alexei]

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

Comment 19

[sfornengo]

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 [:bzbarsky]]

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

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

Any news on this ?

Comment 23

[jb]

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

Comment 24

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

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

Comment 25

[[e-mail]]

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]

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]

(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 [:bzbarsky]]

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]

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

[Wesley Johnston (:wesj)]

Attachment: 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)]

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

Attachment: 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)]

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

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 37

[sfornengo]

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]

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

Attachment: Path 1 - Content pieces

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

Comment 40

[Wesley Johnston (:wesj)]

Attachment: Patch 2 - New range frame type

Comment 41

[Wesley Johnston (:wesj)]

Attachment: Patch 3 - Mouse/Touch handling

Comment 42

[Wesley Johnston (:wesj)]

Attachment: Patch 4 - Native theming for Linux

Comment 43

[Wesley Johnston (:wesj)]

Attachment: Patch 5 - Native theming for Windows

Comment 44

[Wesley Johnston (:wesj)]

Attachment: Patch 6 - Native Theme OSX

Comment 45

[Wesley Johnston (:wesj)]

Attachment: Patch 7 - Support for theming the active part of the slider on linux

Comment 46

[Markus Popp]

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

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]

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

Comment 49

[Markus Popp]

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

(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 (:asurkov)]

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 (:asurkov)]

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

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

Comment 54

[alexander :surkov (:asurkov)]

done bug 863633 and bug 863634

Comment 55

[Jonathan Watt [:jwatt]]

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]

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.

Comment 57

[Eric Shepherd [:sheppy]]

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.