[jonahx]

I read that but it still isn't clear to me.

What is the namespace in question that we're polluting?

Where do you draw the line? Eg, take something a simple as creating striped table rows. Is something like 'class="oddRow"' wrong, because technically that's an enum value -- the rows can be "odd" or "even". Should we instead write 'data-rowtype="odd"'?

Basically, I need to see some more examples to understand the distinction better.

[Nadya]

I've never understood separating by odd/even. Typically the people who do this only want to add styles to "alternate" rows. So I would use 'class="alternate"'.

>Basically, I need to see some more examples to understand the distinction better.

Personally I do it only for organizational purposes more than anything else. The "actual use cases" are a bit contrived if I'm being honest, at least for this example.

Let's say you have 5 photos on a page, each with different filters applied on different locations of the page. You want to allow users to normalize the page by selecting a single filter to apply to every photo.

I'm not a JS expert - but the first seems a lot easier to manipulate multiple images at once. A single check of img.dataset.filter instead of checking against an entire array of classes. (If there is a simpler way of checking the class example, I'm all ears.)

  <img src="/" data-filter="oldschool" class="medium"> //change to greyscale
  <img src="/" data-filter="fuchsia" class="large"> //change to greyscale
  <img src="/" class="large"> //not to be changed
  <img src="/" data-filter="1970" class="small"> //change to greyscale


  <img src="/" class="medium oldschool"> //change to greyscale
  <img src="/" class="large fuchsia"> //change to greyscale
  <img src="/" class="small"> //not to be changed
  <img src="/" class="small 1970"> //change to greyscale

[jonahx]

If you're saying your sole reason for doing this is to ease your javascript selection, I think that's a poor reason. If you have a serious dynamic javascript page of any complexity, you have should have a pure js model and your view should be updating off that, using react, mithril, or your own vanilla update function. Now, not everyone would agree with that, and there may be use cases where it's overkill, but in that case I still don't buy the argument, as you can just write a short helper function that makes things just as easy as selecting with dataset.

I don't think a fear of javascript should be driving decisions about markup. You should write your markup in the clearest, most semantic way possible, and let what are ultimately trivial js problems take care of themselves.

[Nadya]

>You should write your markup in the clearest, most semantic way possible

Semantically is exactly why data-* should be used instead of classes. But semantics often include a bit of extra work (adding a data-filter attribute instead of just throwing an extra class in the mix) and so people throw them aside all too often.

>I still don't buy the argument, as you can just write a short helper function that makes things just as easy as selecting with dataset.

So to avoid doing things the proper way you would write a helper function to get around a problem?

The CSS can be written both ways (you can use [data-filter="..."] as a selector). The difference is between using data-* or adding a class. The difference between the two comes down to semantics and in some niche scenarios the ability to easily change the value.

[jonahx]

All I'm saying is that so far the only tangible reason you've given is that it makes doing javascript selections easier. I'm not saying using data-* liberally is a bad idea, I'm saying that is a bad reason for it. You've also mentioned semantics, which would be a good reason, but I'm still unlcear what the semantic argument is. To use the stripe row example, 'class="alternateRow"' seems just as semantic as 'data-rowtype="alternate"'. If I'm still missing something, I'd like to learn more. Again, additional examples would help. Discussing this kind of thing in the abstract is a recipe for miscommunication.