

The Web Control HTML 5 Left Out - DanielBMarkham
http://www.whattofix.com/blog/archives/2010/12/the-web-control.php

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

~~~
DanielBMarkham
I think this is a behavior-versus-structure question.

The behavior argument says that, given some js, these are just unique
collections of pre-existing concepts.

The structure argument says that this is something new semantically.

I'm a big believer in the structure argument. Let me explain:

Let's say I have a website where I ask the reader some questions. Rate the top
five books of last year. Sort your friends according to how good-looking you
think they are. Talk about how the best movies of 2010 affected each of your
major five emotions.

These are groups of relative rankings that belong together. The frameset
argument is the best counterargument (in my opinion), but even then, it's not
clear from a frameset that the items are related to each other and not just
stand-alone data grouped by topic.

As a consumer of the page, the graphics and whizbangs can easily help me enter
the data, no matter what the controls that are used. But as a content-scraper,
the type of 2-dimensional or 3-dimensional data that is really represented
here needs it's own tag. That's all I'm saying.

You can argue it the other way, sure. And we have too many tags, yes. But my
point is that this is a new concept that we haven't discussed before, one
which I think needs inclusion.

~~~
Groxx
I still don't see how this is 2D or 3D. They are very very strictly related,
both visually upon dragging and technically as they simply send back their
values (which is exactly 1D of data). Visually/semantically, I'd argue this
falls somewhere between 1 and 2 dimensions; they're so tightly bound, they
_are_ a single thing, you're just dividing it up. (Visually, a linear
relationship is probably better signalled by manipulating a pie chart than a
bunch of sliders.)

From a programming standpoint, all these are indistinguishable from numeric
fields. If they are related, they belong in a fieldset, and/or probably have a
naming scheme implemented in their IDs (slider_a_1, slider_a_2, etc). Screen
readers will have to be hinted anyway, probably by a chunk of text before it,
ie: for blind users. And there again we fall upon problems with non-linear
relationships between the sliders causing trouble if it's all in HTML.

The reason I argue for behavior is because HTML _is_ structure. CSS is its
display, and JS is its behavior. That's its _purpose_ ; any holdovers (<font>)
are just that - holdovers from before a better system-wide structure was
enforced. Thus, as this is merely a _behavior_ of a set of sliders, it belongs
in the JS layer.

Scrapers are doomed to have trouble with behavior anyway, as HTML has no
ability to define that clicking checkbox_1 causes textbox_5 to be prefixed by
"squish ". And it shouldn't. That's why we have JS.

~~~
DanielBMarkham
I think we're going to just disagree here.

I would think that the behavior is really irrelevant. As you say, you could do
the same thing with an interactive pie chart. The important thing is to be
able to capture the intent of the user, which is a structure of data -- no
matter what the appearance or behavior. In fact, since it doesn't matter what
the appearance or data is, that's a perfect reason why it should be a tag.

And that's not even getting into the grid concept. Rank your immediate family
members on how much you think they'd like the top 5 TV shows from 2010. Here
we have a very complex piece of data, all interrelated, and it belongs under
the same tag. The structure of the underlying data is fundamentally different
from other things.

But like I said, I don't think we're going to agree. I'm just happy you seem
to understand my point. The conversation starts, and that's always a good
thing.

~~~
Groxx
> _Rank your immediate family members on how much you think they'd like the
> top 5 TV shows from 2010._

ie, what's usually done with a large set of radio buttons, like in surveys? I
_hate_ those huge radio sets, but that's a usability / UI problem, not a
missing-tag problem. (specifically: just bind the frickin' number keys, and
auto-advance! 10x (or more) faster surveys, guaranteed. But nobody does this.)

But yeah, we probably will disagree. I can leave it here :)

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

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

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

~~~
olalonde
Exactly, <http://diveintohtml5.org/examples/input-type-range.html>

