We are replacing background-attachment: fixed with position: fixed. So, we are creating two separate elements - one for the background-gradient and another for the rest of the content. If it’s looking at the smallest possible viewport, then maybe we should be working with an element that looks for the largest possible viewport and position that instead. So, as you know, we are getting in trouble with the background-attachment: fixed property and, as you might have guessed, we are removing it from our code.
Whatever the case, it fixes the linear gradient and background image issues we just saw. iOS has an issue preventing background-attachment: fixed from being used with background-size: cover.Ĭall it a temporary hack, if you will.It causes the image to get cut off and gain whitespace around it. Chrome has an issue that occurs when using the will-change property on a selector which also has background-attachment: fixed defined.Firefox does not appear to support the local value when applied on a textarea element.The issues are nicely documented over at caniuse: This means 100vh will be larger than the visible height when the URL bar is shown. That is, vh units will be sized to the “largest possible viewport”. Instead, vh units will be sized to the viewport height as if the URL bar is always hidden. vh) will not resize in response to the URL bar being shown or hidden. Weird! Perhaps the reason is that background-attachment: fixed relies on the smallest possible viewport while elements rely on the largest possible viewport. That’s because background-attachment calculates a fixed background position relative to the viewport.Įven if we say the body is 100vh, background-attachment: fixed is not exactly in accordance with it. I want to keep the background gradient in a fixed position on scroll, so let’s apply basic CSS styling to the body that does exactly that: body The grey section at the top just indicates the presence of an actual URL bar in Chrome Android.Īnother interesting thing to note is that when background-attachment: fixed is applied, the height is ignored even if we explicitly specify it. We can see it by looking at two different approaches to CSS backgrounds: The issueīefore I show you the fix, let’s examine the issue.
Figma on move or zoom it moves viewport bug code#
I suppose we could call it a “hack” since it’s a workaround in code that arguably we shouldn’t have to do at all. You can ditch this idea completely and let the background scroll on small screens using media queries. In addition, it think it’s a fair assumption that read the viewport and immediately writing back to it should not cause a drift, whether the ruler is on or not.What options do you have if you want the body background in a fixed position where it stays put on scroll? background-attachment: fixed in CSS, at best, does not work well in mobile browsers, and at worst is not even supported by the most widely used mobile browsers. Here is a related bug my user filed on GitHub.
The plugin replies on the accurate behaviour of the figma.viewport API. It calculates the x and y difference the viewport needs to travel and apply it as user controls the device. I maintain a beloved a plugin that allows user to use a custom device to zoom/pan the canvas. Reproĭocument.getElementById("set-viewport").onclick = () =>, "*") When ruler is turned on, the value read from and the value written into figma.viewport are treated differently.
0 kommentar(er)
