- From: <bugzilla@jessica.w3.org>
- Date: Thu, 10 Oct 2013 15:42:30 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13154 --- Comment #22 from Cameron Jones <cmhjones@gmail.com> --- (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'? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 10 October 2013 15:42:36 UTC