
Problems with the CSS background-image property - fagnerbrack
https://nystudio107.com/blog/the-css-background-image-property-as-an-anti-pattern
======
zzzcpan
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!):

    
    
       <picture>
          <source ...>
          <img class="..."
               src="data:... (placeholder, no image)"
               data-sizes="..."
               data-srcset="..."
               data-lowsrc="..."
               alt="..."
               height="auto"
               width="100%">
       </picture>
    

Just don't use javascript for images and static content. It's better for SEO,
for accessibility, it respects people's privacy, it works much faster.

~~~
khalwat
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.

~~~
jakelazaroff
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.

~~~
khalwat
Agreed; if the images are purely decorative (some are, some are not) then it
should have an empty `alt=""` to have screen readers skip them.

But I would still want to use an actual picture element with srcset & source
attributes/tags for the reasons mentioned in the article.

------
HelloNurse
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.

~~~
achtung82
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.

~~~
HelloNurse
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.

~~~
achtung82
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.

~~~
HelloNurse
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?

~~~
achtung82
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.

------
jscholes
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.

~~~
kreetx
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.

------
achtung82
<picture> isn't supported by IE 11 so for the moment this isnt really an
option for us that need to support people with legacy browsers.

~~~
JeanMarcS
Isn’t it why you still put an img element in it ? Or am I mistaking ?

~~~
achtung82
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.

------
mehrdadn
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.

~~~
southerntofu
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.

------
ZiiS
Can anyone think of any evidence to back up the claim a third of google
searches are for images?

~~~
Mathnerd314
The main source seems to be Jumpshot 2017 clickstream data, these posts on Moz
are within 2 days of each other, the first is cited for the "a third" quote in
TFA: [https://moz.com/blog/seo-photos-visuals-graphics-
whiteboard-...](https://moz.com/blog/seo-photos-visuals-graphics-whiteboard-
friday) [https://moz.com/blog/state-of-searcher-behavior-
revealed](https://moz.com/blog/state-of-searcher-behavior-revealed)

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...](https://sparktoro.com/blog/2018-search-market-share-myths-vs-realities-
of-google-bing-amazon-facebook-duckduckgo-more/) (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...](https://www.quora.com/What-is-the-ratio-of-Google-Image-
traffic-to-Google-Web-Search-traffic)

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.

~~~
jobigoud
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.

------
chiefalchemist
I find the reasoning here mostly flawed.

> 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 prop­er­ty pos­si­bly be bad for
per­for­mance? Because typ­i­cal­ly just one image is used for the background-
image prop­er­ty regard­less 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
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?

------
retrobox
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.

------
Operyl
While I can agree with the accessibility stuff usually, depending on how the
feature is abused ... some of these arguments are pretty weak.

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
> Bad for SEO

> 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.

~~~
jszymborski
"...or shown to people with visual impairment"

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.

~~~
hn_throwaway_99
> 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.

~~~
jszymborski
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.

------
miguelmota
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.

------
meerita
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.

------
floatingatoll
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".

------
indalo
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...

~~~
khalwat
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):

[https://nystudio107.com/blog/an-annotated-
webpack-4-config-f...](https://nystudio107.com/blog/an-annotated-
webpack-4-config-for-frontend-web-development)

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.

------
pjc50
Anyone remember the era when genuine background images were popular? Such as
paper texture, greenbar paper, sparkles, and so on? Extremely geocities.

HN uses CSS background images for the vote arrows, and I've never understood
why. Could it be exactly the screenreader thing?

~~~
grenoire
A lot of things are very odd about the way the HN website works, including
most of the underlying JavaScript ( _see_ image object URLs for GET requests).

~~~
zzzcpan
Not sure why you think this is odd. Visit google.com and witness image objects
used for issuing tracking GET requests.

------
TazeTSchnitzel
Is there a proper alternative to CSS for sprite sheets yet?

~~~
SahAssar
Using SVG fragment identifiers seems to be the "modern way"
[https://caniuse.com/#feat=svg-fragment](https://caniuse.com/#feat=svg-
fragment)

~~~
TazeTSchnitzel
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.

~~~
SahAssar
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.

------
pixelbash
Object fit polyfills were iffy at best last I checked, though that only
matters for IE11 (and Edge if using a non img tag).

------
mikeg8
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:

~~~
Thorrez
Anti-patterns have nothing to do with dark patterns. Anti-patterns harm the
developer accidentally, dark patterns harm the user intentionally.

[https://en.wikipedia.org/wiki/Anti-
pattern](https://en.wikipedia.org/wiki/Anti-pattern)

~~~
rhizome
Which is more serious, "anti-pattern" or "code smell?"

~~~
quickthrower2
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.

------
hn_throwaway_99
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.

~~~
caiocaiocaio
It may be an anti-pattern, but is it considered harmful?

~~~
ssalka
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...

~~~
gitrebase
Uh? Your parent comment was referring to often ill suited "X considered
harmful" type of articles.

~~~
coding123
The Problem with Article Titles

------
reshie
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.

~~~
kaushikt
Wow. How many people actually use this?

~~~
reshie
I am not sure. i do not usually share this. to be fair it is not common.

