- From: <bugzilla@jessica.w3.org>
- Date: Mon, 07 Oct 2013 15:37:19 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13154 --- Comment #17 from Cameron Jones <cmhjones@gmail.com> --- (In reply to Ian 'Hixie' Hickson from comment #16) > There's no technical reason we can't do: > > <input type=range multiple min=0 max=10 value="2,5"> > > ...or some such, if we're ok with it. We'd probably have to add two new IDL > attributes to replace valueAsNumber for this specific case Is value="2,5" a new micro-syntax? What about the possibilty of 'named' steps - so with the use of <option> using a label instead of numeric value? This implies that @value syntax (and even @min and @max for single-value) need to have discrete strings and a form of escaping, otherwise they would be pointers referring to a position within a list. > ... and the submitted value would have to be parsed (split on comma) on the > server, but those aren't insurmountable problems. 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. Otherwise there is a coupling of UI to API, visa-versa. > We already use <option> for tick marks on <input type=range> using the > list="" attribute, so we'd get that for "free" here too. 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. I thought that <select> was using either <option> or <datalist>, but that wouldn't make any sense unless <select> were editable. > Maybe this isn't as bad as I initially thought. It's a bit weird, but it's > actually the same as <input type=email multiple>, really. The multi-value email interface isn't really much of a UI control. It seems more for validation. I'd probably prefer to have some kind of "list-building" interface control which was a bit like an editable select box with insert/delete controls. I guess there's no reason something like that could't be made from the current definition with @multiple switch. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 7 October 2013 15:37:21 UTC