Overall the advice is pretty bad and the article doesn't even follow its own advice. Instead we get this crap that doesn't care about accessibility and loads images with javascript (3rd party javascript!):
Author here. What advice is "bad" in your estimation?
As for not following my own advice, that's not quite right. I'm using picture and img tags rather than div's with CSS background-image, which is the main thrust of the article.
I'm also using srcset for performance, and webp as a progressive enhancement for browsers that support it.
The only thing I'm not doing is using the new loading="lazy" because the website was creating long before the article.
Efficiency/SEO sure but what makes this bad for accessibility? It's a standard <img> with alt text, does it matter for accessibility where the final pixel data comes from?
The article criticizes the abuse of background-image as a cheapass replacement for the img or picture tags that should be used for "content images".
It's not a controversial point of view: background-image has always been intended to be purely ornamental (for cases in which background-color doesn't look good enough) and there's no reason to worry about "semantic" features like alt text (a blind or text-only user doesn't care for how the page background is painted).
What perverted line of thought led to the apparently widespread abuse of background-image for content?
CSS sprites, as suggested in other comments, are a significant hack that might have set an example but true content (rather than icons) in background-image is on a different level and requires additional explanation.
I would suspect the main reasons are the possibility to format images are greater for background-image than img. Functionality like background-size cover or contain in a background image are difficult to mimic with an img tag.
`img` tags are (or partially were, with the recent introduction of the object-fit property) significantly harder to properly style and position. Contrary to your argument, achieving certain layouts with `img` tags required significant style hacks, while using `div`s with with a background-image has always been straightforward.
One explanation is that it's more difficult for non technical users to copy the image or url. Which worries many publishers. Eg people using their images/content without consent. DRM is a thing.
"...background-image has always been intended to be purely ornamental..." That works for purely ornamental images, especially if the browser includes the ability to disable the background-image command (I wrote a document with ideas how to make a better web browser program, and one of the ideas is "meta-CSS", which is capable of doing this; the privileged CSS priority settings that I wrote about would also be capable of it; and you can also use both together if wanted).
It's largely used for large/fullscreen hero images on a page header with text overlaid. The easiest way to ensure required portions of the image are visible and the image always fills the container, and the text placement is exact, was background image. It's a problem we can now solve in multiple ways, with object fit and also with CSS Grid. But there's some inertia on the old background image technique; it's long established and will take time to turn around.
There are a number of people on this thread suggesting that the arguments in this article are fairly weak. That may be the case for some (or most) of them, but the accessibility concerns are right on point.
I work in digital accessibility and by using CSS background images as actual inline content, you're purposefully choosing a technique which does not have a well-understood accessible alternative. Which is fine, if you are one of the people who understand that alternatives do exist and how to use them. My experience suggests to me that the majority of web devs must not be in that category.
I thank the author of the article if including this concern helps just one developer or designer make more accessible images.
What the other people are saying is that images meant as content shouldn't be implemented through background-image.
Perhaps the article makes it appear that there is something wrong with background-image - there's not. It's just the masses of devs (and I'm guilty of this, too) using it in the place of an <img>. Background-image, in the same vane as background-color, doesn't need any accessibility.
Would someone mind explaining what "semantics" a "picture" has that an "image" doesn't have (I'm not too familiar with semantic HTML)? It seems kind of bizarre that the img tag couldn't do both jobs.
An <img> is a tag that finds space to fit an actual grid of pixels.
A <picture> is a responsive-aware tag that can several <source> of actual images (of different sizes), as well as an actual <img> for legacy browsers to still be able to render something.
The <picture> element was standardized with HTML5 so the browser can figure out what <source> is best for its resolution, network speed/cost...
This way mobile phones don't have to download fancy 4K backgrounds, and we don't have to use Javascript because it's part of the HTML spec.
But "a third" seems a bit misleading as the big pie chart in the second only shows 26% (closer to a quarter). From the bars in the middle of https://sparktoro.com/blog/2018-search-market-share-myths-vs... (also Jumpshot data) we can see that Google Images has been steadily decreasing in share, it might indeed have been a third in 2010-2014 but today is probably below 20%.
So that's two different sources of clickstream data that mostly agree, 33% is too high but 20% is plausible. The numbers are not really going to get more accurate than that unless you can hack into Google.
It's wildly important for e-commerce.
I personally will use google image search if I'm looking for a particular instance of something generic (like replacing no-name chinese electronics)
How many image searches result in a visit? If my image search habits are typical then I'd say, not many. In addition, not all visits are good visits. In (nearly) 2020, traffic for the sake of traffic is a fool's errand.
> 2. Bad for Accessibility
Yes and no, but mostly no. The #a11y standard is to make sure AT __ignores__ decorative images. I would imagine most background images are for show (i.e., aesthetic for the sighted) and not actually part of the content. AT needing to "see" background images is fringe at best.
> 3. Bad for Performance
"How could the background-image property possibly be bad for performance? Because typically just one image is used for the background-image property regardless of the device screen width or resolution."
Misusing a tool doesn't mean you blame the tool.
> Link 4. Bad for CMS’s & CDN’s
Perhaps. But how often is this an issue? File this under "good problem to have" and then sort it out for that. It's not a reason to lash out against background-image.
p.s. Yeah, object-fit it a great. But it's not a reason to slag (the misuse of) background-image.
I agree. Google nowadays show real SEO results below a huge amount of links. My entire blog is listing on 2nd pages, having the 100/100 pagespeed, best practices and 20 year domain record. Still I see the threshold around the 2nd/3rd page. Who goes there?
There are great points on SEO and accessibility, the latter which is sadly often an afterthought. However, the author does shoot themselves in the foot a little when the first "typical" example they offer is a div tag with an inline style="background-image: ...". It negates the the preceding point made on how it is bad for CMSes and CDNs and shackles them. Finally, advocating a polyfill to support the small number of users that don't need object-fit could potentially add more render-blocking for everyone if not done carefully.
Good. I don't want my background images/textures to be indexed by search engines or shown to people with visual impairment. It's purely for presentation, and should be ignored by applications that only care about the content.
In fact, 95% of images on a typical web page these days seem to be ads, logos, and cute little buttons that have nothing to do with the content. Which means CSS background-image is perfectly fine for most of these images.
The problem lies in people using background-image as the background of fluid design elements where it acts as an illustration with semantic content. Otherwise, it's OK to use as a decorative background.
In the case of buttons, it might or might not make sense, depending on each use.
I think the problem is frameworks shoving it all in the same place because "an image is an image is an image", which they shouldn't be doing.
It's not about being shown to people with visual impairment. It's so that images that you felt relevant to convey to your sighted audience can also be conveyed to your visually impaired audience.
Buttons and logo have text that need to be conveyed. Figures important to a text need description.
People who build software get a bad rap for building inaccessible apps, and this line of thinking is why.
Article makes good points and how the <picture> element should be used instead.
It's surprising to see how many sites use background images on everything when they can use CSS but I can see developers simply implementing what the designer provided them with.
I use the the Wizmage Image Hider browser extension which disables all images by default which makes websites load so much faster and you can whitelist domain or individual images to always show.
The only problem I've found most annoying on using background-image on the CSS files is that you're bloating the CSS for nothing. You can inline that background file and remove a lot of KBs (assuming you use lots of backgrounds). The SEO part to me became irrelevant long time ago since all the traffic is driven by ad campaigns.
Is it possible to write a WebExtension that realtime modifies HTML requests from remote sites to replace inline-CSS background-image with a <picture><img>? Those would be the cases most likely to be "we're doing a background-image out of laziness and/or to spite people trying to save images with long-press on mobile".
these are super weak. I dont need a background image indexed. there are plenty of ways to bundle and optimize images using webpack and the like. It sounds like someone using the least amount of tools available to make a case for a better tool, which plenty of exist...
Author here. I'm familiar with optimizing images via webpack and the like; there's an article I wrote on the same site as this one detailing just that (amongst other things):
The issue is that for many larger sites that are content-managed, the images aren't known at build time. So you need some kind of mechanism in place to deal with optimizing user-uploaded images.
Obviously you don't want truly decorative images indexed; but that's not what the article is discussing (except in the "SO WHEN IS IT GOOD?" section). It's discussing the abuse of CSS background-image for content images, something I've seen as being quite prevalent.
As the article mentioned, this is bad for accessibility, SEO, performances, and other lesser issues.
CSS sprites most likely. You can combine related smaller images into one image and then position the background image to an element so that only one portion of it is shown. This increases load speed and caching abilities since only one http request is made for the single combined background image.
I think the article makes some great points regarding SEO and accessibility benefits that should be followed. My sole gripe is against the title’s use of “anti-pattern” which 1) they fail to define 2) I associate with dark patterns (this is not that) and 3) use of back-ground image is definitely a pattern, sometimes a very useful one. What does he mean by anti-pattern in relation to background image? New Title: Why <picture> is superior to background-image:
TBH, I hate these kinds of articles. Instead of titling it something like "Things to be aware of with CSS background-image", or even the catchier "Don't use CSS background-image for a foreground image", it uses a much broader, click-baity unwarranted title about "anti-pattern".
I'm glad that background-images aren't indexed by search engines, or made available to screen readers, and I obviously know they aren't downloaded before the CSS that references them is. I think all of those as good things, because I use background-image just for that - things that not primary. When I print, if excluding background images makes the page unreadable, I think of it as using background images wrong.
Calling a widely used, useful feature an "anti-pattern" just because some people may use it wrong is ludicrous.
[+] [-] zzzcpan|6 years ago|reply
[+] [-] khalwat|6 years ago|reply
As for not following my own advice, that's not quite right. I'm using picture and img tags rather than div's with CSS background-image, which is the main thrust of the article.
I'm also using srcset for performance, and webp as a progressive enhancement for browsers that support it.
The only thing I'm not doing is using the new loading="lazy" because the website was creating long before the article.
[+] [-] zamadatix|6 years ago|reply
[+] [-] HelloNurse|6 years ago|reply
It's not a controversial point of view: background-image has always been intended to be purely ornamental (for cases in which background-color doesn't look good enough) and there's no reason to worry about "semantic" features like alt text (a blind or text-only user doesn't care for how the page background is painted).
What perverted line of thought led to the apparently widespread abuse of background-image for content? CSS sprites, as suggested in other comments, are a significant hack that might have set an example but true content (rather than icons) in background-image is on a different level and requires additional explanation.
[+] [-] achtung82|6 years ago|reply
[+] [-] systemcluster|6 years ago|reply
[+] [-] z3t4|6 years ago|reply
[+] [-] zzo38computer|6 years ago|reply
[+] [-] limograf|6 years ago|reply
[+] [-] khalwat|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] jscholes|6 years ago|reply
I work in digital accessibility and by using CSS background images as actual inline content, you're purposefully choosing a technique which does not have a well-understood accessible alternative. Which is fine, if you are one of the people who understand that alternatives do exist and how to use them. My experience suggests to me that the majority of web devs must not be in that category.
I thank the author of the article if including this concern helps just one developer or designer make more accessible images.
[+] [-] kreetx|6 years ago|reply
Perhaps the article makes it appear that there is something wrong with background-image - there's not. It's just the masses of devs (and I'm guilty of this, too) using it in the place of an <img>. Background-image, in the same vane as background-color, doesn't need any accessibility.
[+] [-] achtung82|6 years ago|reply
[+] [-] bruxis|6 years ago|reply
In this case: https://scottjehl.github.io/picturefill/
[+] [-] JeanMarcS|6 years ago|reply
[+] [-] mehrdadn|6 years ago|reply
[+] [-] southerntofu|6 years ago|reply
A <picture> is a responsive-aware tag that can several <source> of actual images (of different sizes), as well as an actual <img> for legacy browsers to still be able to render something.
The <picture> element was standardized with HTML5 so the browser can figure out what <source> is best for its resolution, network speed/cost...
This way mobile phones don't have to download fancy 4K backgrounds, and we don't have to use Javascript because it's part of the HTML spec.
[+] [-] ZiiS|6 years ago|reply
[+] [-] Mathnerd314|6 years ago|reply
But "a third" seems a bit misleading as the big pie chart in the second only shows 26% (closer to a quarter). From the bars in the middle of https://sparktoro.com/blog/2018-search-market-share-myths-vs... (also Jumpshot data) we can see that Google Images has been steadily decreasing in share, it might indeed have been a third in 2010-2014 but today is probably below 20%.
Then there's this Quora answer from 2010, it has a 1:5.5 ratio of images to search from Alexa, i.e 15%: https://www.quora.com/What-is-the-ratio-of-Google-Image-traf...
So that's two different sources of clickstream data that mostly agree, 33% is too high but 20% is plausible. The numbers are not really going to get more accurate than that unless you can hack into Google.
[+] [-] robocat|6 years ago|reply
And when I am searching for an image (and I never Google for porn), I am very rarely interested in the landing pages or text that comes up.
[+] [-] lexicality|6 years ago|reply
[+] [-] chiefalchemist|6 years ago|reply
> 1. Bad for SEO
How many image searches result in a visit? If my image search habits are typical then I'd say, not many. In addition, not all visits are good visits. In (nearly) 2020, traffic for the sake of traffic is a fool's errand.
> 2. Bad for Accessibility
Yes and no, but mostly no. The #a11y standard is to make sure AT __ignores__ decorative images. I would imagine most background images are for show (i.e., aesthetic for the sighted) and not actually part of the content. AT needing to "see" background images is fringe at best.
> 3. Bad for Performance
"How could the background-image property possibly be bad for performance? Because typically just one image is used for the background-image property regardless of the device screen width or resolution."
Misusing a tool doesn't mean you blame the tool.
> Link 4. Bad for CMS’s & CDN’s
Perhaps. But how often is this an issue? File this under "good problem to have" and then sort it out for that. It's not a reason to lash out against background-image.
p.s. Yeah, object-fit it a great. But it's not a reason to slag (the misuse of) background-image.
[+] [-] meerita|6 years ago|reply
[+] [-] retrobox|6 years ago|reply
[+] [-] Operyl|6 years ago|reply
For example, for a lot of people the CDN and WAF are now bundled together and completely transparent. I.e. Cloudflare and StackPath's implementation.
[+] [-] kijin|6 years ago|reply
> Bad for Accessibility
Good. I don't want my background images/textures to be indexed by search engines or shown to people with visual impairment. It's purely for presentation, and should be ignored by applications that only care about the content.
In fact, 95% of images on a typical web page these days seem to be ads, logos, and cute little buttons that have nothing to do with the content. Which means CSS background-image is perfectly fine for most of these images.
[+] [-] jarfil|6 years ago|reply
In the case of buttons, it might or might not make sense, depending on each use.
I think the problem is frameworks shoving it all in the same place because "an image is an image is an image", which they shouldn't be doing.
[+] [-] jszymborski|6 years ago|reply
It's not about being shown to people with visual impairment. It's so that images that you felt relevant to convey to your sighted audience can also be conveyed to your visually impaired audience.
Buttons and logo have text that need to be conveyed. Figures important to a text need description.
People who build software get a bad rap for building inaccessible apps, and this line of thinking is why.
[+] [-] dymk|6 years ago|reply
[+] [-] miguelmota|6 years ago|reply
It's surprising to see how many sites use background images on everything when they can use CSS but I can see developers simply implementing what the designer provided them with.
I use the the Wizmage Image Hider browser extension which disables all images by default which makes websites load so much faster and you can whitelist domain or individual images to always show.
[+] [-] meerita|6 years ago|reply
[+] [-] floatingatoll|6 years ago|reply
[+] [-] indalo|6 years ago|reply
[+] [-] khalwat|6 years ago|reply
https://nystudio107.com/blog/an-annotated-webpack-4-config-f...
The issue is that for many larger sites that are content-managed, the images aren't known at build time. So you need some kind of mechanism in place to deal with optimizing user-uploaded images.
Obviously you don't want truly decorative images indexed; but that's not what the article is discussing (except in the "SO WHEN IS IT GOOD?" section). It's discussing the abuse of CSS background-image for content images, something I've seen as being quite prevalent.
As the article mentioned, this is bad for accessibility, SEO, performances, and other lesser issues.
[+] [-] foota|6 years ago|reply
[+] [-] pjc50|6 years ago|reply
HN uses CSS background images for the vote arrows, and I've never understood why. Could it be exactly the screenreader thing?
[+] [-] grenoire|6 years ago|reply
[+] [-] prawnsalad|6 years ago|reply
[+] [-] TazeTSchnitzel|6 years ago|reply
[+] [-] SahAssar|6 years ago|reply
[+] [-] pixelbash|6 years ago|reply
[+] [-] mikeg8|6 years ago|reply
[+] [-] dang|6 years ago|reply
[+] [-] Thorrez|6 years ago|reply
https://en.wikipedia.org/wiki/Anti-pattern
[+] [-] hn_throwaway_99|6 years ago|reply
I'm glad that background-images aren't indexed by search engines, or made available to screen readers, and I obviously know they aren't downloaded before the CSS that references them is. I think all of those as good things, because I use background-image just for that - things that not primary. When I print, if excluding background images makes the page unreadable, I think of it as using background images wrong.
Calling a widely used, useful feature an "anti-pattern" just because some people may use it wrong is ludicrous.
[+] [-] dang|6 years ago|reply
https://news.ycombinator.com/item?id=20545932
[+] [-] dymk|6 years ago|reply
[+] [-] caiocaiocaio|6 years ago|reply
[+] [-] efffff|6 years ago|reply
[deleted]