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

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

Received on Sunday, 13 October 2013 21:12:25 UTC