[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 #26 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #25)
> > It seems the specification and implementation do not always match :)
> 
> What doesn't match? Who's escaping a comma?

Firefox, Chrome and IE are all encoding commas. This form:

<form method="GET" action="http://www.example.com">
    <input name="email" type="email" value="abc@example.com,def@example.com"
multiple>
    <button type="submit">Submit</button>
<form>

All resolve to the same URL:

http://www.example.com/?email=abc%40example.com%2Cdef%40example.com

> > 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.
>

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.

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?

The comma-seperated list is more a data pattern than a syntax. The most popular
encoding using this form of syntax is the CSV format which uses quotes for
escaping. 

I'm concerned that this might be the only mechanism left for being able to
support series of user-strings.

> 
> 
> > 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. 

The user defined values need to be stored in a different medium (usually
database) and they would never be stored in a raw, comma-delimited form.
Otherwise the items would not have been validated before being stored, you
could not enforce item max/min lengths, and it would be impossible to query the
dataset for individual entries. 

So, the server will *always* need to parse the syntax, and it will *always*
need to generate the syntax. The alternate approach alleviates one of these
steps, and the more complex and error prone one.

Consider the example of if we could markup values for 'range' or 'email' as
discrete items, so in the same way that <select> does using <option>. If this
were the case there would be no need for any delimiters. The browser would be
able to take control of the user-input and validation, and ensure that the
values are captured in discrete forms.

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?

The whole string is in error, but if these were discrete values i would be able
to take more action based on a greater knowledge of what the user entered:

email=abc@example,com&email=def@example.com

This is a partially processable request. Whether the transaction is allowed or
not isn't relevant, the process will be able to take more action than would
otherwise be possible with a value bound in microsyntax.

> > [snip]
> > 
> > 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 other case is more compelling - you could trade 2 text controls or a select
control for a range.

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.

> 
> 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.

It's just as possible to use unique names for controls, in which case the
example might become a little less obscene:

"rangeA=1&rangeA=4&rangeB=6&rangeB=9"

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

Received on Monday, 14 October 2013 16:37:07 UTC