Bug 344618 - Implement input type="range" | Hacker News Reader

Bug 344618 - Implement input type="range"

bugzilla.mozilla.org

46 pointsjmitcheson25 comments

Misleading title. Flamebait.

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.

Just to be clear, that wasn't a Mozilla employee commenting, so they won't necessarily even have a good view of Mozilla's priorities.

In case anyone decides that they want to register for Bugzilla and comment on the bug itself about how they feel about priorities, please heed bz's comment and take the discussion to a more appropriate (and probably more responsive) area, like dev-planning[1] or dev-platform[2].

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.

[1] https://lists.mozilla.org/listinfo/dev-planning

[2] https://lists.mozilla.org/listinfo/dev-platform

Off topic: that "kind've" is interesting. It looks like a contraction, but it saves no space over the normal "kind of". Is that just a personal colloquialism of yours, or is it part of a regional thing, or...?

It is a grammatical error.

I've seen it used before, which is why I'm willing to give the benefit of the doubt that it's possibly an evolutionary branch of the language. Being a grammatical error is the obvious answer, but not always the correct one.

Probably a personal thing. I say the word aloud as if it were a contraction, and having never bothered to actually learn proper grammar, I figured it was fine since it sounded correct in my head.

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

Thinking about it, I don't think I've ever really had a reason to use a slider on a web form. It'd be nice to have, I suppose.

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.

Thinking about it, I don't think I've ever really had a reason to use a slider on a web form.

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.

Sure. But there's a way to say "this would be awesome to have, here's all the places I could use it" and ask politely versus "I'm going to make a public display of this on a popular news site in order to pressure you into what I want"

The title here really needs to be changed. No one in the linked report representing Mozilla says anything even close to that. The phrase "not a priority" doesn't even appear on that page, so putting it in quotes is a bit much!

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?

Agreed. Plus, the more issues/bugs are put as 'high priority' in a project the less priority they get, they level out.

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.

Hmm, like all software makers, Mozilla have a finite number of people too. I suppose they'll get round to it eventually!

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.

It's a bummer since sliders are such a fundamental control.

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

I've noticed this as well without having to go near their bugzilla for confirmation. It's not just the range control - it's pretty much everything.

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

While i agree that it probably doesn't matter what gets priority from dev prespective, i believe they should implement form stuff first because they are (probably) easier to implement than a whole API that interacts pages with OS. The devs who try out the simple to test input type range code are far more in number than people who try out APIs. So they take less time and have more users than apis.j cant see why they aren't higher in priority especially since all other major browsers have atleast some kind of implimentation of it.

Range inputs are one of those things that seem obvious but in practice aren't that useful, in the grand scheme of things.

Reply on news.ycombinator.com