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

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

Received on Thursday, 10 October 2013 21:02:28 UTC