6 ms·

The Web Control HTML 5 Left Out

15 points by DanielBMarkham 16y ago

antimatter15 16y ago
Isn't this what HTML5's <input type="range"> is for?
- olalonde 16y ago
  Exactly, http://diveintohtml5.org/examples/input-type-range.html http://diveintohtml5.org/examples/input-type-range.html
Sephr 16y ago
How is this blatant ignorance getting so many upvotes? The author obviously didn't take any time to actually verify his claims.
- DanielBMarkham 16y ago
  I answered this over on the blog, but I'll repeat it here. The key factor is ranking items against one another, not simply having a numerical scale. Therefore the control should have multiple list items -- a slider list -- and not simply a slider. I also mentioned a slider grid. The control itself should contain the sliders, since they are all related to the same concept, just like a select has many options. Sorry if I wasn't clear enough. I am aware of the input range spec. You know, usually if you think somebody is stupid, there are only 3 possiblities: 1) they really are stupid, 2) you are the one that's stupid, or 3) you two are not communicating very well. I've found it's best to begin with "Help me to understand" because many times the answer is #2 or #3 and not #1.
  - Sephr 16y ago
    Your "slider list" concept isn't in HTML5 for the same reason there isn't a "checkbox list" that sets another checkbox to either checked, unchecked, or indeterminate depending on the state of all the checkboxes in the list. The way you worded your blog post, it sounds like you think that implementing a "slider list" would be unreasonably nontrivial with HTML5 <input type="range">. Why do you think this would be so hard? You're just updating range inputs' values when one of the other range input's values changes. I don't see the problem.
    - DanielBMarkham 16y ago
      The point is that semantically they are a unique concept, not that they would be hard to implement. I'm not going to argue it with you. I know about input range, I'm suggesting something else, and yes, there are many ways to accomplish this.
Groxx 16y ago
No. No. No no no no no no. There are frequently cases to combine sliders like this. But there are just as many examples where it's worthless to combine them in a linear fashion. If this were a standard, it'd mean non-linear combinations would be a break of that standard, frowned upon but ultimately required. Or browsers would have to implement combination-formula-X. Or you'd have to define a combination formula, if there even is a simple one (step functions?). Similarly, it can be replicated easily by JS. Want an actual list of related fields in a form? That's what <fieldset> is for. In addition, tag bloat is a decidedly bad thing.
- DanielBMarkham 16y ago
  You can collect data in a flat format or have the tags indicate how groups of linear data relate to one another. There are only so many combinations, and the data received is much richer than before. This is really a simple matter. Either collect in 1-dimensional format or collect data with more depth. If there's a need for the new format, it will eventually win out, whether it leads to "tag bloat" or not. (And believe me, we already have tag bloat running out the ass with HTML. I find your concern for more bloat difficult to address given the already existing state of the spec)
  - Groxx 16y ago
    Isn't the data still collected in a flat format? x=50%, y=25%, z=25%. They're all still needed to determine the values (ok, you can remove one). And yeah, I'm aware of existing tag bloat. But its existence is no reason to make it worse. edit: You'll also note that the humble bundle used zero-values to make non-changing sliders, and values grow / shrink related to their current value. Should these be standard? Should they not? How do you handle it, without JS, because it too has uses? (edit2: they also have an arguable "bug"; set one to 100%, and it forgets the ratios it had before, and makes them all the same. Standard? Not? All this will come up in a standards debate, so why not get it over with now?) I still vote fieldset + JS. This is a behavior, not a thing. And yes, radio buttons and selects are identical in that respect; I do think one shouldn't exist, as they're just behaviors of checkboxes. It seems to me to be more of a hold-over from non-JS days than anything else.

Isn't this what HTML5's <input type="range"> is for?

olalonde 16y ago
Exactly, http://diveintohtml5.org/examples/input-type-range.html http://diveintohtml5.org/examples/input-type-range.html

Sephr 16y ago

How is this blatant ignorance getting so many upvotes? The author obviously didn't take any time to actually verify his claims.

DanielBMarkham 16y ago
I answered this over on the blog, but I'll repeat it here. The key factor is ranking items against one another, not simply having a numerical scale. Therefore the control should have multiple list items -- a slider list -- and not simply a slider. I also mentioned a slider grid. The control itself should contain the sliders, since they are all related to the same concept, just like a select has many options. Sorry if I wasn't clear enough. I am aware of the input range spec. You know, usually if you think somebody is stupid, there are only 3 possiblities: 1) they really are stupid, 2) you are the one that's stupid, or 3) you two are not communicating very well. I've found it's best to begin with "Help me to understand" because many times the answer is #2 or #3 and not #1.
- Sephr 16y ago
  Your "slider list" concept isn't in HTML5 for the same reason there isn't a "checkbox list" that sets another checkbox to either checked, unchecked, or indeterminate depending on the state of all the checkboxes in the list. The way you worded your blog post, it sounds like you think that implementing a "slider list" would be unreasonably nontrivial with HTML5 <input type="range">. Why do you think this would be so hard? You're just updating range inputs' values when one of the other range input's values changes. I don't see the problem.
  - DanielBMarkham 16y ago
    The point is that semantically they are a unique concept, not that they would be hard to implement. I'm not going to argue it with you. I know about input range, I'm suggesting something else, and yes, there are many ways to accomplish this.

Groxx 16y ago

No. No. No no no no no no. There are frequently cases to combine sliders like this. But there are just as many examples where it's worthless to combine them in a linear fashion. If this were a standard, it'd mean non-linear combinations would be a break of that standard, frowned upon but ultimately required. Or browsers would have to implement combination-formula-X. Or you'd have to define a combination formula, if there even is a simple one (step functions?). Similarly, it can be replicated easily by JS. Want an actual list of related fields in a form? That's what <fieldset> is for. In addition, tag bloat is a decidedly bad thing.

DanielBMarkham 16y ago
You can collect data in a flat format or have the tags indicate how groups of linear data relate to one another. There are only so many combinations, and the data received is much richer than before. This is really a simple matter. Either collect in 1-dimensional format or collect data with more depth. If there's a need for the new format, it will eventually win out, whether it leads to "tag bloat" or not. (And believe me, we already have tag bloat running out the ass with HTML. I find your concern for more bloat difficult to address given the already existing state of the spec)
- Groxx 16y ago
  Isn't the data still collected in a flat format? x=50%, y=25%, z=25%. They're all still needed to determine the values (ok, you can remove one). And yeah, I'm aware of existing tag bloat. But its existence is no reason to make it worse. edit: You'll also note that the humble bundle used zero-values to make non-changing sliders, and values grow / shrink related to their current value. Should these be standard? Should they not? How do you handle it, without JS, because it too has uses? (edit2: they also have an arguable "bug"; set one to 100%, and it forgets the ratios it had before, and makes them all the same. Standard? Not? All this will come up in a standards debate, so why not get it over with now?) I still vote fieldset + JS. This is a behavior, not a thing. And yes, radio buttons and selects are identical in that respect; I do think one shouldn't exist, as they're just behaviors of checkboxes. It seems to me to be more of a hold-over from non-JS days than anything else.