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: Mon, 07 Oct 2013 15:37:19 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-13154-2486-B61Rqdn3Vj@http.www.w3.org/Bugs/Public/>

--- Comment #17 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #16)
> There's no technical reason we can't do:
>    <input type=range multiple min=0 max=10 value="2,5">
> ...or some such, if we're ok with it. We'd probably have to add two new IDL
> attributes to replace valueAsNumber for this specific case

Is value="2,5" a new micro-syntax? 

What about the possibilty of 'named' steps - so with the use of <option> using
a label instead of numeric value?

This implies that @value syntax (and even @min and @max for single-value) need
to have discrete strings and a form of escaping, otherwise they would be
pointers referring to a position within a list.

> ... and the submitted value would have to be parsed (split on comma) on the 
> server, but those aren't insurmountable problems.

It would be better to retain the same conventions for Query/Form encoding and
avoid the syntax of value="" breaking out of HTML. The best reason for this is
so that APIs can remain the same when switching between different UI controls,
ie you should be able to swap an <input type="range"> for a <select> with the
same options and be able to interact with the same API.

Otherwise there is a coupling of UI to API, visa-versa.

> We already use <option> for tick marks on <input type=range> using the
> list="" attribute, so we'd get that for "free" here too.

The big difference is no <optgroup> for grouping - maybe this could be added as
valid content for <datalist>? The ability to demarkate groups within scales is
quite valuable, for example in temperature: Cold, Warm, Hot.

I thought that <select> was using either <option> or <datalist>, but that
wouldn't make any sense unless <select> were editable.

> Maybe this isn't as bad as I initially thought. It's a bit weird, but it's
> actually the same as <input type=email multiple>, really.

The multi-value email interface isn't really much of a UI control. It seems
more for validation. I'd probably prefer to have some kind of "list-building"
interface control which was a bit like an editable select box with
insert/delete controls. I guess there's no reason something like that could't
be made from the current definition with @multiple switch.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 7 October 2013 15:37:21 UTC

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