But that's true for all HTML5 features. I'm frankly glad that Mozilla has prioritized stuff like IndexedDB (not yet in Safari or Opera, Chrome using an outdated spec last I checked).
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.
Luckily, new input types should be very easy to provide via polyfill. Personally, I'd rather Mozilla implement the features that can't be implemented by polyfill first.
It's not bad, but I think it's unfortunate that nobody is working on it. The sooner that HTML5 features are implemented, the better. I thought that posting it here would get some eyeballs on it!
I think it's fair to say that Mozilla is focused on the web as an applications platform, hence stuff like this: https://wiki.mozilla.org/WebAPI I'm ok with these input fields getting put on the backburner because they're easy to polyfill, for example this: http://frankyan.com/labs/html5slider/ works perfectly well in Firefox.
The fear is that posting a bug like this on a social network will result in a bunch of people commenting on the bug about how this needs to be our new #1 priority or how we're just too slow. While both are perfectly valid criticism, bugs just aren't the best place to bring that up.
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.
Comments
Is this bad? All browsers must have priorities. Is there a reason why input[type="range"] should be a priority over the stuff they're working on?
Mainly because it's high profile.
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.
But that's true for all HTML5 features. I'm frankly glad that Mozilla has prioritized stuff like IndexedDB (not yet in Safari or Opera, Chrome using an outdated spec last I checked).
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.
Luckily, new input types should be very easy to provide via polyfill. Personally, I'd rather Mozilla implement the features that can't be implemented by polyfill first.
>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.
That was true once, but the autoupdating nature of Firefox and Chrome challenges that assertion.
It's not bad, but I think it's unfortunate that nobody is working on it. The sooner that HTML5 features are implemented, the better. I thought that posting it here would get some eyeballs on it!
I think it's fair to say that Mozilla is focused on the web as an applications platform, hence stuff like this: https://wiki.mozilla.org/WebAPI I'm ok with these input fields getting put on the backburner because they're easy to polyfill, for example this: http://frankyan.com/labs/html5slider/ works perfectly well in Firefox.
The fear is that posting a bug like this on a social network will result in a bunch of people commenting on the bug about how this needs to be our new #1 priority or how we're just too slow. While both are perfectly valid criticism, bugs just aren't the best place to bring that up.
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.
Hmm, like all software makers, Mozilla have a finite number of people too. I suppose they'll get round to it eventually!
Agreed. Plus, the more issues/bugs are put as 'high priority' in a project the less priority they get, they level out.