I agree that a two-handle range is a useful and reasonably common widget.  This can probably wait until the current form stuff is well-supported, though.

This is probably something we want to add, but not until browsers have more solid WF2 support.

For what it's worth, I believe type="range" support is coming along in most browsers main-stream browsers. There are other controls which is seeing much slower adoption, such as type="date", however I don't see a reason to hold off working on range-like controls until the problems surrounding date pickers have been solved.

mass-move component to LC1

Yeah, we probably need to address this soon. Marking REMIND for now but I'll get back to that once the feedback is down to more manageable levels in a month or so. Please don't hesitate to reopen this in mid September or so if I forget (I do check REMIND bugs regularly, but might not be prompt).

Meanwhile, anyone got any good ideas of how to fix this? New type (type=actually-a-range)? Attribute for type=range (<input type=range foobar>)? Reuse multiple="" somehow? How about submission; have the value be a comma or space separated list? Do type=image-like name.min=foo&name.max=bar?

First thing I could think of was

<input type=range highlow>

And yes, I think type=image-like is a good way to go.

it might be possible to alter the specification of 'multiple' attribute to be dynamically typed and have a numeric value for the declaration of the quantity of multiplicity, eg:

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

This indicates that the range should have 2 values, and the agent should interpret and provide the corresponding interface. 

The extrapolation of this example illustrates greater potential for this extension and could also extend to the 'required' attribute for declaration of the number of values required.

This will work well with the other constraint declarations to provide rich interface elements:

<input type="range" multiple="4" required="2" min="-1" max="1" step="0.1"/>

Why would we ever want more than two values?

there's no reason why a representation of a 'range' can't select multiple values within that range. this is what the control represents in single-valued mode - "select a value within this range" where the range (or scale) is bound by the min\max values. for dual-value mode there is more of an assumption that the user is selecting the 'range', however they are really still selecting 2 values within the overall range\scale. 

nothing is lost by allowing a 'range' input to select multiple values yet this opens the element for greater use.

implementing slider\scale controls in other languages i considered this to be relatively standard, however it would seem to be a less used configuration than i expected. there is no difficulty in representing this control to a user with multiple handles, and the implementation of encoding the values assigned to the control will require the same considerations.

for a specific use case, i'll just continue in abstract and just say that someone will want to collect 3, 4, etc values within a pre-defined range\scale. when combined with datalist, and especially when exhibiting pre-defined\natural ordering, the ability to graphically represent the choice of multiple values with a visual representation of their natural characteristics and relativity is not possible through other controls.

This bug was cloned to create HTML WG bug 19073.

(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.


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 more I think about it, the more I think reusing <input type=range> will just lead to confusion. I think minting a new type=? is a simpler way to go.

We could have .value return something like { min: x, max: y } though that's somewhat messy since we end up in the same old "is the object mutable?" debate.

(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.

Creating a new element for this would be unfortunate... I'd rather try to exhaust the possibilities with <input> first.

But since I'm out of good ideas for how to make this work with <input value="">, maybe the possibilities are exhausted already?

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.

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, and the submitted value would have to be parsed (split on comma) on the server, but those aren't insurmountable problems.

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

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.

(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.

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

Insofar as a comma-separated list is a microsyntax, sure.


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

What's the use case?


> 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.

I don't follow. Can you elaborate? How does this impact <input type=email multiple>, for example? (It uses the same syntax as I'm suggesting here.)


> 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.

This is getting pretty elaborate. At some point we have to draw a line and say "if you want a more elaborate control, use Web Components to make it yourself". I'm not sure which side of the line this suggestion should be on, though.

Can you give concrete examples of what your suggestion would look like?


> The multi-value email interface isn't really much of a UI control.

It's exclusively a UI control, no? I don't follow.

I don't really understand what a "list-building control" would be. Can you give an example of one? (I see two-point range controls all over the Web.)

(In reply to Ian 'Hixie' Hickson from comment #18)
>
> > What about the possibilty of 'named' steps - so with the use of <option>
> > using a label instead of numeric value?
> 
> What's the use case?
> 

It really just opens up the control for ontological display and input, so when the numeric value is of little (or lower) significance and would otherwise fail to communicate with the user so aptly.

An example would be the 'ages of man', quoting from wikipedia['Ages_of_Man']:

"Anthropology and evolutionary biology recognize various periods/ages of Homo (Man, the Human Genus) beginning with the invention of stone tools in the Oldowan. These periods are grouped into Prehistory (subdivided into Lower, Middle, and Upper Paleolithic, followed by Mesolithic and Neolithic) and Recorded History (subdivided into Antiquity, the Middle Ages, and Modernity)."

The numerical year values for these is of little to no relevance to the representation to the user, however almost every user would be able to relate to a scale with these markers and be able to answer questions and provide input based on the relativity within the markers.

This is the value of type="range", it allows for user selection within a graphically depicted scale of relativity between or within the options.

> 
> > 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.
> 
> I don't follow. Can you elaborate? How does this impact <input type=email
> multiple>, for example? (It uses the same syntax as I'm suggesting here.)
> 

The encoding for email is also undesirable for the same reason, i thought that this was actually encoded using the same mechanism as <select>, where frequency and order of parameters have significance within encoding.

The encoding structure of query/form encoding essentially imposes no restriction on UI, as long as inputs are named and multiple values use the same name. Breaking this design property would be unfortunate.


> > 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.
> 
> This is getting pretty elaborate. At some point we have to draw a line and
> say "if you want a more elaborate control, use Web Components to make it
> yourself". I'm not sure which side of the line this suggestion should be on,
> though.
> 
> Can you give concrete examples of what your suggestion would look like?
> 

See above for the kind of use case i'm considering.

The scope for Web Components is good, but i don't see any real difference whether the work is done as a component or as a 'built-in' control.

What is the scope for authors of Web Components to use native OS controls? AFAIK, the native controls have the flexibility with which to build such a multi-value control, but these would be outside the realm of Web Components. This means either tailoring UI for each platform, or creating new generic controls with images or styles.

The scope for CSS binding would be preferable through HTML controls.

> 
> > The multi-value email interface isn't really much of a UI control.
> 
> It's exclusively a UI control, no? I don't follow.
> 
> I don't really understand what a "list-building control" would be. Can you
> give an example of one? (I see two-point range controls all over the Web.)

They're more the kind of controls you would build using a programmable GUI. Web Components can definitely fill the gap, but isn't there still a desire to improve the basic set of controls? One thing which is missing for Web Components is the ability to manipulate sub-element UI features.

The concept of a "list-building control" would be to provide a control which allowed users to enter and edit a list of values - but as discrete items. The method used for <input type="email" multiple> relys on parsing a user-string and the use of comma delimiters. I expect this to be beyond most web users.

You see "editable lists" all over UIs, usually the OS Wifi manager has one. For HTML it would allow the browser to take control of state prior to sending a form. It's probably something that browsers could just implement for the existing @multiple controls, maybe with a nice CSS switch.

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">

Ok. The issue of labeling parts of the scale seems out of scope of this bug; if you want that supported as a native HTML feature, please file a separate bug or send mail to the list. Same with disabling specific values and so on.

This bug is about the ability to select more than one value with a range control.

I think I'm going to go with the design in comment 16 unless there's a use case for more than two numbers. If there is, please point to a Web page that does that, so that we can study what it means. (Cases with two handles are common, e.g. google.com/flights).

(In reply to Ian 'Hixie' Hickson from comment #21)
>
> This bug is about the ability to select more than one value with a range
> control.

Sure, the extrapolation of alternative designs introduced the additional considerations.

> I think I'm going to go with the design in comment 16 unless there's a use
> case for more than two numbers. If there is, please point to a Web page that
> does that, so that we can study what it means. (Cases with two handles are
> common, e.g. google.com/flights).

I'm fine with limiting to only 2 values, it seems the most prudent step forward and doesn't impose nor limit any further work on any controls.

The only outstanding issue is the nature of query/form encoding and value representation.

The problem with comma-delimited microsyntax for multiple values is that the comma is a restricted character and so will be percent-encoded.

This makes deducing the individual entries a lot more difficult than if they are already split before encoding, a new microsyntax must be incorporated and decoded instead of just fetching a value by key from the query/form data set.

This problem is excaserbated when viewed with email (as oppsed to a purely numeric range value) as example. I assume this might be one reason why the email syntax has been restricted over the RFCs. 

The <input type="file" multiple> uses the same query/form encoding as <select>, this a preferable standard approach. Can the same implementation also be applied to 'range' and 'email'?

> The problem with comma-delimited microsyntax for multiple values is that the
> comma is a restricted character and so will be percent-encoded.

Actually comma isn't percent-encoded, but more importantly, a server should always apply the query-decoding logic, because there's nothing semantically different between

   http://example.com?a=A+

...and:

   http://example.com?%61=%41%20


> This makes deducing the individual entries a lot more difficult than if they
> are already split before encoding, a new microsyntax must be incorporated
> and decoded instead of just fetching a value by key from the query/form data
> set.

If you have the query/form data set already decoded such that you can just fetch its value, then it'll already be %-decoded, and you can just split on commas.


> This problem is excaserbated when viewed with email (as oppsed to a purely
> numeric range value) as example. I assume this might be one reason why the
> email syntax has been restricted over the RFCs. 

Not sure what you mean here. Posting the form by e-mail would just have something like:

   range=1,54

...which seems quite readable to me.


> The <input type="file" multiple> uses the same query/form encoding as
> <select>, this a preferable standard approach. Can the same implementation
> also be applied to 'range' and 'email'?

type=file is a special case. It has hard-coded logic all over the place, it can't be set to a value when you create the form, and it generates attachments in the output. This is quite different from anything else and not really a model I think we should follow.

The other problem with using multiple values in the type=file style is what happens with cases like this:

   Choose the ranges you want to cover:
   <input name=ranges type=range multiple>
   <input name=ranges type=range multiple>
   <input name=ranges type=range multiple>
   <input name=ranges type=range multiple>
   (button to add more...)

With the comma-based proposal, you end up with:

   ranges=1,4&ranges=6,9&rangles=14,44&ranges=80,90

...but with the type=file-style system you end up with:

   ranges=1&ranges=4&ranges=6&ranges=9&rangles=14&ranges=44&ranges=80&ranges=90

...which, while still _technically_ unambiguous, is much less obvious and easier to screw up.

(In reply to Ian 'Hixie' Hickson from comment #23)
> > The problem with comma-delimited microsyntax for multiple values is that the
> > comma is a restricted character and so will be percent-encoded.
> 
> Actually comma isn't percent-encoded, 

It seems the specification and implementation do not always match :)

> ...but more importantly, a server should always apply the query-decoding 
> logic, because there's nothing semantically different between
> 
>    http://example.com?a=A+
> 
> ...and:
> 
>    http://example.com?%61=%41%20
> 
> 

Yes, the query or form data must always be decoded but introducing a new microsyntax imposes a second phase of decoding. First doing the standard decoding, then decoding the microsyntax. 

The problem here is that the new microsyntax has no form of escaping, so the encapsulated syntax is limited in its character set.

It would be better not to create a new over-the-wire syntax and just split prior to encoding and use the syntax and escaping already available and universally deployed and supported.


> > This makes deducing the individual entries a lot more difficult than if they
> > are already split before encoding, a new microsyntax must be incorporated
> > and decoded instead of just fetching a value by key from the query/form data
> > set.
> 
> If you have the query/form data set already decoded such that you can just
> fetch its value, then it'll already be %-decoded, and you can just split on
> commas.

Exactly. There is another phase to being able to retrieve the values.

It is more difficult to perform 'deconstructive' techniques (parsing) rather than 'constructive' techniques (collection building) over discrete items.

'Deconstruction' is a complex and error prone process, whereas it is (virtually) impossible to create an in-memory collection of objects from discrete items in error.

> 
> > This problem is excaserbated when viewed with email (as oppsed to a purely
> > numeric range value) as example. I assume this might be one reason why the
> > email syntax has been restricted over the RFCs. 
> 
> Not sure what you mean here. Posting the form by e-mail would just have
> something like:
> 
>    range=1,54
> 
> ...which seems quite readable to me.
> 
> 

Sorry, i wasn't referring to an email html client but to the <input type="email" multiple> control.

Due to the complexity of the email syntax in RFC 5322 it would be impossible to use conforming email addresses with the comma-delimited microsyntax for multiple values. This must be the reason why RFC 5322 has a willful violation, as otherwise it would be impossible to parse, and a far cry from doing a simple:

String[] addresses = emails.split(",");

If this is the case, then it is a bad decision to violate RFC 5322 just in order to construct a new comma-delimited microsyntax for over-the-wire encoding when there is already a standard method with full support for doing so.

Why should some email addresses be un-submittable just to support sending multiple email addresses as a single parameter?

The comma-delimination seems more apt to support an ability to create a backwards-compatible text control which could be hacked by well informed individuals such that they could still enter multiple email addresses into an old browser and have them processed the same on the server. I think this is a poor consideration for imposing a new microsyntax across the client-server barrier. It is leaking a client implementation detail into the server.

> > The <input type="file" multiple> uses the same query/form encoding as
> > <select>, this a preferable standard approach. Can the same implementation
> > also be applied to 'range' and 'email'?
> 
> type=file is a special case. It has hard-coded logic all over the place, it
> can't be set to a value when you create the form, and it generates
> attachments in the output. This is quite different from anything else and
> not really a model I think we should follow.

Sure type="file" is a strange anomalous case requiring lots of special logic, but the <select> element also uses the same encoding model so it would seem that type="email" is the anomalous example in this case.

The value representation (so setting initial 'range' handle positions) does require some consideration. If the new microsyntax for value="" is limited in scope to the client (one way server->client only) then it shouldn't pose any problems. Constructing the 'range' HTML requires generating its specific syntax already, so whatever value representation is chosen it still requires some level of custom server-side code. I can't really think of a more concise expression of the element's state, nor a better expression for being set from within JS. (The best alternative being considered is the use of <option value="" selected>).

But, forcing the value representation into query/form encoding is unnecessary, doesn't introduce any gains over the encoding, and requires the server to have prior knowledge of what element was used to capture the data. See on for the examples.

> 
> The other problem with using multiple values in the type=file style is what
> happens with cases like this:
> 
>    Choose the ranges you want to cover:
>    <input name=ranges type=range multiple>
>    <input name=ranges type=range multiple>
>    <input name=ranges type=range multiple>
>    <input name=ranges type=range multiple>
>    (button to add more...)
> 
> With the comma-based proposal, you end up with:
> 
>    ranges=1,4&ranges=6,9&rangles=14,44&ranges=80,90
> 
> ...but with the type=file-style system you end up with:
> 
>   
> ranges=1&ranges=4&ranges=6&ranges=9&rangles=14&ranges=44&ranges=80&ranges=90
> 
> ...which, while still _technically_ unambiguous, is much less obvious and
> easier to screw up.

The choice of param names is key here, there is nothing preventing or requiring the use of that structure.

The power of the encoding model comes from being able to replace the example above with:

<label>Enter 1st range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>

<label>Enter 2nd range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>

<label>Enter 3rd range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>

<label>Enter 4th range:</label>
<input name=ranges type=number min=0 max=100>
<input name=ranges type=number min=0 max=100>


Or with this:

<label>Enter 1st range:</label>
<select name=ranges required=2 multiple>
	<option value=0>
	...
	<option value=100>
</select>
...

To me, that's pretty powerful UI.

> It seems the specification and implementation do not always match :)

What doesn't match? Who's escaping a comma?


> Yes, the query or form data must always be decoded but introducing a new
> microsyntax imposes a second phase of decoding. First doing the standard
> decoding, then decoding the microsyntax.

Yeah, but in this case doing it takes less code that your sentence above saying how much work it is. :-)


> The problem here is that the new microsyntax has no form of escaping, so the
> encapsulated syntax is limited in its character set.

There's no commas in numbers, so this seems like a non-issue. Also, comma-separated lists are hardly new.


> Due to the complexity of the email syntax in RFC 5322 it would be impossible
> to use conforming email addresses with the comma-delimited microsyntax for
> multiple values. This must be the reason why RFC 5322 has a willful
> violation, as otherwise it would be impossible to parse, and a far cry from
> doing a simple:
> 
> String[] addresses = emails.split(",");

RFC 5322 is just bogus compared to real-world usage. Commas were long disallowed in type=email before we introduced multiple="".


> The value representation (so setting initial 'range' handle positions) does
> require some consideration. If the new microsyntax for value="" is limited
> in scope to the client (one way server->client only) then it shouldn't pose
> any problems.

Not having trivial round-tripping is a problem.


> > The other problem with using multiple values in the type=file style is what
> > happens with cases like this:
> > 
> >    Choose the ranges you want to cover:
> >    <input name=ranges type=range multiple>
> >    <input name=ranges type=range multiple>
> >    <input name=ranges type=range multiple>
> >    <input name=ranges type=range multiple>
> >    (button to add more...)
> > 
> > ranges=1&ranges=4&ranges=6&ranges=9&rangles=14&ranges=44&ranges=80&ranges=90
> 
> The choice of param names is key here, there is nothing preventing or
> requiring the use of that structure.

The point is that if you do that, it's rather confusing, whereas with the comma-separated version, it's not.


> The power of the encoding model comes from being able to replace the example
> above with:
> 
> <label>Enter 1st range:</label>
> <input name=ranges type=number min=0 max=100>
> <input name=ranges type=number min=0 max=100>
> 
> <label>Enter 2nd range:</label>
> <input name=ranges type=number min=0 max=100>
> <input name=ranges type=number min=0 max=100>
> 
> <label>Enter 3rd range:</label>
> <input name=ranges type=number min=0 max=100>
> <input name=ranges type=number min=0 max=100>
> 
> <label>Enter 4th range:</label>
> <input name=ranges type=number min=0 max=100>
> <input name=ranges type=number min=0 max=100>
> 
> 
> Or with this:
> 
> <label>Enter 1st range:</label>
> <select name=ranges required=2 multiple>
> 	<option value=0>
> 	...
> 	<option value=100>
> </select>
> ...
> 
> To me, that's pretty powerful UI.

It's certainly interesting theoretically. I'm not sure it's particularly useful. When are you going to actually be trading a range control for two number controls, or even a select control?

The weirdness of "ranges=1&ranges=4&ranges=6&ranges=9" meaning "1..4 and 6..9" seems more bad than the substitutability with other controls seems good. But I agree that it's subjective.

(In reply to Ian 'Hixie' Hickson from comment #25)
> > It seems the specification and implementation do not always match :)
> 
> What doesn't match? Who's escaping a comma?

Firefox, Chrome and IE are all encoding commas. This form:

<form method="GET" action="http://www.example.com">
    <input name="email" type="email" value="abc@example.com,def@example.com" multiple>
    <button type="submit">Submit</button>
<form>

All resolve to the same URL:

http://www.example.com/?email=abc%40example.com%2Cdef%40example.com

> > The problem here is that the new microsyntax has no form of escaping, so the
> > encapsulated syntax is limited in its character set.
> 
> There's no commas in numbers, so this seems like a non-issue. Also,
> comma-separated lists are hardly new.
>

Yep, with the restriction to numbers there is no need for any escaping. I'm considering the potential for encoding user-string values, which is why the type="email" is a better examination.

So my real concern is - what is the scope for comma-separated lists becoming the 'new' mechanism for encoding series through application/x-www-form-urlencoded?

The comma-seperated list is more a data pattern than a syntax. The most popular encoding using this form of syntax is the CSV format which uses quotes for escaping. 

I'm concerned that this might be the only mechanism left for being able to support series of user-strings.

> 
> 
> > The value representation (so setting initial 'range' handle positions) does
> > require some consideration. If the new microsyntax for value="" is limited
> > in scope to the client (one way server->client only) then it shouldn't pose
> > any problems.
> 
> Not having trivial round-tripping is a problem.

There is usually *no* round tripping in a typical server setup. 

The user defined values need to be stored in a different medium (usually database) and they would never be stored in a raw, comma-delimited form. Otherwise the items would not have been validated before being stored, you could not enforce item max/min lengths, and it would be impossible to query the dataset for individual entries. 

So, the server will *always* need to parse the syntax, and it will *always* need to generate the syntax. The alternate approach alleviates one of these steps, and the more complex and error prone one.

Consider the example of if we could markup values for 'range' or 'email' as discrete items, so in the same way that <select> does using <option>. If this were the case there would be no need for any delimiters. The browser would be able to take control of the user-input and validation, and ensure that the values are captured in discrete forms.

The problem with using delimiters, it is impossible to deduce what kind of error a user may have made. If validation is turned off and the following is recieved:

email=abc@example,com,def@example.com

How do you know if the user has tried entering 1, 2 or 3 email addresses?

The whole string is in error, but if these were discrete values i would be able to take more action based on a greater knowledge of what the user entered:

email=abc@example,com&email=def@example.com

This is a partially processable request. Whether the transaction is allowed or not isn't relevant, the process will be able to take more action than would otherwise be possible with a value bound in microsyntax.

> > [snip]
> > 
> > To me, that's pretty powerful UI.
> 
> It's certainly interesting theoretically. I'm not sure it's particularly
> useful. When are you going to actually be trading a range control for two
> number controls, or even a select control?

The other case is more compelling - you could trade 2 text controls or a select control for a range.

This makes migration/upgrade to HTML5 easier as the API might not need to be updated.

Also, i always consider the case where the API and the UI are controlled by different parties. Having flexibility allows the 3rd party UI to have complete freedom in UI choice when they will never be able to change the API.

> 
> The weirdness of "ranges=1&ranges=4&ranges=6&ranges=9" meaning "1..4 and
> 6..9" seems more bad than the substitutability with other controls seems
> good. But I agree that it's subjective.

It's just as possible to use unique names for controls, in which case the example might become a little less obscene:

"rangeA=1&rangeA=4&rangeB=6&rangeB=9"

> Firefox, Chrome and IE are all encoding commas.

Ah, indeed. Looks like for historical reasons that code point is unnecessarily encoded. Oh well.


> Yep, with the restriction to numbers there is no need for any escaping. I'm
> considering the potential for encoding user-string values, which is why the
> type="email" is a better examination.

If you want to change type=email multiple="", you should file a separate bug. But I think that it's likely too late, implementation(s?) have shipped.


> So my real concern is - what is the scope for comma-separated lists becoming
> the 'new' mechanism for encoding series through
> application/x-www-form-urlencoded?

Well, it would be a case-by-case basis. We've done it for e-mail; we're considering doing it for numbers. Seems reasonable to me to do it for numbers. It makes things work pretty neatly. I don't really see the problems you describe as being especially problematic, and there's problems with the other proposals as well. It's just a matter of picking the one that's least difficult.

Having multiple values in separate fields, like range.min=1&range.max=2, or having multiple values in the same field, as in range=1&range=2, would either mean changing how we set the value, or would mean the value isn't what the value="" attribute contains, both of which are big cans of worms.

The advantage of range=1,2 is that it fits in neatly with the current design, requires minimal work to handle on the server, and mostly works like the other <input> controls at the API level.


> > > The value representation (so setting initial 'range' handle positions) does
> > > require some consideration. If the new microsyntax for value="" is limited
> > > in scope to the client (one way server->client only) then it shouldn't pose
> > > any problems.
> > 
> > Not having trivial round-tripping is a problem.
> 
> There is usually *no* round tripping in a typical server setup. 

For now, yeah. One of the features that was in the old Web Forms 2.0 proposal before it got merged into the HTML spec was a round-tripping mechanism, though, and we might still need to find a good way to do that. <select> was a pain in the neck when it came to doing that last time. I'm skeptical about making that worse.


> The problem with using delimiters, it is impossible to deduce what kind of
> error a user may have made. If validation is turned off and the following is
> recieved:
> 
> email=abc@example,com,def@example.com
> 
> How do you know if the user has tried entering 1, 2 or 3 email addresses?

You don't. If you want to do something useful with the user's input, don't turn off the very validation that is required to make sure the user's input makes sense...


> > It's certainly interesting theoretically. I'm not sure it's particularly
> > useful. When are you going to actually be trading a range control for two
> > number controls, or even a select control?
> 
> The other case is more compelling - you could trade 2 text controls or a
> select control for a range.

Sure, but changing the server when you do that isn't hard.


> This makes migration/upgrade to HTML5 easier as the API might not need to be
> updated.
> 
> Also, i always consider the case where the API and the UI are controlled by
> different parties. Having flexibility allows the 3rd party UI to have
> complete freedom in UI choice when they will never be able to change the API.

Not _complete_ freedom. What if they want to replace it with a multi-choice <select> where you choose a range of options? Then it'll include more than two.

But in any case, with JavaScript you can trivially convert the input into a type=hidden field of whatever format you need for the server.

(In reply to Ian 'Hixie' Hickson from comment #27)
>
> > Yep, with the restriction to numbers there is no need for any escaping. I'm
> > considering the potential for encoding user-string values, which is why the
> > type="email" is a better examination.
> 
> If you want to change type=email multiple="", you should file a separate
> bug. But I think that it's likely too late, implementation(s?) have shipped.
> 

Understandable. That ship has already sailed.
 
 
> Having multiple values in separate fields, like range.min=1&range.max=2, or
> having multiple values in the same field, as in range=1&range=2, would
> either mean changing how we set the value, or would mean the value isn't
> what the value="" attribute contains, both of which are big cans of worms.

What i quite like is the way @files works, by providing access to an array. This seems like the simplest and least error prone:

var start = document.getElementById("ranges").values[0];
var end = document.getElementById("ranges").values[1];

document.getElementById("ranges").values[0] = 0;
document.getElementById("ranges").values[1] = 100;

Anything else will require string manipulation, for multiple values.

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.

> > > > The value representation (so setting initial 'range' handle positions) does
> > > > require some consideration. If the new microsyntax for value="" is limited
> > > > in scope to the client (one way server->client only) then it shouldn't pose
> > > > any problems.
> > > 
> > > Not having trivial round-tripping is a problem.
> > 
> > There is usually *no* round tripping in a typical server setup. 
> 
> For now, yeah. One of the features that was in the old Web Forms 2.0
> proposal before it got merged into the HTML spec was a round-tripping
> mechanism, though, and we might still need to find a good way to do that.
> <select> was a pain in the neck when it came to doing that last time. I'm
> skeptical about making that worse.
> 

I'm not sure what a round-tripping feature would entail. To me, the <select> model is the level of granularity you end up having to deal with. Layers built on top of this just have to be deconstructed.

It's usually a bad idea to be blindly storing user input and send back out as HTML, this is your common source of security holes.

> 
> > The problem with using delimiters, it is impossible to deduce what kind of
> > error a user may have made. If validation is turned off and the following is
> > recieved:
> > 
> > email=abc@example,com,def@example.com
> > 
> > How do you know if the user has tried entering 1, 2 or 3 email addresses?
> 
> You don't. If you want to do something useful with the user's input, don't
> turn off the very validation that is required to make sure the user's input
> makes sense...
> 

Sure, but also consider the case where we have a non-HTML client using the same API. 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.

This also highlights what is a fundamental point - as far as an API is concerned it is literally using form encoding as a data format. The client used to construct the data set is of no importance, be it a cutting-edge browser, a text-only browser, a programmatic client, curl or other command line tools.

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?

> 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.

Okay, so for the type="range" input i agree that the approach you've just outlined is most prudent from the current requirements.

The only further consideration i'd like is with regards to what future <input type="" multiple> might come up?

If there are new type="" which may contain user text and allow multiple values, then my argument is that this would be better served by the client splitting these values prior to encoding so that a new microformat is not needed to deal with user escaping. 

Otherwise, if you think there will be no extensions requiring series encoding from <input>, then the concerns are largely moot.

So, for example <input type="tel" multiple> would be a bad idea. 

OTOH, i think <select> has some great potential for collecting multiple values, but, of course, that can be looked at separately.

Comma-separated values wouldn't work for type=tel since a comma is a valid value in that field. Same with e.g. type=text or type=url. If we have a use case for multiple URLs in one field, we'd have to come up with some other way to submit the values, certainly.

Checked in as WHATWG revision r8435.
Check-in comment: <input type=range multiple min=0 value='25,75' max=100> for two-valued range controls
http://html5.org/tools/web-apps-tracker?from=8434&to=8435

TODO:
- Need to add examples.
- XXXX = be more explicit about conversion algorithms
- XXXXX = s/<em>s</em>/s/g

Checked in as WHATWG revision r8436.
Check-in comment: Move <input type=range> examples
http://html5.org/tools/web-apps-tracker?from=8435&to=8436

Checked in as WHATWG revision r8437.
Check-in comment: New <input type=range multiple> example
http://html5.org/tools/web-apps-tracker?from=8436&to=8437

Checked in as WHATWG revision r8438.
Check-in comment: Be more sensible with the emphasis on the 's' in 'values' for concept-fe-values
http://html5.org/tools/web-apps-tracker?from=8437&to=8438

Checked in as WHATWG revision r8439.
Check-in comment: Clean up some vague parts of the spec relating to form controls' numeric values to use the right algorithms
http://html5.org/tools/web-apps-tracker?from=8438&to=8439