But also because it can't be used until it's been in browsers for a long long time. So you need to get it in there early.
There is a HUGE lag time from when it's implemented to when it's usable.
Unless there is a reason why input[type="range"] is more important than the stuff they are working on, I don't think we can really complain. Mozilla arguably has the fastest release cycle nowadays.
That was true once, but the autoupdating nature of Firefox and Chrome challenges that assertion.
I posted links to the mailing lists in my other comment; if you haven't already, posting a thread to them asking about the priority of the bug would be a good way of getting the attention of a bunch of devs and planning people at once.
Bugs like this are meant to be mostly for technical discussion and aren't the most effective way of getting attention around this kind've issue.
In a similar vein, I get lazy with the word "milk" and pronounce it as "melk", and am the only person I know who does so. Apparently I'm broken. :D
To me implying that "HTML5 isn't a priority for mozilla" because they haven't implemented a really marginal component is quite an exaggeration. I think using bug reports to try to create pressure on developers is in this weird grey area of stuff where it violates some sort of implicit social code of bug reporting. (In short: it's sort of a passive aggressive move)
Having an opinion on what should prioritized is fine, but it should be marketed as such, IE, make it a blog post or write an email or something instead.
I've been dying to have native sliders for ages. There are lots of user interfaces to be made that have nothing to do with databases, CRUD, or social networks. For example, sliders are particularly essential to audio/video/lighting control and media editing UIs.
Yesterday's thinking will only solve yesterday's problems.
Mozilla devs have limited resources and they decided to tackle developing a better DOM before adding new auxiliary features. How is this wrong?
The main comment says:
«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.»
They think that their efforts are better spent on DOM performance rather than form sliders. We argue about that, but one has to accept that, in presence of limited resources, one has to prioritise something.
When people must create their own:
* Implementations are more often than not sub-par.
* Implementations are inconsistent (will clicking off the thumb snap to the mouse or act as an increment?).
* There is no platform-native look & feel control (which should matter for any FF phone device, as they should want all apps to use a single slider implementation).
This is one of the features that would stop me having to churn out literally acres of JavaScript validation and normalising forms across different browsers.
I mean even IE10 supports them now: http://ie.microsoft.com/testdrive/HTML5/Forms/default.html
