[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 #19 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #18)
>
> > What about the possibilty of 'named' steps - so with the use of <option>
> > using a label instead of numeric value?
> 
> What's the use case?
> 

It really just opens up the control for ontological display and input, so when
the numeric value is of little (or lower) significance and would otherwise fail
to communicate with the user so aptly.

An example would be the 'ages of man', quoting from wikipedia['Ages_of_Man']:

"Anthropology and evolutionary biology recognize various periods/ages of Homo
(Man, the Human Genus) beginning with the invention of stone tools in the
Oldowan. These periods are grouped into Prehistory (subdivided into Lower,
Middle, and Upper Paleolithic, followed by Mesolithic and Neolithic) and
Recorded History (subdivided into Antiquity, the Middle Ages, and Modernity)."

The numerical year values for these is of little to no relevance to the
representation to the user, however almost every user would be able to relate
to a scale with these markers and be able to answer questions and provide input
based on the relativity within the markers.

This is the value of type="range", it allows for user selection within a
graphically depicted scale of relativity between or within the options.

> 
> > It would be better to retain the same conventions for Query/Form encoding
> > and avoid the syntax of value="" breaking out of HTML. The best reason for
> > this is so that APIs can remain the same when switching between different UI
> > controls, ie you should be able to swap an <input type="range"> for a
> > <select> with the same options and be able to interact with the same API.
> 
> I don't follow. Can you elaborate? How does this impact <input type=email
> multiple>, for example? (It uses the same syntax as I'm suggesting here.)
> 

The encoding for email is also undesirable for the same reason, i thought that
this was actually encoded using the same mechanism as <select>, where frequency
and order of parameters have significance within encoding.

The encoding structure of query/form encoding essentially imposes no
restriction on UI, as long as inputs are named and multiple values use the same
name. Breaking this design property would be unfortunate.


> > The big difference is no <optgroup> for grouping - maybe this could be added
> > as valid content for <datalist>? The ability to demarkate groups within
> > scales is quite valuable, for example in temperature: Cold, Warm, Hot.
> 
> This is getting pretty elaborate. At some point we have to draw a line and
> say "if you want a more elaborate control, use Web Components to make it
> yourself". I'm not sure which side of the line this suggestion should be on,
> though.
> 
> Can you give concrete examples of what your suggestion would look like?
> 

See above for the kind of use case i'm considering.

The scope for Web Components is good, but i don't see any real difference
whether the work is done as a component or as a 'built-in' control.

What is the scope for authors of Web Components to use native OS controls?
AFAIK, the native controls have the flexibility with which to build such a
multi-value control, but these would be outside the realm of Web Components.
This means either tailoring UI for each platform, or creating new generic
controls with images or styles.

The scope for CSS binding would be preferable through HTML controls.

> 
> > The multi-value email interface isn't really much of a UI control.
> 
> It's exclusively a UI control, no? I don't follow.
> 
> I don't really understand what a "list-building control" would be. Can you
> give an example of one? (I see two-point range controls all over the Web.)

They're more the kind of controls you would build using a programmable GUI. Web
Components can definitely fill the gap, but isn't there still a desire to
improve the basic set of controls? One thing which is missing for Web
Components is the ability to manipulate sub-element UI features.

The concept of a "list-building control" would be to provide a control which
allowed users to enter and edit a list of values - but as discrete items. The
method used for <input type="email" multiple> relys on parsing a user-string
and the use of comma delimiters. I expect this to be beyond most web users.

You see "editable lists" all over UIs, usually the OS Wifi manager has one. For
HTML it would allow the browser to take control of state prior to sending a
form. It's probably something that browsers could just implement for the
existing @multiple controls, maybe with a nice CSS switch.

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

Received on Tuesday, 8 October 2013 16:35:53 UTC