I've been unable to solve stuttering in Chrome/Opera when using transitions - e.g. opacity, transform, filter etc.
For simplicity, I will focus on opacity.
Live example here:
http://www.lydkontoret.dk/index.php?pgId=20&pgName=Lyd+%26+lys
When you click on one of the pictures below the banner, a large version is displayed. I do this by adding a fullscreen div on top of page to prevent access to page elements. The div is faded in via transition on opacity. On top of this div is added further divs that holds the image.
Notice the opacity transition for the fullscreen element when clicking on a picture. On a 24" monitor with browser window maximized, chrome/opera stutters like crazy, while firefox/msie/msedge is reasonably smooth.
To complicate matters, Chrome/Opera performs ok when browser window is smaller - as rendering engine apparently is able to cope.
I've tried using will-change and translateZ(0) on the various elements involved, but chrome just doesn't care (removing the banner helps a lot - as expected, because the rendering engine then has less to deal with).
Also it's mostly the fade in that stutters. When closing the image display, transition on fullscreen element back to fully transparent often looks acceptable.
I figure my coding is ok, as Firefox etc. do the various transitions nicely. So why the problem with the blink engine used by chrome and opera?
Any thoughts??
I would like to achieve the above. The image is clipped, then there is a surrounding border around the image, which is clipped as well. I have actually done it for Chrome and Firefox using CSS clip path - http://staging.web2-hk.redantdev.com/plukka-html/about.html
The clip path property for complex shape isn't supported in any IE - http://caniuse.com/#feat=css-clip-path.
I would like to know another technique to make this work in IE Edge at the least.
I used vw values for height/width of elements, Chrome displays them right, but it looks completely different in Opera. Black background elements.
I guess you don't need any css lines, because you can pretty much see it by yourself:
http://meanwhile.today
What can possible be wrong? Do I need to use additional css for Opera?
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).
I am pulling my hair out on this one.
We're just about done with the development of an overhaul to our site. As a last step, we're trying to wrap up all the glyphs and icons into a sprite. They're all transparent .png's so the sprite is too. It appears that if a background comes from a sptire, IE distorts it. If it comes from the original file, it does not. FF and Chrome are fine either way.
I am looking at the orignal image and the sprited version side-by-side with grids to see that the pixels are identical. I have counted the pixels in the sprite many times to ensure I'm using the right coordinates. My CSS looks like this:
XXbackground: url(sprite.png) no-repeat 0px -837px; /* lozRedRedSpacer */
background: url(lozRedRedSpacer.png) no-repeat;
The 'XX' lets me toggle back and forth. With the single-file version, it looks perfect: . The sprite-version looks like this: . It looks like it is 'squished' both vertically and horizontally. This does not happen in FF or Chrome.
Any ideas?
EDIT I was able to strip out most of the noise and post an example here. I've added notes to the example to describe my problem.
Thank you so much for taking the time to look at this!
UPDATE We've since replaced these 'overlapped divider images' with CSS pseudo-classes that REALLY do overlap and the zooming issue seems to have gone away. Of course now we have new problems - IE8 gets the z-order wrong and IE7 doesn't understand psuedo-elements at all. But at least the markup is simpler and the zooming issue is gone.
It turns out my problem was caused by IE's 'zoom' feature. Without any zoom, everything looks great like the other browsers. Even 150% or 200% looks good. But 125%, where I had it, causes this distortion. It happens in IE7 and IE8.