- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Oct 2013 15:52:44 +0000
- To: public-html-bugzilla@w3.org
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