W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2013

[Bug 13154] WF3: Allow two handles on input type="range", like this: http://jqueryui.com/demos/slider/#range

From: <bugzilla@jessica.w3.org>
Date: Thu, 10 Oct 2013 15:42:30 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-13154-2486-Yq7zHyFJmi@http.www.w3.org/Bugs/Public/>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:44 UTC