This problem would also be solved by actual widespread support for SVG or something similar. With vector rendering, we can just let the client handle any subpixel business.

When you're trying to communicate a handful of pixels of information why send the entire (complex) vector file?

For the exact reason I stated: portability. Bitmaps are good for some things, but logos aren't really one of them.

But in this case we're talking about a logo that's going to appear a few pixels wide on all clients - there's really no incentive to add the overhead of a large file transmission (not to mention the requisite client-side processing).

In a everything-is-made-of-marshmallows ideal world, yeah, bandwidth is not an issue, nor is site load time, and client-side CPUs and RAM are infinite. In that world I too would transmit everything, no matter how minor, in vector form. We do not live in that world.

The YouTube favicon.ico is 318 bytes long. I threw together a crappy SVG mockup of the logo with absolutely no size optimization, and it clocks in at 429 bytes. When gzipped, they clock in at 233 and 248 bytes, respectively.

If you're worried more about the 15 bytes than about compatibility, then just have the logo scale up and use it for your main logo as well; it should actually save bandwidth that way.

Something that people often forget when dissing vectors and SVG in particular, is that they're _scalable_ - so you can use the same version everywhere. So, you send the logo SVG once, and you could use it for the main logo on the homepage, smaller footer logo on the rest of the site AND for the favicon, because it'll scale. Browser just downloads one SVG file once, instead of 3 different bitmaps. Obviously, this is in everything-is-made-of-marshmallows ideal world where Internet Explorer doesn't exist, but hey.

Technically SVG is scalable, but not in practice. Small icons need different design than large icons, and SVG doesn't solve that. Look at fonts, they have hinting system to indicate changes for different sizes. Without similar system, SVG can't produce icons that truly are scalable. It's especially important in small icons like favicon(16x16px) which I believe will be hand drawn for long time.

I think that Apple does resolution independent icons by embedding several bitmap versions with a vector version in their icon files. That's the way to go in desktop applications, but similar system would produce too much overhead without significant advantage in web.

True, although the hinting is mostly just used for when things get tiny. SVG works well from sizes from 32x32 up to infinity, which is fairly impressive, I think.

Why should anyone be telling me what format decisions I make in the end? If SVG is right for the job, I'll use SVG. If it isn't, I won't. We do have a choice, here.

Why not just reference a larger .png file in your HTML and let the browser deal with the specifics?

Independent of subpixel rendering issues, a good iconographer will tweak an icon at different sizes, even if they originally created it from a vector. Pixels do matter.

The bigger download would slow things down.

Not sure if image resizing could even make sensible use of sub-pixel rendering...

A 32x32 PNG would not be that much larger than a 16x16.

Another solution is to put the pixel order in the html header.

A smart browser showing the same page spread over two different monitors would then download twice as much, but everyone else would be happy.

No. HTML has no reason to specify information that has meaning to display technologies we happen to use now. Subpixel anti-aliasing is based on current LCD technology and doesn't even deal with newer approaches such as the PixelQi screen that equips the OLPC laptop (9 subpixels per pixel).

This solution would pollute the HTML information space.