They should really be in data-attributes instead of classes imo.
And not having issues on Github is quite a weird, especially when the first rule for contributing is:
> Create an issue
Personally, I hate moving/changing/adding classes with Javascript. classList is hacky. Stuff like this is exactly what data-attributes are for. [0]
img.dataset.filter // "instagram filter type"
img[data-filter="filter_type"] { /* styles */ }
The data attributes almost seem to be a way to invoke CSS styles as functions themselves.
Enum values should map to attribute values. It makes logical sense. Attribute values don't go into a namespace. They just exist as things to query by.
It is possible many CSS engines optimize this fact. By not caching attribute values until there is a selector that uses them. Classes on the other hand are inherently saying 'I will query by this at a later time - I give no hints as to whether it is mutually exclusive with other class values. I merely have a list of class values which apply.'
How so? I don't think that it's in anyway hackier than its sister dataset.
I am still unclear, though, how you draw the line, in general, between things that belong in dataset and things that belong in standard classes?
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.
>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 greyscaleI 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.
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.
Surely the common setting for this to be applied is in a web page where the author/photographer/designer has already selected a fixed filter and the visitor is just looking at it applied. A UI allowing someone to toggle or select filters on an image is the exceptional case here.
So a UI to select filters to apply in FF/Chrome as progressive enhancement seems to be the best use case I can see for this, if I can be frank.
As for not supporting IE users at all, it's a filter - you don't lose image display.
...in what way?
Instead of polluting the CSS namespace, it's much more apt to use a data-instafilter="[val]" property.