I have a screenshot on this attach document but I do not know what you call this type of function in a html form. Is it just simply a textarea with a scrollbar which allows you to select numbers higher or lower? If I know what it is then I can research this I find out how to code it myself.
It’s not a standard <select> because I assume the numbers automatically scroll up and down as you hold down either the up or down arrow next to each box and when you stop scrolling, the current visible value automatically becomes the value for that box.
One way to create the same effect is to use a <textarea> with rows=1 and then use onmousedown and onmouseup event handlers on the arrows to run/stop some javascript to increment or decrement the <textarea>'s value by 1 at set intervals, say 0.5 secs or whatever speed you want.
I was going to say the same thing, but then remembered that in the new Mac interface, that’s the appearance of standard select elements now-a-days, so thought it might be the same on Windows. (There is a default up and down arrow, though the bahavior is the same as before: just a drop down list.)
EDIT: OK, just checked a few modern Windows browsers and see that they just have the down arrow, so yes, presumably that’s a screen shot of something more than a standard select list.
Mind you, a select list is still the way to go here. Getting JS involved may cause unnecessary accessibility obstacles.
If accessibility is an issue then obviously you’ll need a Plan B to replace Plan A for javascript disabled browsers.
Otherwise there is no reason why your Plan A couldn’t be scrolling up/down values as you click and hold on one of the arrows and when you release the mouse the current visible value in the box automatically becomes the value for that box without having to actually click the value like you do in a <select>
I’m not sure which was plan A and which plan B above, but it may be that the example in the screen shot above does have a fallback for those with JS off. Some amazing things are happening in the realm of accessibility with JS, and though they aren’t quite there yet in a lot of respects, it’s pretty clear that not too far into the future there will be some really good solutions for these things. Well, hopefully, anyhow. And hopefully by that time, I’ll have some idea how they work.
Why would anyone want to build a website just for 1 person (:
And if your audience includes a small number of people using some ancient version of Netscape or other “dinosaur” browser are you suggesting I should have to cater for them? I don’t even support IE6 anymore, let alone any older browsers
When I mention accessibility to designers, they are often scathing, mainly (though they don’t acknowledge it) because they don’t consider it an issue for them. So in other words, they are acting like the site is designed solely for them.
So when you said accessibility is not an issue for you, I was just pointing out that that’s not an excuse to ignore it when building a website.
And if your audience includes a small number of people using some ancient version of Netscape or other “dinosaur” browser are you suggesting I should have to cater for them? I don’t even support IE6 anymore, let alone any older browsers
I wasn’t thinking of people using dead browsers. I agree that they get what they deserve. But a lot of sites use JS to serve up content that is almost or completely inaccessible to blind users with screen readers (for example). The ideal is to establish a way for them to be able to access the content too. Unless the content in that select element (or whatever stands in its place) is accessible with JS off or via assistive technology, it could be said to fail in its duty from a purist point of view. To use some JS-dependant, inaccessible alternative to a select list just for its fancy appearance is retrograde, IMHO.
I agree in general with the points you make but all I am saying is that where practical you can have functionality with all the “you beaut.” bells and whistles and a Plan B for javascript disabled browsers, screen readers etc etc.
And unless I and/or the client are legally bound to provide useable functionality for screen readers, javascript disabled browsers etc in addition to all the bells and whistles functionality, then whether I provide functionality for javascript disabled browsers etc or not boils down to
whether the client wants to pay for any extra costs, depending on any extra amount of work that might be required.
or
whether I have the time to do any extra work for free if it’s not a legal requirement.
HTML5 introduces a number input type with min and max attributes that makes it possible to achieve that design. Otherwise a select would be the most appropriate. Though number if not supported would default to a normal text field. So it is probably enough to supply a message for a number within a certain range with server-side validation for those browsers that do not support number.
HTNL5 is still in development and support for HTML5 varies greatly between browsers.
Anyway, I’ve had a bit of a play with this and below is a quick and simple “no frills” value slider.
Just hover over the up and down arrows and the value in the box will change automatically up or down in increments of 1 between the values of 1 and 24.