3 ms·

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 concept

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 16y ago
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 16y ago
  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 16y ago
    >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 :)

Groxx 16y ago

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 16y ago
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 16y ago
  >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 :)