Show HN: Create css/html images that can't be blocked by email providers | Hacker News Reader

Show HN: Create css/html images that can't be blocked by email providers

imgtocss.com

11 pointsdwwoelfel14 comments

I was just going to say I don't see any practical use-case, but you outlined one I didn't think of. One problem I foresee is the cross-email compatibility problems. It's a magnitude worse than browsers. This problem is obviously extenuated by the fact that misalignment could produce unrecognizable images. Assuming the technical side is rock solid, I could see people using this for logos in their email signatures along with social icons. I still don't see many people paying for this, much less understanding it. I also hate seeing company logos and facebook icons in email signatures since I just think it's useless and annoying.

Hey,

This is pretty damned useful! I'm the Product Manager of PostageApp (http://www.postageapp.com), we deal with outbound transactional email, and I have to say, this is probably a godsend for our clients.

The only problem I can see is the significant size increase in emails - transactional emails need to get to the recipient as soon as possible. Saving the Firefox icon as HTML/CSS was about 647KB in TextEdit as a plain text file!

That would be my only reservation for using it.

REALLY love the idea though. Great work!

REALLY love the idea though. Great work!

Thanks! That's really nice to read.

The only problem I can see is the significant size increase in emails

One of the big contributors to the size is the inline CSS, which is required if the images are going to be included in emails. That said, there is alot of work that can be done on optimization.

Right now I use a list with ~pixel-high items and paragraphs. It makes it easy to represent the image in html, but I'm not so sure that it's the most efficient way. Tables or divs might have a smaller footprint, but I haven't had a chance to investigate.

It's potentially a very interesting problem. My analysis professor told me that he likes image processing because it's one of the rare fields where you can apply the more abstract concepts.

Unfortunately, the prospect for making money off of this thing is pretty bleak. Newsletter publishers could be my biggest customers, but they like external images for tracking purposes. Right now, I'm waiting to see if it gets traction before I do any more work on it

If you could make the output size much more manageable, and have it actually be usable for larger images, I think newsletter publishers would love the hell out of this. The only external image I can think of that they would want for tracking is the one they use for open tracking, otherwise all other images are fair game, AFAIK.

Definitely something that I would love to keep tabs on if you do continue to develop it, do you have a github repo I can watch?

do you have a github repo I can watch?

https://github.com/dwwoelfel

My github repo is pretty barren. I probably won't put any updates there.

However, I have your email from your profile. If I make a decent improvement to the output size, I'll send you an email. I won't forget. I put a reminder in my gmail drafts folder and my calender prompts me to check it once a month.

You have me more excited about this then I was when I released the app, but I'm still not certain that a market exists. My hypothesis is that the people who make the email newsletters include extra external images on purpose so that the recipient will think he's missing something. Then he'll be motivated to click the "display all images from this sender" link, enabling the tracking image in the process.

Perhaps that is what happens, and it may even be true for transactional mail, but having icons and small images show up without having to click that button seems to be much better for the UX.

The tracking image is wildly inaccurate anyway, but whatever, that's just my opinion.

I made this because I needed to include a few small images into emails I'm sending for a separate project. I didn't want to annoy the user with the "allow images from this sender" message, so I needed them to be pure html/css. I couldn't find a tool that would make the conversion with inline css, so I made one myself.

It can't handle large images because the css is inline, but that's the trade-off for being able to email them.

Can you think of anyone who would pay for this? Is there a feature I could add that would make this worth paying for?

One cool thing is that a converted transparent PNG will display properly in IE 6, even though the original doesn't:

http://imgur.com/XA6OE

Is there a reason you need to involve css here? what's wrong with just embedding a data: url inside the html?

Are you sure that won't be removed by the email client?

Email clients avoiding going out to fetch external images, because that may be used to track user reading (when the image has been fetched, you know that the email was displayed on screen, so you can code every email you send with a unique URL, and get a date & time & ip & operating system etc. signature for every time it is read).

They have no problem with inlined images, whether that is css or data: url. Thunderbird (for sure), and Gmail (I think) will display data: image urls inline; not sure about other clients.

I tested it in a few web-mail clients. The data: uri images get blocked in gmail, yahoo, hotmail, and aol web-clients. I think that they just indiscriminately block "img" tags.

The css images, on the other hand, continue to display even when I put the emails into the spam folder.

Edit: All of the web-clients knew how to display the data:uri image.

I'm confused. So, data: image uris work in web clients?

Sorry, I wasn't very clear.

The web client knows how to display the images, but it blocks them if it doesn't trust the sender.

Basically, they work exactly the same as regular old external images.

Reply on news.ycombinator.com