Hacker News Reader

Comment by jaggederest | Hacker News Reader

Remember back in the old days when people used to concatenate images into imagemaps and specify the coordinates and dimensions? One image file for a whole site.

Same goes back when we could just load a single library from the Google public version (cough-jquery-cough) and then all the on-page JS was just in-tag handlers. Not that it was better but boy howdy was it faster to load.

View on HN

You're probably thinking of CSS sprites, if you mean only displaying a certain portion of the image file at a time. An image map is when you display the whole image file as-is, but have different clickable links at different coordinates/dimensions.

The former is specifically for reducing requests, while the latter is more about UX.

I'm actually conflating both, you're right. I'm thinking of sprite-ed CSS, but also the really really old style imagemap where the same image could be clickable in multiple areas for different purposes.

For what it's worth, I recall the CSS sprite technique being referred to as image mapping too.

Sure, it's different from the <map> element (which is officially an image map, as you say).

But it's effectively mapping out the sections of a large image that you care about and then using CSS to display parts of it

Yeah, I vaguely recall some usage like that by the same crowd that also thinks an "anchor" is specifically a fragment link that brings you to a certain element on the same page, when in reality the word applies to all <a> tags. Sort of a casual understanding of HTML among non-devs.

I'm sure it's due to lack of standardization on the early web, but the really wild thing to me is that there are both client-side and server-side image maps (both still specified in HTML5). With the former, the various regions of the image are defined within the HTML and more or less act like regular links. With the latter, the client sends the coordinates to the server and gets redirected, so the user has no idea which pixels correspond to which URL.

Google used css sprites for Google+. They cared a lot about speed, specially for the stream, with even some CSS constructs that were known to be slow were banned from use for rendering posts.

For css sprites, you could submit an image to a folder in the monorepo, and a couple of minutes later an automated system would update the image with all the sprites, and create constants that you could you in your templates/css to use the icons with the coordinates/size of the image.

Not just in the old days, if you ever need to target super slow devices with web tech this sort of optimisation is still needed. I've used Spritesmith (https://www.npmjs.com/package/spritesmith) to good effect, there are probably others too.

It's too bad ad tracking networks ruined shared JS hosting and CDNs for everyone. There's no cache benefit to it any more because browsers stopped sharing caches between sites for privacy reasons.

(As Deno shows, ESM imports make a lot of sense from CDN-like URLs again. It just won't perform well in the browser because there is no shared cache benefit.)

The original Space Jam (1996) site does this for navigation (and it still works fine): https://www.spacejam.com/1996/cmp/jamcentral/jamcentralframe...

I just checked, and no it doesn't. The icons in the navigation are separate .gif files.

edit to add: And this makes a large part of the load time (when not cached). Other than that, the largest part is the SSL handshake and the fact that the server seems to be a bit slow (WRT the fact that it serves static content; 200ms for dynamic stuff would be okay).

Still a lot faster than most of todays websites.

In fairness I would be completely not surprised to find out it's on the same hardware as the day it launched, and probably hosts a pile of other static sites besides.

Reply on news.ycombinator.com