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.
Given that all the images in the article are purely decorative, why you using picture and img tags rather than CSS background-image? You're also supplying alt attributes, so someone with a screen reader will hear a random "Bad boy doggo" in the middle of an article about HTML and CSS.
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?
In case you are using a browser without JavaScript or have disabled JavaScript, or are using some customizations which the script on the webpage is not compatible with, then using a script to load the images can be bad for accessibility. (There is a legitimate reason to do so, but it is unfortunately used for many cases when it is not a good reason. If the width and height are hard-coded, then when the images should be loaded is possible to implement in the browser, subject to user settings, without needing a script on the web page.)
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.
But these features are meant for ornamental images, which should fit their container instead of being displayed "naturally". Stretching or cropping content images (instead of scaling and padding them, which is equally easy to do with proper and improper markup) is intrinsically inappropriate, not something worth doing.
I disagree. I would say cropping images is essential to be able to use images in responsive designs. It is obviously possible to make websites where images have the same aspect ratio on all devices, but in reality you dont always have the same people in charge of design as implementation.
In a responsive design, an image can be displayed with its proper aspect ratio, cropped as the author saw fit. It can be scaled to fill the available space horizontally or vertically, and it can be optionally optimized with a picture tag instead of a img tag to load a lightweight version if the available space is small.
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?
As i said before im not disputing that it is possible to make responsive design keep same aspect ratio always. Im just pointing out that in reality you can not control all parts of your work. Design as i said can be done by people you have no influence over. And they might have very relevant reasons for making it the way they do.
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.
`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.
True, of course then you will have to deal with the formating problems that made you choose background-image over img in the first place. Though concidering the small numbers still using IE 11 that might be acceptable.
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.
I wonder if these numbers are for traffic as in bandwidth or for discrete requests. Counting by bandwidth would explain the surprising representation of image search.
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.
> It's so that images that you felt relevant to convey to your sighted audience can also be conveyed to your visually impaired audience.
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 point made earlier is that most images are "buttons and logos", and while not part of the main text, understanding what they say is important to e.g. the navigation or context of the site. For that reason, it's no more clutter for users of screen readers than it is visual users.
The "printing a page" example doesn't work, because we still need to navigate pages, see logos, etc.
They do not care about visual/aesthetic presentation such as gradients, shadows, textures etc, aruagbly the most common and appropriate use of background image. They care about structural presentation.
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.
Ah, wonderful! I remember there was some proposal to let # specify a part of a bitmap some years ago but it didn't take off, but that SVG supports it (in a better way) is great!
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.
Yeah, Media Fragments is basically only implemented for partitioning videos based on time, not slicing bitmaps.
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.
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:
To me code smell is a clue that some code might be badly written. But it's not proof - and there could be good justification for the smell. An example would be a 500 line method.
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"
Generally tricking the user into doing something would be considered harmful.
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.
I’d still consider it a dark pattern, as you’re still operating hostile to the user; you’re trying to get done what the user explicitly does not wish.
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)
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.
At the very least it's user-hostile, if I want to save the image I would have to inspect element and open the URL in a new tab, rather than just Right Click > Save Image as...
this is one reason i like console browsers; i have a custom default css for it as well though. a lot of sites like to have there own rules for css and that is when general user css have to get into per-site css configuration especially your graphical browsers.
...and there is like 5 people doing that in 7.7 billion population.
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. :)
