I'm having issue positioning popper on a scaled iframe element.
In the screenshot you can see that the element is wrongly positioned both on the X and Y axis. The scale is applied with a css rule transform: scale(x)
In this sandbox you can reproduce the issue using #popperjs/core 2.11.6
https://codesandbox.io/s/elastic-haze-197srf?file=/index.html
I can see that the iframe scaling should be handled here:
https://github.com/floating-ui/floating-ui/blob/db4b7ad129b3f79b85184c3c30f352daab824cc3/packages/dom/src/utils/getBoundingClientRect.ts#L61
Is this a known limitation of Popper v.2? Any known workaround for this?
Thanks!
Turns out it's a know limitation of Popper v2.
The issue is resolved using floating-ui v1 as explained here:
https://github.com/floating-ui/floating-ui/issues/2184
Related
This bug is appearing only in Safari on Mac OS and only with the current set up in our application. Initially I though it was a z-index issue, since some elements disappeared after updating that value.
Although there's a last element that has no z-index value and it's always displayed on top of the full-screen video.
--see screenshot below--
I have tried removing all styling from the bar you see on the screen and it would still appear on top of the video.
--see screenshot below--
As you can see the elements within the bar are still visible.
I haven't been able to reproduce the issue on codepen.io or jsfiddle and nothing is currently available in Stackoverflow or GitHub.
SOLUTION:
removing will-change property from the container solved the issue.
DESCRIPTION
The problem that caused this issue was the property will-change set to one of the containers of this video element.
The structure of the application is quite complex so I am not going to post the whole code here. Although by moving around the video element in the inspector and testing the full-screen functionality every time, I narrow down the problem to one div container that had this property.
If you guys find out the exact reason why the default full-screen functionality of safari broke down because of the will-change property, post a comment or an answer since it will be very appreciated.
I had a similar issue with my application. Web elements were overlapping fullscreen videos. Only effected Safari on Mac OS. I also assumed it was a z-index issue specific to Safari and initially tried modifying z-index when fullscreen mode was detected. Thanks to Guilio G.'s comment above the issue was resolved by removing the -webkit-backdrop-filter:blur(3px); of a parent <div>.
Like Guilio G., I don't yet know why, but this -webkit declaration was causing the issue and removing it resolved the problem.
In my case, this issue was being caused by isolation: isolate on an ancestor element. Removing this property fixed the issue.
Hopefully Safari fixes this, since isolation is a wonderful property that solves a bunch of stacking context issues.
I'am using Bootstrap 4 in React.js project.
I have two elements - navbar and alert implemented from Bootstrap4.
Since I've set position:fixed in both (overrided css) both of them become semi-transparent. I've never used transparency for neither of them and haven't use rgba color codes for them. It just happened by itself ... why and where I should seek ?
I found the answer by myself. Post it here in hope to be helpful for some other newbie :)
So:
When you're using Bootstrap4 read documentation carefully ;)
When you want fixed top/bottom navbar WITHOUT transparency instead of overriding .navbar class in your's csses by adding position:fixed apply ready-to-use Bootstrap class fixed-top/fixed-bottom/sticky-top applying them to your html/jsx Bootstrap element
Docs: https://getbootstrap.com/docs/4.0/components/navbar/#placement
This is a (was) very hot topic but I did not find a good answer for that.
So I am developing a plugin for a webshop and I need to integrate a popup window that has a position:fixed
The problem is that in IE8 position fixed has a doctype problem and I cannot change the default doctype of the website.
Can anyone tell me how to / or if it is possible to use position:fixed in IE8 without having to change doctype?
Edit: I am using default html5 doctype
This is a bit late, but I hope it helps. Upon searching other sites/answers about all the issues with position:fixed, I've found that changing the doctype and using a metatag for X-UA-Compatable do not work for every issue. However, positioning the for the overlay on the HTML page does make a difference. If your overlay is being obscured by other elements, put the for the overlay after the elements that are obscuring it. It doesn't matter where this div is in the HTML DOM, right?--because it's fixed position anyway.
After days of hard work (i know it would've taken a pro only a few minutes), I have finally designed the exact layout I want. The only problem now is that it uses a lot of absolute positioning, which I hear is evil or at least undesirable. Here is the jsfiddle of how I have done this. Can someone guide on which of these <div>s can avoid absolute positioning and instead use more fluid constructs?
I am not sure where you can avoid using absolute positioning in that fiddle, becuase i didn't go through your css. but if older browser support in not a problem, you can create this layout without using absolute positioning at all..
check this Fiddle
It uses css3 calc() function so will only work in modern browsers.
There's a loss of 1% width due to the whitespace problem of display:inline-block elements
This is another Fiddle using display:flex property which avoids the whitespace problem.
Tested and working fine on Chrome 33.0 FF 28 & IE11 (This one was a surprise! :)
CSS Flexible boxes makes it easier to create layouts.
Read more about Flexible Boxes # MDN
Flexbox guide # css-tricks
Float left for the columns and use default relative positioning. Percentage widths and set heights to px if need be. That would the most consistent layout.
I have an element positioned fixed at the top of the screen, with a z-index of 100. When I scroll up the page in Chrome (V. 21.0.1180.82 on OS X and V. 21.0.1180.83 m on Windows) I notice a rendering problem which looks like this:
UPDATE:
I noticed that the rendering problem appears every time when the fixed element passes a new <section>...</section> during scrolling up. Chrome seems to have some issues related to HTML5 tags like <section>...</section> or <nav>...</nav>. Changing those to <div>...</div> solves the rendering problem, anyway I would still like to continue using HTML5 tags.
Does anybody know a "hack" to solve this problem?
Until then I will try to create a reproducible code sample and file a bug to chromium.
The cause of the issue where elements with an opacity of 0 inside the fixed element. Setting those to display: none solved the problem.
Particularly for Chrome latest browser version (55.0.2883.87 m (64-bit))
I have added:
-webkit-transform: translateZ(0);