Hacker News new | past | comments | ask | show | jobs | submit login
CSSgram: CSS library for Instagram filters (github.com)
176 points by gotchange on Oct 27, 2015 | hide | past | web | favorite | 40 comments

That post didn't catch attention. I wonder why?

I wonder if Github posts catch more attention than web site posts. Funny since in the comments, someone asked for a demo, which is the website I submitted. Oh well.

However, let's not lose focus of the fact that while it's fun to watch them, you really cannot spend these internet points we earn here.

Probably because HN <3s the word library a bit too much.

Yeah, I'm in agreement with previous posters. "Library" + "Github" equals more attention. This is somewhat of a lesson in crafting a headline here.

Probably I'm just left behind in terms of front-end stuff and just need to catch up, while for everyone else "it's not a big deal", but for me it's really impressive. I mean, I understand that instagram filters are not a rocket science, but CSS filters, really? In real time, just like that?

And the whole github profile is pretty nice, I gotta say. Nothing special, but inspiring somehow.

Nice! I made a similar thing last year to play around with CSS filters:


It's not exactly an editor as the original image is not 'edited'. I don't know why I decided to call it that :) Filter is the right term.

If anyone interested in learning how I built it: (my guest post on SitePoint about it)


I honestly could use this for something I'm working on at work. Thanks!

What a great contribution to the open source space! We'll to get our hands dirty with this library! Thanks! :-)

Nice! Meanwhile Instagram added new filters: Clarendon, ludwig, moon etc. Would love to have a guide on how to recreate filters with CSS if we want to have those new filters as well

Hey! This is the library author :) I wrote a bunch of blog posts about blend modes, filters, and gradients on http://una.im if you wanted to learn more about them. I also did a conference talk on the subject (its linked in the page for CSSgram)

Thanks for checking it out :)

Very cool! Wondering if there are any performance implications?

Too bad there's no IE support, but defaulting to a regular image isn't a big deal.

Nice! Note that using SVG one can pretty much create any kind of filter, sure it's not as simple as adding a class attribute and I'm not sure about transitions (SVG can be animated though).

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

Why on earth would someone want to apply CSS via data attributes instead of classes? That's the kind of statement you need to justify.

The filters are a collection of the same type of things. Therefore its more akin to filterAttr = filterEnumVal[autumn,auburn,sunnydale,cheezit,etc..]

Instead of polluting the CSS namespace, it's much more apt to use a data-instafilter="[val]" property.

Well goldenkey answered perfectly for me here.

Structural purposes.

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"
The CSS would need slight changes, accordingly:

  img[data-filter="filter_type"] { /* styles */ }
[0] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Usin...

Why does everyone here seem to be assuming the primary use-case is some kind of interactive on/off filter?

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.

There are better ways to accomplish this if you just want a fixed filter... such as displaying the image with the filter already applied instead of relying on user's (non-IE) browser to do it. Unless you plan to not support IE users at all, which is a rather big "don't do this" for front-end dev.

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.

"Better" from an infrastructural perspective maybe, for performance reasons, etc. but for many people quickly dropping in a bit of frontend magic is very often opted for in practice over more performant server-side setups.

As for not supporting IE users at all, it's a filter - you don't lose image display.

Hm, this is an interesting case where stylesheet design principles and application logic aren't so loosely coupled.

The data attributes almost seem to be a way to invoke CSS styles as functions themselves.

The main difference is that using classes, is misusing them. Because enum values as classes pollutes the namespace.

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.'

Interesting, thanks for pointing this out.

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?

goldenkey explained this well in their response.


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.

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

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.

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

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.

> classList is hacky

How so? I don't think that it's in anyway hackier than its sister dataset.

I don't understand that comment either, but it might be the lack of classList support in earlier IE versions without a polyfill.

I hate moving/changing/adding classes with Javascript. classList is hacky.

...in what way?

I think Una turned issues off on her repos...she's getting issue spam:


Woah. I wonder if you can notify github about such behavior and if something would be done about that. Because that's really not pretty.

Apparently she (and all those watching the project) got spammed so she had to shut down issues - https://twitter.com/Una/status/659128221292605440

No demo?!

there's a link at the top of the repo page: http://una.im/CSSgram/

Oh yes thanks, I scrolled down to read, then ctrl+F for "demo" and missed it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact