[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 #29 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
> What i quite like is the way @files works, by providing access to an array.

Well regardless of what architecture we use here, we're still going to have IDL
accessors to get the low and high parts of the range, sure. That's a given.


> IFF the value series is not represented as a microsyntax within value="",
> then there is no parity between HTML and form encoding to maintain. Both
> would define the format which best fits their model for the scope of use.
> 
> Bridging HTML formats and form encoding is blending two distinct uses into
> the same model.

I agree that in principle we don't have to keep them in sync. In practice,
though, it makes it simpler to deal with.


> Sure, but also consider the case where we have a non-HTML client using the
> same API.

Since the API is defined to describe each component separated by commas, this
seems to Just Work. No? I don't really see the problem here.


> We have to provide the same level of error reporting as for any
> other user. Mandating that clients must provide input in discrete parameters
> ensures that a generic API can provide the information back to clients in a
> piece-meal fashion.

I'm not following how this concretely applies here.


> To say that all of these clients must know and construct a new specific
> syntax for a particular parameter imposes otherwise avoidable constraints.
> 
> These clients may be served an entirely different media type than HTML. Why
> should HTML impose it's internal data formats onto other clients?

Having the values in one "field" makes sense purely from the point of view of
the data format, not considering HTML at all, IMHO, as shown by the example at
the bottom of comment 23.


There's three things we have to figure out:

1. What does the markup look like to declare a two-value range input with
preset values.
2. What does the API look like to use this control from JS.
3. What does the result look like when submitted.

Looking at all the comments in this bug so far, I think the simplest answers
all around are:

1. <input name=foo type=range multiple min=1 value=3,5 max=10>
2. input.valueLow and input.valueHigh to get the two values from JS
3. "3,5" as the value in the submission (i.e. ...?...&foo=3%2C5&...)

This is easy to explain, easy to write, easy to use in JS, easy to parse on the
server, and it's of minimal impact on the spec.

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

Received on Tuesday, 12 November 2013 23:05:57 UTC