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.
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.
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.
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 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.
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 played with the same kind of hack back in the nineties and then in JavaScript+HTML table in 2001.
http://plea.se/me/galen_man.htm (it was hideously slow to scroll down back then)
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.
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.
- 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.
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.
The output can be made much smaller if you just encode (and possibly compress) the bitmap data as a (base64?) string in JavaScript, then use a little JavaScript to actually render it at runtime. You can then have all sorts of optimizations - render using CSS data URIs or canvas where available, for example, to make it look better on iPads and other high-DPI devices.
It was more of an experiment than anything else. Certainly not too practical. :) One nice thing is that you can easily "scale" the image by changing the size of the table cells.
Both this and similar attempts in CSS (http://www.imgtocss.com/) look really bad on my iPad as I zoom in and out, there are little grey anti-alias lines all over the "image". Totally unusable.
The graphic is unusable - i.e. don't use it. And it's not a bug - HTML leaves such anti-aliasing rules undefined, which is why it's a bad idea to try this sort of practice, and why CSS "graphics" nearly always look crappy.
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.
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.
I did something like this for a government project 6 years ago. We had to email a status update (HTML) and we couldn't have any images so we found a site that turned images into tables.
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 brings back great memories, it is how I used to do tiny round corners back in the day, then I remember gmail came with a smarter way using divs and margins.
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.
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.
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!
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.