2 ms·

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 da

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.
- DanielBMarkham 16y ago
  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.
      - 16y ago

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.

DanielBMarkham 16y ago
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.
    - 16y ago