Bug 19073 - WF3: Allow two handles on input type="range", like this: http://jqueryui.com/demos/slider/#range
WF3: Allow two handles on input type="range", like this: http://jqueryui.com/...
Status: RESOLVED REMIND
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
Other other
: P5 enhancement
: ---
Assigned To: This bug has no owner yet - up for the taking
HTML WG Bugzilla archive list
http://www.whatwg.org/specs/web-apps/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-25 22:25 UTC by contributor
Modified: 2013-01-30 07:51 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-09-25 22:25:49 UTC
This was was cloned from bug 13154 as part of operation REMIND convergence.
Originally filed: 2011-07-06 01:10:00 +0000

================================================================================
 #0   contributor@whatwg.org                          2011-07-06 01:10:15 +0000 
--------------------------------------------------------------------------------
Specification: http://www.w3.org/TR/html5/spec.html
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Please give developers the ability to use two handles on input type="range",
like this: http://jqueryui.com/demos/slider/#range

This feature is very important when the user must enter two boundary values
​​of the interval.

Posted from: 95.31.9.93
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
================================================================================
 #1   Tab Atkins Jr.                                  2011-07-06 18:15:51 +0000 
--------------------------------------------------------------------------------
I agree that a two-handle range is a useful and reasonably common widget.  This can probably wait until the current form stuff is well-supported, though.
================================================================================
 #2   Aryeh Gregor                                    2011-07-06 20:54:21 +0000 
--------------------------------------------------------------------------------
This is probably something we want to add, but not until browsers have more solid WF2 support.
================================================================================
 #3   Jonas Sicking                                   2011-07-07 23:54:57 +0000 
--------------------------------------------------------------------------------
For what it's worth, I believe type="range" support is coming along in most browsers main-stream browsers. There are other controls which is seeing much slower adoption, such as type="date", however I don't see a reason to hold off working on range-like controls until the problems surrounding date pickers have been solved.
================================================================================
 #5   Ian 'Hixie' Hickson                             2011-08-13 02:52:34 +0000 
--------------------------------------------------------------------------------
Yeah, we probably need to address this soon. Marking REMIND for now but I'll get back to that once the feedback is down to more manageable levels in a month or so. Please don't hesitate to reopen this in mid September or so if I forget (I do check REMIND bugs regularly, but might not be prompt).

Meanwhile, anyone got any good ideas of how to fix this? New type (type=actually-a-range)? Attribute for type=range (<input type=range foobar>)? Reuse multiple="" somehow? How about submission; have the value be a comma or space separated list? Do type=image-like name.min=foo&name.max=bar?
================================================================================
 #6   Jonas Sicking                                   2011-08-22 20:59:04 +0000 
--------------------------------------------------------------------------------
First thing I could think of was

<input type=range highlow>

And yes, I think type=image-like is a good way to go.
================================================================================
 #7   Cameron Jones                                   2011-08-29 16:39:20 +0000 
--------------------------------------------------------------------------------
it might be possible to alter the specification of 'multiple' attribute to be dynamically typed and have a numeric value for the declaration of the quantity of multiplicity, eg:

<input type="range" multiple="2"/>

This indicates that the range should have 2 values, and the agent should interpret and provide the corresponding interface. 

The extrapolation of this example illustrates greater potential for this extension and could also extend to the 'required' attribute for declaration of the number of values required.

This will work well with the other constraint declarations to provide rich interface elements:

<input type="range" multiple="4" required="2" min="-1" max="1" step="0.1"/>
================================================================================
 #8   Simon Pieters                                   2011-08-30 09:28:07 +0000 
--------------------------------------------------------------------------------
Why would we ever want more than two values?
================================================================================
 #9   Cameron Jones                                   2011-08-30 12:09:05 +0000 
--------------------------------------------------------------------------------
there's no reason why a representation of a 'range' can't select multiple values within that range. this is what the control represents in single-valued mode - "select a value within this range" where the range (or scale) is bound by the min\max values. for dual-value mode there is more of an assumption that the user is selecting the 'range', however they are really still selecting 2 values within the overall range\scale. 

nothing is lost by allowing a 'range' input to select multiple values yet this opens the element for greater use.

implementing slider\scale controls in other languages i considered this to be relatively standard, however it would seem to be a less used configuration than i expected. there is no difficulty in representing this control to a user with multiple handles, and the implementation of encoding the values assigned to the control will require the same considerations.

for a specific use case, i'll just continue in abstract and just say that someone will want to collect 3, 4, etc values within a pre-defined range\scale. when combined with datalist, and especially when exhibiting pre-defined\natural ordering, the ability to graphically represent the choice of multiple values with a visual representation of their natural characteristics and relativity is not possible through other controls.
================================================================================