[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 #28 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #27)
>
> > 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.
> 
> If you want to change type=email multiple="", you should file a separate
> bug. But I think that it's likely too late, implementation(s?) have shipped.
> 

Understandable. That ship has already sailed.


> Having multiple values in separate fields, like range.min=1&range.max=2, or
> having multiple values in the same field, as in range=1&range=2, would
> either mean changing how we set the value, or would mean the value isn't
> what the value="" attribute contains, both of which are big cans of worms.

What i quite like is the way @files works, by providing access to an array.
This seems like the simplest and least error prone:

var start = document.getElementById("ranges").values[0];
var end = document.getElementById("ranges").values[1];

document.getElementById("ranges").values[0] = 0;
document.getElementById("ranges").values[1] = 100;

Anything else will require string manipulation, for multiple values.

IFF the value series is not represented as a microsyntax within value="", then
there is no parity between HTML and form encoding to maintain. Both would
define the format which best fits their model for the scope of use.

Bridging HTML formats and form encoding is blending two distinct uses into the
same model.

> > > > 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. 
> 
> For now, yeah. One of the features that was in the old Web Forms 2.0
> proposal before it got merged into the HTML spec was a round-tripping
> mechanism, though, and we might still need to find a good way to do that.
> <select> was a pain in the neck when it came to doing that last time. I'm
> skeptical about making that worse.
> 

I'm not sure what a round-tripping feature would entail. To me, the <select>
model is the level of granularity you end up having to deal with. Layers built
on top of this just have to be deconstructed.

It's usually a bad idea to be blindly storing user input and send back out as
HTML, this is your common source of security holes.

> 
> > 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?
> 
> You don't. If you want to do something useful with the user's input, don't
> turn off the very validation that is required to make sure the user's input
> makes sense...
> 

Sure, but also consider the case where we have a non-HTML client using the same
API. We have to provide the same level of error reporting as for any other
user. Mandating that clients must provide input in discrete parameters ensures
that a generic API can provide the information back to clients in a piece-meal
fashion.

This also highlights what is a fundamental point - as far as an API is
concerned it is literally using form encoding as a data format. The client used
to construct the data set is of no importance, be it a cutting-edge browser, a
text-only browser, a programmatic client, curl or other command line tools.

To say that all of these clients must know and construct a new specific syntax
for a particular parameter imposes otherwise avoidable constraints.

These clients may be served an entirely different media type than HTML. Why
should HTML impose it's internal data formats onto other clients?

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

Received on Tuesday, 15 October 2013 16:12:42 UTC