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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13154

--- Comment #20 from Cameron Jones <cmhjones@gmail.com> ---
Some further investigation and attempt to flush out a definition.

The use of multiple range 'handles' can be defined through a @multiple numeric
indicator:

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

The use of labels can be applied through the application of <option> and
<datalist>:

<datalist id="opts">
    <option value="1">Option 1</option>
    <option value="2">Option 2</option>
    <option value="3">Option 3</option>
</datalist>

<input type="range" list="opts" step="1" min="1" max="3">

You can see that in this case the @min and @max could be implied through the
inspection of the range 'datamodel' supplied through the list="opts".


This can further be extended for 'in-scale' grouping through applying
<optgroup>(s):

<datalist id="opts">
    <optgroup label="Impossible">
        <option value="0">
    </optgroup>
    <optgroup label="Possible">
        <option value="0.25">
        <option value="0.5">
        <option value="0.75">
    </optgroup>
    <optgroup label="Certain">
        <option value="1">
    </optgroup>
</datalist>

<input type="range" list="opts" step="0.25" min="0" max="1">

Here we can see a duplication of numeric markers which could be toggled as a
CSS indicator. 

Also, <optgroup> could be extended to support @min and @max (and even @step)
for defining its scope within the range.

So, this could be replaced with:

<datalist id="opts">
    <optgroup label="Impossible" min="0" max="0"/>
    <optgroup label="Possible" min="0.25" max="0.75"/>
    <optgroup label="Certain" min="1" max="1"/>
</datalist>

<input type="range" list="opts" step="0.25" min="0" max="1">

Again, the @min and @max could be inferred from the 'datamodel'.


Further, we could define a 'named' range like this:

<datalist id="opts">
    <option value="opt1">Option 1</option>
    <option value="opt2">Option 2</option>
    <option value="opt3">Option 3</option>
    <option value="opt4">Option 4</option>
    <option value="opt5">Option 5</option>
</datalist>

<input type="range" list="opts" step="1" min="opt2" max="opt4">

Here, either the value of the <option> can be used within @min or @max, also
each <option> within <datalist> is given an implicit index within the
<datalist>.

So, the input for the same <datalist> could be written:

<input type="range" list="opts" step="1" min="2" max="opt4">

This also implies that the default step for 'named' ranges would be 1, in
keeping with their implicit whole-number index.

The case for using a fractal step with named ranges (so any value in between)
is an clash with regard as what value, or state, the range is in. In this case,
as the author has chosen to use string values for their <option>s, these should
be the deafult value for handles in that position. The author would have the
ability to only markup position + label, without affecting value using
non-named <option> value.

The use of <option> also provides further attributes for range state
declaration:

<datalist id="opts">
    <option selected>Option 1</option>
    <option>Option 2</option>
    <option selected>Option 3</option>
</datalist>

<input type="range" list="opts" multiple="2">

Here the handles have predefined position on the 1st and 3rd options.

There is also the potential to have in-range exclusions through the use of
@disabled which would 'step over':

<label>Pick a number between 1 and 10 other than Pi:<label>

<datalist id="opts">
    <option value="1">One</option>
    <option value="3.14" disabled>Pi</option>
    <option value="10">Ten</option>
</datalist>

<input type="range" list="opts" step="0.01" min="1" max="10">

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 9 October 2013 16:15:07 UTC