W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2013

[Bug 13154] WF3: Allow two handles on input type="range", like this: http://jqueryui.com/demos/slider/#range

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Oct 2013 15:52:44 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-13154-2486-gZb2k7tjVK@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13154

--- Comment #13 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #11)
> (In reply to Cameron Jones from comment #9)
> > nothing is lost by allowing a 'range' input to select multiple values yet
> > this opens the element for greater use.
> 
> One thing that would be lost is simplicity.
> 

That's true, there is an increase in complexity of UI elements capable of
capturing single _or_ multiple values.

The <select> element has this functionality, and employs an implementation 
simplification on the value such that it only ever represents the first 
selected value. Any dynamic inspection of the state is left as a task for the 
author through Javascript. 

Perhaps a similar approach could work for 'range'?

> So one problem is how to specify the value of a type=range with two values.
> It's all very well submitting it as foo.min=1&foo.max=4, but we only have a
> single value="" attribute to read the value, so that implies we should be
> either using value="1,2" or some such (and presumably submitting the same
> way), or doing something else entirely. Adding multiple value="" attributes
> seems dodgy.
> 
> Any opinions?

The wire encoding is not an issue. Query and form encoding can both handle 
multiple values, and order, within their syntax.

So, the problem is how the state of the element is dynamically accessible. 
Since this is for Javascript, i prefer the array syntax with a natural 
order. A new attribute can provide access.

Another option is the possibility to mint a new element along 
the lines of <select> (maybe <scale>?), so to allow descendent elements with 
<option>(s). This could use the same semantics for distinguishing between 
'suggested' and 'restricted' values for notches.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 2 October 2013 15:52:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:44 UTC