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.
(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?
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"].
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.
a new HTML5 Working Draft is out:
Draft Standard — 1 October 2010
It would be nice to have this in Firefox 4.0 too
Firefox 4 is in feature freeze. This is not happening for Firefox 4.
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.
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>
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.
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:
> 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
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.
> 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.
I found a nice MIT-licensed implementation here:
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.
A new draft (5 February 2011)
(for this example the sliders would be very helpful)
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:
> 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. :)
Take it. I'm busy doing other things. :)
*** Bug 649963 has been marked as a duplicate of this bug. ***
http://userscripts.org/scripts/show/101214 - user script for insert html5slider.js (required Greasemonkey)
*** Bug 656496 has been marked as a duplicate of this bug. ***
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
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.
> 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...
Any news on this ?
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.
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?
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) ?
(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.
(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
Links to find these mailing-lists:
> 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.
*** Bug 782165 has been marked as a duplicate of this bug. ***
Created attachment 666577 [details] [diff] [review]
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]
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 on attachment 671334 [details] [diff] [review]
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.
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'
Did you mean NS_THEME_RANGE?
/Users/frank/mozilla/widget/cocoa/nsNativeThemeCocoa.mm:2250:18: error: use of
undeclared identifier 'nsIDOMHTMLInputElement'; did you mean
nsCOMPtr<nsIDOMHTMLInputElement> inputElt = do_QueryInterface(content);
#include "nsIDOMHTMLInputElement.h" ?
*** Bug 810234 has been marked as a duplicate of this bug. ***
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...
say that IE 10, Safari 5.0, Opera 10, Chrome 6 could use input=range.
Created attachment 701418 [details] [diff] [review]
Path 1 - Content pieces
Been way to busy to work on this. Updating these to hand this off.
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
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.
"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."
Filed bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=853670
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.
oninput event is fired whenever thumb is clicked (no value change). Is it known issue? Should I file a bug on this?
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.
done bug 863633 and bug 863634
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.
This has been noted in the Aurora 23 release notes:
If you would like to make any changes or have questions/concerns please contact me directly.