Recently I spent WAY too much time on
background-attachment. Even though it’s not a tremendously important CSS declaration, I don’t see any reason not to inflict my pain on you as well. Besides, I retested the CSS Backgrounds and Borders module in all browsers, and that should count for something.
If you need to refresh your memory, take a look at the background-attachment test page in a desktop browser that is not Chrome 51 on Windows 10. For God’s sake don’t use a mobile browser — or Chrome 51 on Windows 10.
background-attachment used a lot? No, not really. And the
local value, especially, is hardly ever used. Still, I have an ulterior motive for studying exactly this declaration.
Leaving aside the tricky parts, all browsers support most of Backgrounds and Borders. Some notable exceptions:
-y, though support is supposed to land pretty soon.
background-origin(and an old note suggests this is specifcally an Android problem). Also,
background-size: contain and coverare buggy.
All in all not an overwhelming set of problems. Still, we haven’t looked at the tricky bit yet:
From my previous round of testing I already knew that many mobile browsers support either
local but not both. I wanted to verify that that is still the case.
It is. But with added wrinkles. See the inevitable table for more details.
localonly, but only if you do not use
-webkit-overflow-scrolling: touch. In addition, it correctly positions the background when you use
fixed, but doesn’t ever change it.
fixedonly, and they have various bugs.
localonly from version 35 on. BUT ... oh boy! See below.
localonly, but with the same problem as Safari.
localis pointless, since you can’t scroll individual elements in Opera Mini./li>
That leaves Firefox on Android the single mobile browser to perfectly support
Contrary to my expectations, in my first test run the Chromia on Android did not support either
local. Odd, but I made the necessary notes.
Later I happened to look at the caniuse entry and found that it gave full support to Safari iOS and Chrome on Android. With my new research in hand I raised issues and asked Alexis to change the compatibility data.
He replied pretty soon. He changed his Safari/iOS information, but for the Chrome problem pointed me to this test case by Vadim Makeev. Lo and behold:
background-attachment: local works absolutely fine!
Whut? It’s a long time ago that one of my test cases was contested. Besides, I hadn’t made an actual mistake: the code I wrote was supposed to work, and in fact worked in quite a few other browsers.
So there has to be some sort of difference between the two test cases. I spent about half an hour testing various options (see the issue for details), but in the end gave up. I wrote some snarky sentences for my table and decided to get me some expert help.
In the end, that help came from Samsung. (Samsung? Yes. They’re in the process of opening up, but more on that later.) I mailed my contact persons, and they were as surprised as I was. This Monday I saw their bug report:
Any element that has
background-attachment: local also needs a
border-radius in all Chromia. And no,
border-radius: 0 is not enough, it has to have an actual value.
Thank you, Samsung. I would never have thought to test
border-radius. Oh, and incidentally, Chrome 51 on Windows 10 has the same bug. Also, I ascertained that Chromia version 34 or below do not support even the
border-radius test case. So
background-attachment: local (with bug) was introduced in Chromium 35. That’s good to know.
Update: Bug also reported on one MacBook Pro (Retina, 13-inch, Early 2015), though it does not appear on either of my two (Air 13'' early 2015 and Mini 2015).
Anyway, there you have the current state of affairs in Backgrounds and Borders. What I haven’t told you yet is why I wanted to test
background-attachment specifically. I’ll talk about that tomorrow.
If you like this blog, why not donate a little bit of money to help me pay my bills?