Bug 234779 – [iOS] background-attachment: fixed should not crop background and ignore sizing properties

• Status: NEW
• Component: CSS

[Christian Liebel]

Created attachment 448149 [details]
Comparison of background-attachment: fixed (top) and scroll (bottom) on iOS Safari. The "fixed" background is greatly enlarged.

The CSS property `background-attachment: fixed` is not supported on iOS. Instead, the background scrolls with the page. However, the background is still cropped as if `background-attachment: fixed` would be applied. (I'm not exactly sure to which dimensions the background is cropped. There seems to be a difference if a responsive meta tag was set or not, with the tag set the background image is greatly enlarged. The `background-position` property seems to be ignored, see attachment.)

I use this effect to create a parallax effect where the user can reveal the entire background image by scrolling the page, as it works in most browsers including desktop Safari. It's fine for me to fall back to the `scroll` behavior, but therefore the background must not be cropped and the `background-position` and `background-size` properties must be applied. Due to the zooming and because `background-position` is ignored, the current result is hardly usable and I need to detect mobile Safari to explicitly set `background-attachment: scroll` there.

In short, as `background-attachment: fixed` is not supported on iOS, it should behave exactly as `scroll` and not take any different code paths.

Repro: https://christianliebel.github.io/bg-repro/
Source: https://github.com/christianliebel/bg-repro

[Simon Fraser (smfr)]

Agreed.

[Simon Fraser (smfr)]

Also @supports should not lie and claim that it's supported.

[Radar WebKit Bug Importer]

<rdar://problem/87099014>

[Sam Sneddon [:gsnedders]]

(In reply to Simon Fraser (smfr) from comment #2)
> Also @supports should not lie and claim that it's supported.

If we fix that, then presumably we'll no longer support the value at parse-time and hence the rest of the issue will be solved because we'll never end up with it as a computed value? Hence this is actually just a dupe of bug 196327?