1. 6
  1.  

  2. 3

    I don’t know how anyone could come up with an idea to use background-image: as a substitute for <img>. I can see why people may use an improper way because the proper way is not well known or takes more work, but this one is neither.

    1. 4

      For a long, long time, if you had images that are only shown conditionally, and you wanted to avoid downloading them when they aren’t shown, it was the only way without using JS to inject the <img> tag dynamically. Still is, if you care about cross-browser support.

      1. 1

        IIRC Instagram does it with images in posts, probably as a weak attempt to prevent users from saving them (the usual context menu items for saving etc. don’t show up for background images). But yeah, it’s not something you’d just do accidentally.

        1. 2

          Yeah, I’ve seen that. No idea just whom they are trying to stop.

          I once found a minor vulnerability in a large(ish) blog hosting provider that was trying to do “copy protection” and avoid revealing too much by inserting “special” links to background-image:, but just removing some GET request parameters would give you the original high res image with all EXIF data intact. Not sure if they closed it or not.

      2. 1

        Some of these points could be considered good things, as well. For example if you have a large decorative image which serves no real purpose, then not being indexed or seen by screen readers is a good thing (of course, for many other uses the article is correct in pointing out that it can be bad).

        The performance issue is no different form using <img src="large_image.jpg">, and it’s not that hard to use responsive design with background-image (just like with <img> tags). I don’t see how it’s “really sticky”, as the article claims.

        The “bad for CDN” argument is, quite frankly, grasping at straws.