64 comments

[ 3.4 ms ] story [ 131 ms ] thread
This is not an HTML table. It's an error establishing a database connection.
This is not an error establishing a database connection. It's an header1 tag.
workin' on it...
Do you have a mirror anywhere? in the past people would just put a github gist or something.
Try hitting "CTRL +" to zoom and it will bring your system to a halt.

Interesting effect though. It's what some crafty devs are doing to get around image blocking in modern email clients, like here: http://www.campaignmonitor.com/blog/post/3642/email-with-pix...

What browser/system? On Linux with Firefox 14.0.1 I had no problem zooming in.
Chrome latest on a fairly high end Windows machine.
For anyone too lazy to use web inspector: It's 100x40, so effectively a 100-row 4000-cell table.
I just replaced it with 50x20... should help speed things along.
It does render a lot faster now.

Are you using any plugins like W3TotalCache for WordPress? I'd recommend it, if only until this story falls off the frontpage.

idea for improvement: Use colspan to cut down on the number of cells
also consider using css classes as a colour palette
More improvement: Use that with "background: linear-gradient(...)" and you've got the makings of a truly baroque image format.
With several backgrounds like that maybe you can build up a Fourier representation of a small image

http://upload.wikimedia.org/wikipedia/commons/2/23/Dctjpeg.p...

Right, that's what I kind of had in mind. It'd be tough to combine them to get a "checkerboard" result, though, since you can only specify them along a single axis. You might be able to do something fancy with multiple overlapping backgrounds, though.
Cool idea. :-)

Clearly not aiming for smallest representation though. ;-) https://github.com/discountgenius/pixeltable/blob/master/pix...

First off, the p class should just go on the table instead of every pixel. Then use a descendant combinator "table.p td".

Next, I would probably index the image (like a gif) down to a few hundred colors, create a style for each, and then use a base62 (0-9A-Za-z) representation of the index as a class name.

You can further reduce the content size if you can use ids instead of classes, but even with classes, you don't need the quotes around the class names.

There are probably more ways as well, like using a fixed-width div container and filling it with floating <b> tags instead of using a table.

Some more optimizations that come to mind:

- You could also calculate which color is the most used color in the image, and make that the background color of the table. If 10% of the image have that color (for example white, in a logo) you could leave the class or id out of the table for these pixels.

- if two or more columns have the same color in a row, one could add a colspan. Since the word is rather long, it makes only sense from 2 columns onward, I guess, but if, say, the first 100 pixels of the image portrait a white line, instead of having 100 x '<td id='ff'></td>' you'd have <td id='ff' colspan=100></td'.

- The same could be done with column for colspan, albeit a bit more difficult.

- If there're certain pixel color patterns that appear throughout the image (say a white pixel next to a black pixel) one could create a css .before and .after rule for these, that defines the pattern for one td, making the 2. unnecessary.

There's probably more.

I am curious, why not just use a data-uri and inline the image?
I don't mean to be mean, but someone who is just now thinking of converting an image to a table in 2012 probably doesn't know about data URIs.
I'm guessing the forum simply blocks all img tags
If you have javascript and don't worry about supporting IE 7, you can possibly defeat any kind of blocking logic that looks for the '<img' tag.
I played with something like this a while ago. Interestingly, I found that my gzip'd table html had a smaller file size than the source png, even after png crush. Though I suspect I was doing something wrong to get a result like that.

http://disruption.ca/code/png2html/

perhaps your resolution when converted is slightly smaller than the original, and thus, after compression, the size is smaller than the source?
I'm confident that resolutions are identical. I am using colspan and rowspan to do two dimensional run-length encoding, which may account for the difference. Even so, it's a surprising result.
I remember reading that Google did this for their checkout shopping cart image since it meant faster loading times. At a scale like Google's where they can measure the impact on the bottom line, something as ridiculous as this can make sense.
I think HN moderators could have a pause button for top threads like these. If there is a problem for the baby tech thing, just put the thread on pause for sometime [vanish] and bring the thread back online [reappear] the moment DB error/any error is sorted out.

Quite often we see connection errors or other problems for these new cool things, and the guys behind it lose a lot of crucial steam.

If it's a personal blog, maybe submitters should just use a coral cache link or something. hard for us commenters to contribute anything useful if we can't see it!
A more complex, but perhaps better solution, UI-wise: HN could just poke Coral/Google/whoever to cache any site that hits the front page, so there'll be a guaranteed fallback--and then switch the link out for the fallback when you press your hypothetical pause button. (The only problem being that this works for web pages, but won't do much to help web apps.)
>switch the link out for the fallback when you press your hypothetical pause button //

I think this interferes too much. An icon indicating that the site is having problems and a second link to a cache would, IMO, be preferable. Such caches in my country are almost certainly copyright infringing if used to redirect users away from the original source - with this modified solution the user chooses. TBH it's probably still strictly a copyright infringement but the situation looks more ethical.

Of course we know that HN won't implement something like this.

My custom CSS makes it disappear (while normal images stay). Web developers should keep accessibility features of browsers in mind when coming up with ideas like these.
This may be horribly off-topic, but your link to your old tripod site made me nostalgic for my own preteen tripod/angelfire/geocities days. They don't seem to be live anymore, nor can I find them on the Internet Archive WayBack machine. I suppose they are gone for good, but do you have any other suggestions for trying to find them? I heard there was a huge dump of GeoCities available as a torrent, but I don't recall that I ever used my GeoCites page as much as the others.
HTML table is one of the Gimp's built-in output formats.
I did this, too: http://www.imgtocss.com. It was one of my first webapps.

I think that my implementation is about as compact as possible while still working in all email clients. Outlook has an odd limit on the number of columns.

Here's the HN thread where I debuted the thing: http://news.ycombinator.com/item?id=2491438

It hasn't been a huge money-maker for me. I've got one subscriber at $30 a month and every now and then someone gives me $5 for a few conversions. It costs me $3 a week to run on Google App Engine.

> Outlook has an odd limit on the number of columns.

I've had problems with IE itself in the ~<1024 cells range (it was about 900~1000 IIRC. More cells, and it simply drops either the extra cells, or the table itself, I can't recall). I seem to remember the value was actually round in some way.

Use case was a horizontally scrollable day-based timeline, and the user decided to look at more than three years worth of data, which worked just fine everywhere but in IE.

Three things:

1. Google used to do this to reduce request overhead when displaying Google Checkout icon in search results.

2. Data URIs essentially render this pointless for newer browsers

3. I've tried using a lot of divs and animating them to simulate a canvas. Very slow. Do not try.

Data URIs essentially render this pointless for newer browsers

He mentions bypassing image filters in emails as one of the use cases. Data URIs still require an img tag, so they'll be blocked by the email client.

Newer email clients should allow them, though.
When I checked last year, gmail was indiscriminately blocking anything with an img tag.
I think I remember someone doing this in the late 90ies. It's a cute idea and a fun hack, but doesn't have a lot of practical applications.
I used html tables as a poor man's pixel grid canvas for doing some very simple javascript software 3d object rendering animations many many years ago. Unfortunately, it seems I've lost the source.
A hack trying to leverage current system without real merits
I finally discovered a somewhat useful reason to resurrect my childhood idea. My web store, BTC Gear has bought up some ad space on the Bitcoin Talk forums which allow small, image-free HTML ads with CSS styling.

To me this sounds dodgy. The whole point about these ads is that they are supposed to be unintrusive and not have images.

Abusing HTML to re-inject what is in effect just that, images, sounds like blatant violation of TOS. This can cause bad rep for the ad-provider who has promised site-owners image-free ads, and bad rep for site-owners who has promised end-users (or maybe VIP members) an ad-free or ad-limited experience.

While this may technically be a "cool" (yet obvious) hack, the reasons stated for doing them are wrong on every single level. I wouldn't want to encourage this.

The forum moderator uploads each ad manually and explicitly states that ads can be rejected for being "too annoying." Although I could see how this would be a backdoor in some situations, the site owner will not upload our ad unless he's OK with it.
Very interesting idea -- The idea that one can bypass image filters (say at a network DPI level) would be useful, until this technique is discovered and detectable.

What about some client-side js that read png/jpeg and converted to a colored tabular pixel array, makes it more difficult for a naive user to 'copy-paste' image.

Theoretically, SVGs should have exactly the same benefits (e.g. load times) without any of the "hackiness".