Problems with the CSS background-image property
nystudio107.com
nystudio107.com
<picture>
<source ...>
<img class="..."
src="data:... (placeholder, no image)"
data-sizes="..."
data-srcset="..."
data-lowsrc="..."
alt="..."
height="auto"
width="100%">
</picture>
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.
But I would still want to use an actual picture element with srcset & source attributes/tags for the reasons mentioned in the article.
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.
Practical example: a group photo of 15 people smiling at the camera on the official page of some event. You adjust colour, you rotate the picture to get a horizontal horizon, you crop different amounts of excess background on each of the four sides. Then would you like "responsive" tricks to automatically slice away their feet because the screen isn't tall enough? Maybe their heads or a bit of both? Or should they be stretched instead, to disturbing squat proportions?
What kind of pictures look better deformed or mutilated than, at worst, unobtrusively letterboxed?
Obviously the ideal situation isnt to crop images, but if the people using the system is aware they can select images that do not have esential information in the edges.
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.
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.
In this case: https://scottjehl.github.io/picturefill/
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%.
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.
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.
> 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.
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.
> 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.
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.
Completely disagree. When used correctly, while background-image is an enhancement for sighted viewers, it's actually a distraction for visually impaired viewers where a screen reader needs to read the information sequentially.
Again, printing (where CSS background-images aren't shown by default) is a good test. If the printed page is still understandable, and actually easier to read on paper, without the background-image, it's probably a good use of the feature. If critical info is missing (stuff that would also be left out by a screen reader), it's a bad use of background-image.
The "printing a page" example doesn't work, because we still need to navigate pages, see logos, etc.
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.
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.
HN uses CSS background images for the vote arrows, and I've never understood why. Could it be exactly the screenreader thing?
Edit: The thing I was thinking of was Media Fragments, apparently that has some browser support at least, but not for images? Hrm. You could put a PNG inside an SVG but that seems silly.
Putting a PNG/JPEG inside a SVG can be a valid strategy at times, but if you are using primarily bitmap sprites then the traditional way of positioning/clipping backgrounds is probably best.
Antipattern is more serious IMO because of the work "pattern", i.e. "something repeated". It is a repeated occurrence of doing something badly (in someones opinion!) across the code base. An example that comes to mind is making references to packages that you don't want structurally in your dependency graph, just to use a utility function.
It's more about deception and persuasion than harm, like the modals that say "Sign-up for our 20-part email series on gold investment... [X] No thanks, I want to stay poor and uninformed"
Although it is an interesting question whether it's still considered a dark pattern if you trick the user into doing something that helps the user. For example in some videogames if you play for hours they'll give a popup telling you to take a break. What if that popup had the options "Sure" and "No, I don't care about my health". Or if you design a UI so that it's really annoying to order unhealthy food, but easy to order healthy food.
And absent nanny-state reasoning (which is really hard to justify in the hands of a no-name dev..), you really are operating user-hostile, even if your intent was not; no better than microsoft forcefully updating your OS for your security, eventually regardless of what you were doing (see guy in middle of 8 hr render process)
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.
I'm always stunned by god-like developers/designers who want to convince others that their way is better, completely forgetting that truly normal users don't care about anything discussed here or done by any other company. :)