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: Fri, 04 Oct 2013 15:41:42 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-13154-2486-JxlYIOJBeQ@http.www.w3.org/Bugs/Public/>

--- Comment #15 from Cameron Jones <cmhjones@gmail.com> ---
Creating a new element is quite heavy-weight, especially given the potential
for something to fit into <input type="range">. 

The alluring features of <input type="range"> are its pre-existence and the
integration and reuse of @multiple, @step, @min, @max, and other attributes.
The @multiple attribute would be required to be extended to allow for a numeric
value, and this could clash with @required, although it is possible to have
interfaces which cater for variability in the number of handles through their
'folding-in' on discrete values - two handles both on '1' is the same result. 

The only other input types using @multiple are 'file' and 'email'. It also
exists on <select>. 

Perhaps another way of looking at this is whether @multiple could be deprecated
on <input> and instead make <input> a single-value user input, and repurpose
<select> for multiple-value user input. This would require the addition of a
@type attribute for similar discrimination as required for <input>. The benefit
is the separation of single and multiple values into distinct elements. This
could be beneficial for 'file' and 'email' by having custom interfaces to
manage multi-values through some expanded <select>-style box.

Alternatively, what about introducing a new <input values=""> attribute? This
would be purely for providing declaration/access over a collection of values
(or a collection of one, for single-value inputs). The regular value=""
attribute would retain its current semantics and provide the first/default
value in the set.

The other factor in minting a new element/re-purposing <select>, is the
opportunity to cater for descendent elements and the reuse of <option> and
<optgroup>. These are a really good fit for the labeling and value-demarcation
of ranges. It would seem a shame to loose these, although akin to loosing @min,
@max, @step from <input>.

The styling of multi-value range will impose new requirement on CSS, probably
through the application of pseudo-classes. This is largely unaffected by the
choice of implementation.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 4 October 2013 15:41:44 UTC

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