[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 #27 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
> 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.

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

Received on Monday, 14 October 2013 18:43:18 UTC