

Show HN: Create css/html images that can't be blocked by email providers - dwwoelfel
http://www.imgtocss.com

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

------
JonLim
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!

~~~
dwwoelfel
_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

~~~
JonLim
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?

~~~
dwwoelfel
_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.

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

------
dwwoelfel
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?

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

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

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

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

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

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

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

