CCS3 background-size:cover not working in IE - css

I am working on a web application that allows me to insert some custom css for the front page.
I want to have a full screen background image at the start page. I understand that I can use background-size:cover which is supported in all latest version of browsers.
body {
background-image:url(/File/Publisher/Start/startpage_background.jpg);
background-repeat:no-repeat;
background-size:cover;
}
This works for latest version of Firefox and Chrome. However, it is not working in IE11. The background image does not shrink to cover the entire screen. It displays at its original size and is partially cropped off.
Using F12 to debug, I discover that if I disable either margin-top or margin-bottom (see screenshot), background-size property will work.
I do not want to modify the margin property introduced by the original CSS of the web application. Any way to resolve this problem?

I came across this as well and found that giving body any height makes the cover property have effect as long as it's not set as a percentage. For good order, min-height: 100vh should do :
http://codepen.io/anon/pen/oXmzLL?editors=010
Pretty odd since there's no issue on any other browser but that's IE for ya. Of course it's only present if the content doesn't exceed the window size (edit - it should also not have positioning that takes it out of the document flow).
Not the quickest answer by the way but it's the only topic I came across on this subject (that wasn't about legacy browser support)...

Related

How can I make background-size:cover work in IE10 without making attachment fixed?

My code:
html
{
background-image:url('img.png');
background-repeat:no-repeat;
background-position:center top;
background-size:cover;
}
This works perfectly on Firefox and Chrome, but on IE the image doesn't get stretched at all. It will work if I set background-attachment to "fixed" but that isn't what I want.
Every website I've looked at claims that these proprties are perfectly implement in IE, but they clearly aren't.
Troubleshoot CSS Background Size Cover
It's a bit hard to troubleshoot without seeing additional code or the website, but here are some things you can try.
Try adding background-attachment:scroll; instead of leaving it blank
Is your doctype correct, or does it have typos?
Are there other scripts or styles on the HTML tag that may be interfering/overwriting the background style?
Hit F12 to open Developer Tools, and click on the HTML tag to see what styles are listed. Toggling the CSS styles on an off for key elements on your site can help you troubleshoot the problem.
If you are in IE Developer Tools, check to see if "Document Mode" and/or "Browser Mode" are set to an older browser. (IE6, IE7 and IE8 don't recognize background-size:cover, and will show the background in its original size - Can I Use support table.)
Is your background only filling the browser window, and not expanding to cover the document page/scrollable areas? Try adding height:100%, width:100%, margin:0 and padding:0 to your HTML and BODY tags. (The default HTML and BODY tags have different styles. The HTML size is controlled by the browser window, while the BODY will wrap around the contents, regardless if the contents are less than the browser window, or expands past it.) Also try switching the background to the BODY, or the wrapper tag.
To help troubleshoot, make a basic test page with the HTML, BODY and wrapper tag only (if you use a wrapper), and see if you can get the background to function properly. This will help you narrow down the bug. Your wrapper may need a height and width too. Depending on your wireframe (DIV or CSS Table, HTML Table), it may need: min-height:100% and min-width:100%, or height:100% and width:100%.
I created a simple html page with the css you provided, did not include a background-attachment, and used <!DOCTYPE html> as the doctype. The background worked well and fully covered the screen as expected in Windows Vista/IE9, Windows 7/IE10 and Windows 8/IE11.
Side Note: Full background Stack Overflow solution for IE7 and IE8

Choppy scrolling in chrome with big background images

I've created a web page, and it has 7 six sections with huge background images using background-size: cover;. It works fine in all browsers except Google Chrome (All versions/All platforms). When I try scrolling the page in google chrome or click on its links (which they also scroll the page using $.scrollTo) the page gets choppy and laggy and it scrolls slowly and uses 100% CPU.
I've uploaded the page so you can test it: http://baaemail.com/beta (I'll remove the page later). Even IE9/10 is fine, but chrome gets choppy.
The page has several "scroll" events bound to it and I have tried disabling the javascript altogether but it doesn't get better so its not from the scroll events.
I'm using background-size: cover because it shapes the photo exactly like I want it to and I want the image to be fixed that's why I can't use other methods like using img tag instead of backgrounds.
What should I do?
thanks.
A solution I found for myself for a website with similar behaviour was to add background-repeat:no-repeat css property for those divs containing huge background images.
You can also check if you have a background image for body or html that is repeated, for me the big problem was a repeated pattern image that interfered considerably with google chrome's scrolling performance.
Also if you're using CSS transitions on those "slides" you should check that those are not assigned to "all". If you're having a transition only for the "left" property there is no point assigning it for "all".
I'm not sure if this alone will help you but it is always a good practice to compress your images and your scripts.
This stuff did the trick for me. Hope it helps.

Chrome CSS background image appears with white area

I have a mysterious (at least for me) css background image problem, that I run into only with Google Chrome. I have found similar topics, but unlike those, here no Javascript, JQuery or anything else is involved, it is pure CSS. It's just not working as it should.
If you open up the page www.bodrogietterem.hu, the background image should be below the entire content area (as it is in other browsers). In Chrome a horizontal and vertical white area is appearing.
Once you start scrolling, the background image appears all okay, and it stays there from then on. Similarly, when you open the dev tool with inspect element, the background image is immediately there, and stays there, too.
this is the pertaining css:
body.page-node-1 div#main{
background:#FFFFFF url('/sites/all/themes/bodrogietterem/images/bodrogi_bodrogi.jpg') bottom;
background-repeat:no-repeat;
background-attachment:fixed;
background-position:50% 135px;
padding-bottom:0px;
margin-bottom:0px;
}
and attaching two screengrabs on how it looks like, and how it should look like (well, I'm not allowed to attach these, as a new user, but have a look here:
http://www.bodrogietterem.hu/chrome_issue.JPG
and here
http://www.bodrogietterem.hu/should_look_like.JPG
It happens on sub-pages, too, but I think the root of the problem must be the same.
I'm using Vista, with up to date Chrome (20.0.1132.57), and up to date other browsers. btw, the second screenshot was taken in Chrome, too, but after opening the dev tool
many thanks for your kind help,
bests,
Zsolt
The latest version of Chrome is 21.0... so try updating chrome browser and see if it appears ok in the latest version. The screenshots lead to a 404 error page, so try uploading the screenshots again.
I also checked the page in IE7, IE8, IE9 the page looks good in all 3, IE7 however shows a horizontal scrollbar at bottom but the background image looks ok.
Your page looks fine in Chrome in windows 7 (Chrome 20.0.1132.57)
I have had problems in the past where various toolbars / addons that have been installed interfere with the CSS on a page quite significantly rendering Chrome to appear to bug out in isolated incidents. Try running chrome with no addons / plgins installed and see if it fixes your problem.
One observation on your CSS: #content contains floated elements that aren't cleared. I dont think that's the problem here but could be mixed with the above possibly.
Let me know if that helps at all.
Thanks for your helpful thoughts, I finally managed to resolve the problem.
While fiddling around, I measured the height of the white area, and it turned out to be 135px (which is exactly the top position of the background in the CSS above). So I decided that for whatever reason, that attribute was causing the problem, and I was right.
as a quick and dirty solution, I added 135px of white area to the top of the background image, and set the background-position property's top to 0px - which immediately fixed the issue.
as for the vertical white area, it was resolved by binding the background image to the #main-wrapper div instead of the #main div (it is a Drupal 7 build). Again, I don't exactly know why, but it fixed the problem instantly.
I love, how the web should be precise and logical, and it still stays random and ad hoc at times
thanks again for your time and effort, bests,
Zsolt
Had the same problem with two pages of http://www.stoerbeton.nl but I think I solved it after reading your above posts and some thinking.
The problem was probably in the general background: url; attribute and loading of the website css. I replaced all general background: #222222 url repeat etc.; for background-image:; , background-repeat:; and background-color:; etc.
Please let me know if your website works after editing your css. I'm still testing.
Greets, aquaster.nl

Iframe height not displaying correctly in Firefox only

I have created a page that has similar functionality to that of the DiggBar (i.e. a header of specified height and an iframe below filling the rest of the page).
I had this working a while back with desired results, but all of a sudden the height of the iframe has gone from 100% of the remaining page height to only 44.8px. The catch is that this is only occurring in one browser — Firefox on Ubuntu.
I thought that this should be happening in all other browsers, but it's not. It displays correctly in IE, FF, & Chrome on Windows and Chrome on Ubuntu.
Finally, using Firebug, I have selected inspect element to try to determine what's going on, but it only tells me that my height is defined to be 100%, but that it is computed to be only 44.8px.
I am looking for some guidance as to how best to debug this issue because I have completely run out of ideas. I didn't think that it would be necessary to post all of the code that produces this problem, but if any is absolutely needed, just ask.
Thanks.
Unfortunately the Cascading part of the Cascading Style Sheets threw me off. I had another (let's call it 'hidden') reference to the parent of the iframe which caused the weird height calculation issue.
Funny that this only happened in my Ubuntu version of Firefox, though.
If you have a complicated layout structure, setting height of all divs to 100% may break the page layout. In this case I recommend using javascript to set the height of iframe to 100%. In my case I used JQuery, but I believe pure javascript DOM functions should also work. I set the height of iframe equal to parent div height:
$('#doc-preview iframe').height($('#doc-preview').height());
Here the doc-preview is an id of iframe's parent div.
Make sure to run this script after the page has been loaded.

SVG height incorrectly calculated in Webkit browsers

I have a issue specific to Webkit browsers (Safari & Chrome, on Mac & PC).
I'm using Raphael JS to render SVG data and using a responsive layout to scale the SVGs with the browser window. The SVGs are set to 100% width/height using JQuery. The containing elements have their widths set in percentages to maintain the ratios of the layout as the page resizes.
Trouble is Webkit doesn't calculate the height correctly, it adds extra pixels (sometimes hundreds) around the SVG image; which breaks the layout.
If you open the following link in a Webkit browser you'll see the green extra pixel areas. If you use the developer inpspector in safari you'll see the reported size for the SVG is bigger than the SVG displayed.
http://e-st.glam.ac.uk/simulationgames/svgheightbug/index.html
If you open the link in Firefox or Opera you'll see the layout as it should work (the green here is caused by margins I have deliberately set).
IE8 was having a similar problem which using height:auto fixed, but this won't work in Webkit.
Has anybody else had this problem? Anybody have a solution?
I think it may be a Webkit bug (checked the nightly build already, issue persists), but before I log it I thought check to make sure nobody else has a solution first.
svg { max-height: 100%; }
WebKit bug documented here: https://bugs.webkit.org/show_bug.cgi?id=82489
I also added the workaround to the bug tracker.
I had a similar problem for Safari. Case was that the svg width and height were rendered as dom element attributes (in my case width="588.75px" height="130px"). Defining width and height in css could not overwrite this dimension setting.
To fix this for Safari I removed the width and height information from the SVG file while keeping viewBox intact (you can edit .svg files with any text editor).
Git diff snippet of my .svg file:
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 588.75 130"
- height="130"
- width="588.75"
xml:space="preserve"
version="1.1"
I just set the height to a very large size in the svg to maintain the aspect ratio. Using 100% comes with too many problems. This works better for me because I did not want to use js.
Full props to:
http://www.seowarp.com/blog/2011/06/svg-scaling-problems-in-ie9-and-other-browsers/
width="1200" height="235.5"
It's hard for me to understand exactly what you want with your example, or what is not as you intend it. However, in general, if you are using a layout with percentage widths and height containers and you want content to fill those containers, you need to take them out of the flow (using position:absolute on the content and position:relative or position:absolute on the containers).
Here's a simple example that works find in Chrome and Safari:
http://phrogz.net/SVG/size-to-fill.xhtml
The #foo div has its height and width as a percentage of the body. It has a red background that will never be seen because the SVG is position:absolute inside it and set to fill it completely, and have a green background. If you ever see red, it is an error.
#foo, svg { position:absolute }
#foo { left:20%; width:30%; top:5%; height:80%; background:red; }
svg { top:0; left:0; width:100%; height:100%; background:green; }
<div id="foo"><svg ...></svg></div>
This is a known issue that has been fixed by the Chromium team with version 15.0.874.121. I verified this fix myself just today.
http://code.google.com/p/chromium/issues/detail?id=98951#c27
i know how to fix it, you have just to put this at the begining of your svg file: "preserveAspectRatio="xMinYMin none" it must be into svg tag like this:
Problem will be fix
As previously pointed out WebKit's scaling of SVG improved recently. It is still quite broken in the current Safari (version 5.1, WebKit 534), in my opinion. I did a few experiments and recorded my findings on my website:
http://www.vlado-do.de/svg_test/
In short: embedding svg with <object> works under most conditions in WebKit 535. For older WebKit I embed it in an <img> tag. That's fine if you don't want links inside your svg (but it does not work in older Gecko and strangely also is problematic in current Chromium).
I found that adding "position: absolute;" to the image element (if it's within a parent that's also absolutely positioned), which had my .svg being called, made the "height: 100%;" declaration become relative to its container instead of the page/browser/device.
Tested this on both Chrome and Safari (mobile webkit) for iOS 7.1, and it fixed my problem (the .svg file was going way outside of its container).
Hopefully this a somewhat reliable fix for others here who were having trouble. Worth a shot?
I was having a problem with Javascript returning incorrect "height" values for SVGs, and I found the solution was simply to run my script (the bit that needed to access the height) on window.load rather than document.ready.
document.ready fires when the DOM is ready, but images have not necessarily been rendered at this point. At the point where window.load fires, images will have been loaded (and thus the browser will be able to access their dimensions correctly).

Resources