I have an iframe container on my page that loads a map when i click on a button. And for some reason, when the map loads it causes surrounding objects to go blurry.
Example: https://i.postimg.cc/xCfJWwZG/beforeafter.png
I have tried adding -webkit-font-smoothing: subpixel-antialiased; to various things in the CSS and transform: scale(1.0) translate3d(0,0,0); which only makes the objects permanently blurry. How do i stop the iframe from screwing up my page.
Most likely the problem is not being directly caused by the position:absolute css property but is caused by anti-aliasing due subpixel positioning of the iframe.
With either positioning using a % value or using a transform with % values the iframe can be inadvertently positioned in a subpixel position i.e. left is set to 10% and that calculates to say 10.5px. That results in the iframe content appearing blurred.
In my case something as simple as an odd value (35px) for padding on a ancestor element resulting in an odd value for width and then a left:10% on the iframe was enough to cause the problem, setting the padding to an even number then removed the problem.
Adding it as an answer so that people looking for similar problem will find it.
Sometimes the content of the iframe has absolutely positioned elements inside that due to css positioning might take up the whole screen if the iframe is not positioned relative to some container.
So it seems in this case this is the problem.
So try to wrap the iframe in a container and set its position:relative to fix it.
Related
I am experiencing an odd issue and am wondering if it's a bug in the rendering engines - it occurs in WebKit and also Firefox that I've tested.
If you have a div that's fixed on the page and you add another div inside it and also set it to be fixed (to obtain a fixed header within a fixed popup), you can ensure that the header will remain visible even when the user scrolls the popup. Unless you set transform scale on the popup - doing that will break position:fixed and cause it to no longer fix to the top of the parent div and instead it will scroll along with the content. Is that expected behavior - how can I work around that?
JSFiddle
Well the transform: scale(x) will break the element out of the coordinate flow and thereby can not have a fixed position.
I'd recommend instead wrapping the text below #header in a constrained div with overflow: auto. A fixed child of a fixed ancestor just doesn't make that much sense, but I can see what you were going for.
Recently we've had some customers complain about our website positioning being messed up and we've since found out that this problem only occurs when their browser is zoomed out to around the 75% mark. Most of our customers do not realise that their browsers are set to zoomed out mode, and we have been told to fix the problem so positioning is consistent regardless of the zoom level.
I have tried resizing elements using em and also tried in % but the positioning still messes up.
Here is a link to the website:
http://www.comms-express.com
The issue occurs on all pages - the 'Need Assistance' box at the top right of the page falls off at 75% zoom, and the main boxes on product pages do not fit in the container at 75% zoom.
Could anyone give me some pointers? I'm looking for some kind of CSS media query which would allow me to change CSS rules on specific zoom levels.
Thanks!
This seems to mainly be effecting your .product elements, change their width from its current setting of 190.5px; to 23% so they scale proportionately.
.product {
width: 23%;
}
This is likely more of a quick fix than anything else, but should solve the position issue until a more permanent solution is found.
I managed to solve this problem by modifying widths of elements to use percentages instead of pixels, and by re-tweaking how elements were spaced. Instead of using a margin, I placed a smaller inner container and gave this a padding which generally resolved most problems.
I'm running into some extremely strange behaviors, and non-consistant across every browser i've tested.
I've a pretty complex layout, but the main issue lies here:
<div id="drop">
<div id="header"></div>
</div>
#drop has position:absolute and z-index:100
#header has position:fixed; top:60px;
As I start scrolling down Chrome ignores the position:fixed rule. If I remove either of the two styles above from #drop then Chrome starts respecting the position:fixed rule.
can't get it working on Ubuntu Chrome 23.0.1271.97 and see the same behavior on Mac Chrome 25.0.1364.99. My friend uses Ubuntu Chrome 25.0.1364.68 beta and it works correctly for him. I've tested it on firefox and it kinda works (with other symptoms)
Has anyone heard of this error? or can anyone even reproduce it?
edit
I'm using openlayers map as another div with position:fixed if I delete that layer or at least change it to display:none then this weird bug goes away.
edit
Noticed that during the presence of this bug, if I change the zoom level back and forth, then the position adjusts itself to the proper behavior. To me, this indicates a webkit issue that fails to execute some internal callback function on scroll.
Another extremely strange thing is that I have a few links inside of #header and they work if I just click the expected location, even though the the div does not appear there. Overall I've noticed that it's only the rendering that's broken. If at any point of time I force the browser to re-render by resizing the window, or changing zoom, or just doing Select-All, then the header bar jumps to the proper position, but does not remain fixed.
You mentioned in the comments that OpenLayers uses CSS transforms. That being the case:
the element with fixed positioning will become relative to the element with the transform - not relative to the viewport
Take a look at the spec: The Transform Rendering Model
Specifying a value other than ‘none’ for the ‘transform’ property
establishes a new local coordinate system at the element that it is
applied to.
.wpr
{
width: 200px;
height:1000px;
background: pink;
position:relative;
margin: 0 200px;
-webkit-transform: translateX(0);
transform: translateX(0);
}
.fixed
{
width: 200px;
height:200px;
margin: 50px;
position: fixed;
top:0;
left:0;
background: aqua;
}
<div class="wpr">
<div class="fixed"></div>
</div>
As the accepted answer says, this is the intended behavior, and is spec-compliant. Another important component of this is what it means to be using CSS transforms.
In your case, it was due to OpenLayers, but this applies to anyone using will-change: transform as well (probably a lot of the people visiting this question). This has been brought up on the Chromium bug tracker here, and marked as WontFix, because (as I said) it's intended behavior. The official comment is this:
This behavior is required by the spec
(http://dev.w3.org/csswg/css-will-change/): "If any non-initial value
of a property would cause the element to generate a containing block
for fixed-position elements, specifying that property in will-change
must cause the element to generate a containing block for
fixed-position elements."
The idea is that once will-change:transform is specified, you should
be able to add/remove/change transforms cheaply, without needing
fixed-position descendants to get re-layed-out.
Note that using other values of will-change (e.g. opacity, top) will
not change the positioning of fixed-position descendants.
As far as I am aware, the only solution is to make the child of the will-change element a sibling instead, to prevent the attribute from cascading.
As a side note, in my specific case, I was able to fix it by being more specific with the will-change attribute. Instead of using it on the div containing the performance-jarring element that required GPU offloading, I used it directly on the offending element. This was due to my original bad code, though, so it won't work for most cases.
You will have to place header outside the parent container drop to make it work.
I had slightly similar issues days back.For instance,if you set z-index of header,it will be attain the z-index of the parent dropcontainer.The z-index of header will be useless because it is already inside a container which has another z-index.
The same logic of z-index applies to position.
I want to add another possible solution because I was struggling with chrome ignoring position:fixed for quite some time until I finally found the culprit:
-webkit-perspective: 1000;
It was coming from a plugin I was using and causes ALL position:fixed elements to be ignored.
Hope it helps someone.
I think this is impossible, i don't think if two positions can be placed at the same place without one to collapse. But i think its better to use Avail height in javascript, i mean if you wanna an outer div to hold inner div, and outer div must cover the whole screen, use Availheight in js, this will get the screen height and then apply if, thereafter set all the divs in fixed position.
Add this to parent:
position: fixed;
...and this to the child:
position: sticky;
First of all, put something in your div as empty ones behave really weird. Then, what do you expect by putting a fixed into an absolute? Obviously, nobody knows what is the reference point of your fixed div. Should it be its parents position? which is not changing with scroll or the page position which changes? Try to use things that are completely meaningful and have a clear definition because if you fix it in chrome, what would happen with another browser? Do you really prefer to test is on all of them?
I suppose a small change in your divs so that pull the fixed div out of the absolute one or move the absolute div somewhere else.
In all major browsers: as the question states, a parent <div> container (whose height is not set) over-sizes its height to fit a child <img> element (for instance, a 300-pixel tall image that is the only thing inside the div). The over-sizing is usually about 3 to 5 pixels, and appears at first as img margin-bottom or div padding-bottom might look.
However, using absolute positioning, it is clearly demonstrated that the bottom of the div is below the bottom of the imgby a few pixels. It might not ruin a website's design, but it is a hurdle to overcome in certain situations. I have made a fairly detailed fiddle demonstrating this issue here.
Why is this standard practice in web browsers?
Is this meant to compensate for something? It seems unnecessary.
Is this a bug, or a soon-to-be antiquated feature?
EDIT: Thanks to the answerers/commentators below, I know the reason is that an <img> is treated by default as CSS
display:inline which preserves whitespace around the element.
Changing it to display:block completely fixes the problem by
eliminating whitespace around the element.
Notes: This over-sizing can be averted by giving the image child element a CSS property of float:left or float:right, etc., but this is a workaround, and as such is not the answer to the question. One reason this can be problematic is if you already have other float elements layered in front of the div child image (float overlap not allowed Firefox, Opera, IE. float overlapping only seems allowed in Chrome and Safari using CSS position settings). Thanks!
Add display:block to your image. I think that will fix the problem.
Is there a way to make an element not contribute to parent overflow, but keep it visible? Let me clarify
There is a watermark-like logo to be applied to a page in the manner below. It is supposed to be positioned partly outside the main content (dashed blue line)
I'm not aware of the option to set an element background in such a manner that it would persist as the browser window is resized horizontally, so I've just added a <div> with the logo as its background and position:absolute with the necessary offset relative to main content container.
Previously, the page would not get a horizontal scrollbar as long as the browser was wider than W1. Now, with an additional "watermark" element added outside of the main content box, the scrollbar would appear whenever the browser is narrower than W2
Is there something obvious I'm missing? A background setting, or possibly a neat margin workaround/
Update:
I've added a rough jsfiddle to illustrate the issue
Unfortunately, just because you nested the "watermark" div and positioned it absolutely doesn't make it outside of the document. If you put it outside of the document, the page will scroll (as you see).
To me, the first solution I think of is to move the watermark outside of the "content" div and apply the watermark to its parent container. I'm guessing you haven't done that because you need it to be relative to the "content" div, but it's something to try.
Also, the reason it scrolls is because the document has been overflow. The quick fix, yet not recommended, is to use "overflow-x: hidden;" on the parent container of the "content" div.
It's harder to give you a solution since you've stripped the rest of your HTML, and some "fixes" may not be as applicable if your structure is complicated in certain ways.
Remember that the width of your elements is greater than the actual "width" it includes padding & margins, if you have padding on your div reduce the "width" by the equivalent amount.
does that make sense? if you post the actual css & html it might be easier to give you a more detailed answer
additionally could you not assign the image as the background of the actual body element and set it to centered?
I've had a play with the code and come up with a possible solution for you.
set
body{overflow-x:hidden;}
then add
#media all and (max-width: 400px)
{
body{overflow-x:auto; }
}
as soon as your screen is smaller than 400px (the width of the div) your overflow:hidden will be overridden and you'll be given you scroll bars.
at this point you may also want to reduce the width of your watermark.