No, it's been around since forever. Just not used terribly often.
> Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
It depends. Making a new request to fetch the image always has overhead. Whether that overhead is bigger or smaller than the overhead of base64-encoding the image depends on:
• file size (naturally)
• file compressibility: The difference isn't as pronounced after gzipping everything, especially if the source data is somewhat compressible
• protocol: http2 allows a correctly configured server to push attached data with the original request, so no second request is needed. Even without server push, http2's multiplexing will reduce the overhead drastically compared to plain HTTP1.1 or the worst case, HTTPS1.1 to a different domain. The latter requires a full TLS handshake, and that's what, >30kb data exchanged if you have more than one CA certificate in the chain? That's a lot of image data.
You forgot the most important factor: Whether you're reusing that image on a different page. Embedding images in the HTML is basically saving an HTTP request at the expense of not being able to cache the image separately from the HTML.
This seems like it should work, but have you ever tried it? Or, can you point me to some results of a test to show that it indeed caches the image embedded in the CSS?
The problem is that now it's going to be sent with every request. So it'll make the first page faster for the initial request, but slower in the long run.
No, it's been around since forever. Just not used terribly often.
> Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
It depends. Making a new request to fetch the image always has overhead. Whether that overhead is bigger or smaller than the overhead of base64-encoding the image depends on:
• file size (naturally)
• file compressibility: The difference isn't as pronounced after gzipping everything, especially if the source data is somewhat compressible
• protocol: http2 allows a correctly configured server to push attached data with the original request, so no second request is needed. Even without server push, http2's multiplexing will reduce the overhead drastically compared to plain HTTP1.1 or the worst case, HTTPS1.1 to a different domain. The latter requires a full TLS handshake, and that's what, >30kb data exchanged if you have more than one CA certificate in the chain? That's a lot of image data.