I'm facing a weird problem with Internet Explorer 11 running on Windows 10 machine.
Using an SVG image as background thats appears totally black, Edge with the same code works fine.
Here a little fiddle reproducing my problem
Using this, Edge renders SVG rightly, IE renders only a black image...and i can't understand such a different behaviour!
Furthermore, on a Windows 7 machine IE11 works fine!
Some ideas?
Thanks in advance guys!
.icon-user-default {
width: 128px;
height: 128px;
background-image: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPCEtLSBHZW5lcmF0b3I6IEFkb2JlIElsbHVzdHJhdG9yIDE5LjEuMCwgU1ZHIEV4cG9ydCBQbHVnLUluIC4gU1ZHIFZlcnNpb246IDYuMDAgQnVpbGQgMCkgIC0tPgo8c3ZnIHZlcnNpb249IjEuMSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeD0iMHB4IiB5PSIwcHgiCgkgdmlld0JveD0iMCAwIDgwMCA4MDAiIHN0eWxlPSJlbmFibGUtYmFja2dyb3VuZDpuZXcgMCAwIDgwMCA4MDA7IiB4bWw6c3BhY2U9InByZXNlcnZlIj4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KCS5zdDB7ZmlsbDojODI3OTc3O30KCS5zdDF7ZmlsbDojN0I3MjcwO30KCS5zdDJ7Y2xpcC1wYXRoOnVybCgjU1ZHSURfMl8pO2ZpbGw6I0Q5QTc4Qzt9Cgkuc3Qze2NsaXAtcGF0aDp1cmwoI1NWR0lEXzJfKTtmaWxsOiNGMUYyRjI7fQoJLnN0NHtjbGlwLXBhdGg6dXJsKCNTVkdJRF8yXyk7ZmlsbDojRTZFN0U4O30KCS5zdDV7Y2xpcC1wYXRoOnVybCgjU1ZHSURfMl8pO30KCS5zdDZ7ZmlsbDojRUFDMEE3O30KCS5zdDd7ZmlsbDojRjJEN0JDO30KCS5zdDh7Y2xpcC1wYXRoOnVybCgjU1ZHSURfMl8pO2ZpbGw6IzJGMzQzQTt9Cgkuc3Q5e2ZpbGw6I0EwQjJCRTt9Cgkuc3QxMHtmaWxsOiNGRkZGRkY7fQoJLnN0MTF7Y2xpcC1wYXRoOnVybCgjU1ZHSURfMl8pO2ZpbGw6I0ZGRkZGRjt9Cjwvc3R5bGU+CjxnIGlkPSJiYWNrZ3JvdW5kIj4KPC9nPgo8ZyBpZD0iT2JqZWN0c18xXyI+Cgk8Y2lyY2xlIGNsYXNzPSJzdDAiIGN4PSI0MDAiIGN5PSI0MDAiIHI9IjMyMS4xIi8+Cgk8cGF0aCBjbGFzcz0ic3QxIiBkPSJNNzIxLjEsNDAwYzAtMTc3LjMtMTQzLjgtMzIxLjEtMzIxLjEtMzIxLjF2NjQyLjJDNTc3LjMsNzIxLjEsNzIxLjEsNTc3LjMsNzIxLjEsNDAweiIvPgoJPGc+CgkJPGRlZnM+CgkJCTxwYXRoIGlkPSJTVkdJRF8xXyIgZD0iTTcyMS4xLDQwMGMwLTE3Ny4zLTE0My44LTMyMS4xLTMyMS4xLTMyMS4xQzIyMi43LDc4LjksNzguOSwyMjIuNyw3OC45LDQwMAoJCQkJYzAsMTc3LjMsMTQzLjgsMzIxLjEsMzIxLjEsMzIxLjFDNTc3LjMsNzIxLjEsNzIxLjEsNTc3LjMsNzIxLjEsNDAweiIvPgoJCTwvZGVmcz4KCQk8Y2xpcFBhdGggaWQ9IlNWR0lEXzJfIj4KCQkJPHVzZSB4bGluazpocmVmPSIjU1ZHSURfMV8iICBzdHlsZT0ib3ZlcmZsb3c6dmlzaWJsZTsiLz4KCQk8L2NsaXBQYXRoPgoJCTxwb2x5Z29uIGNsYXNzPSJzdDIiIHBvaW50cz0iNDQ3LDU4NC4xIDQwMS4xLDY5NS41IDM1Myw1ODQuMSAzNTMsNDgxIDQ0Nyw0ODEgCQkiLz4KCQk8cGF0aCBjbGFzcz0ic3QzIiBkPSJNMzUzLDU0Mi40YzAsMC0xMDAuOCwxMy4xLTExNCwyNi44Yy0xMS41LDEyLTM1LjQsMTI2LjctNDAuOSwxNTEuOWMxNTcsMCwyMDIsMCwyMDIsMHYtNjAuNUwzNTMsNTQyLjR6Ii8+CgkJPHBhdGggY2xhc3M9InN0NCIgZD0iTTQ0Nyw1NDIuNGMwLDAsMTAwLjgsMTMuMSwxMTQsMjYuOGMxMS41LDEyLDM1LjQsMTI2LjcsNDAuOSwxNTEuOWMtMTU3LDAtMjAyLDAtMjAyLDB2LTYwLjVMNDQ3LDU0Mi40eiIvPgoJCTxnIGNsYXNzPSJzdDUiPgoJCQk8cGF0aCBjbGFzcz0ic3Q2IiBkPSJNNDAwLDE4NS45YzQ1LjcsMCwxMTcuOSwyNiwxMTcuOSwxNDcuNmMwLDcwLjItMjIuOSwxMTYuMi0zMi45LDEyOWMtOS4yLDExLjctNjAuOCwzNi43LTg1LDM2LjcKCQkJCUM0MDAsMzc2LjIsNDAwLDE4NS45LDQwMCwxODUuOXoiLz4KCQkJPHBhdGggY2xhc3M9InN0NiIgZD0iTTU0MC42LDM2Mi41YzItMTkuNC03LjItMzYuNy0yMC43LTM4LjVjLTEzLjQtMS44LTI2LDEyLjQtMjgsMzEuOWMtMiwxOS40LDcuMiwzNi43LDIwLjcsMzguNQoJCQkJQzUyNiwzOTYuMiw1MzguNiwzODEuOSw1NDAuNiwzNjIuNXoiLz4KCQk8L2c+CgkJPGcgY2xhc3M9InN0NSI+CgkJCTxwYXRoIGNsYXNzPSJzdDciIGQ9Ik00MDAsMTg1LjljLTQ1LjcsMC0xMTcuOSwyNi0xMTcuOSwxNDcuNmMwLDcwLjIsMjIuOSwxMTYuMiwzMi45LDEyOWM5LjIsMTEuNyw2MC44LDM2LjcsODUsMzYuNwoJCQkJQzQwMCwzNzYuMiw0MDAsMTg1LjksNDAwLDE4NS45eiIvPgoJCQk8cGF0aCBjbGFzcz0ic3Q3IiBkPSJNMjU5LjQsMzYyLjVjLTItMTkuNCw3LjItMzYuNywyMC43LTM4LjVjMTMuNC0xLjgsMjYsMTIuNCwyOCwzMS45YzIsMTkuNC03LjIsMzYuNy0yMC43LDM4LjUKCQkJCUMyNzQsMzk2LjIsMjYxLjQsMzgxLjksMjU5LjQsMzYyLjV6Ii8+CgkJPC9nPgoJCTxwYXRoIGNsYXNzPSJzdDgiIGQ9Ik0yOTcuOCwzNjQuNmg4LjFjMCwwLTUtMzEuNyw5LjYtNDEuOWMwLTE1LjgsMC0yMC41LDAtMjAuNXMtNS42LTAuNy01LjYtMjQuN2MwLTI0LjEsMjguNy00MS4yLDkwLjEtNDEuMgoJCQljMC0zNC4zLDAtODguMSwwLTg4LjFzLTEyMS4zLDIuNi0xMjEuMyw5MC42YzAsMzYuNiwwLDg1LjIsMCw4NS4yczguOS0xLjYsMTUuMiwzLjdDMzAwLjcsMzMzLjUsMjk3LjgsMzY0LjYsMjk3LjgsMzY0LjZ6Ii8+CgkJPHBhdGggY2xhc3M9InN0OCIgZD0iTTUwMi4yLDM2NC42SDQ5NGMwLDAsNC45LTMxLjctOS42LTQxLjljMC0xNS44LDAtMjAuNSwwLTIwLjVzNS42LTAuNyw1LjYtMjQuN2MwLTI0LjEtMjguNy00MS4yLTkwLjEtNDEuMgoJCQljMC0zNC4zLDAtODguMSwwLTg4LjFzMTIxLjMtMi44LDEyMS4zLDg1LjNjMCwzNi42LDAsOTAuNiwwLDkwLjZzLTguOS0xLjYtMTUuMiwzLjdDNDk5LjMsMzMzLjUsNTAyLjIsMzY0LjYsNTAyLjIsMzY0LjZ6Ii8+CgkJPGcgY2xhc3M9InN0NSI+CgkJCTxwb2x5Z29uIGNsYXNzPSJzdDkiIHBvaW50cz0iNDAwLDY2MC42IDM2OCw1NTEuNCAzNTYuMiw2MDAuNiAJCQkiLz4KCQkJPHBvbHlnb24gY2xhc3M9InN0MTAiIHBvaW50cz0iMzUxLjcsNTMxLjEgMzY4LjQsNTUyLjkgMzU2LjIsNjAwLjYgMzMwLjUsNTY1LjkgCQkJIi8+CgkJPC9nPgoJCTxnIGNsYXNzPSJzdDUiPgoJCQk8cG9seWdvbiBjbGFzcz0ic3Q5IiBwb2ludHM9IjQwMCw2NjAuNiA0MjguOSw1NTAuMSA0NDMuOCw2MDAuNiAJCQkiLz4KCQkJPHBvbHlnb24gY2xhc3M9InN0MTAiIHBvaW50cz0iNDQ4LjMsNTMxLjEgNDI4LjYsNTUxLjYgNDQzLjgsNjAwLjYgNDcxLjgsNTY1LjkgCQkJIi8+CgkJPC9nPgoJCTxwYXRoIGNsYXNzPSJzdDExIiBkPSJNNDAwLDQ0Ni43YzIxLjMsMCwzOC41LTcsMzguNS0xNS43aC03Ny4xQzM2MS41LDQzOS43LDM3OC43LDQ0Ni43LDQwMCw0NDYuN3oiLz4KCTwvZz4KPC9nPgo8L3N2Zz4K)
}
<div class="icon-user-default">
</div>
Make sure to set background size width and height
background-size: 80px 60px;
After digging into SVG file structure I found that problem concerns the SVG' styling properties.
Adobe Illustrator give me four options to declaring style sheet properties when saving graphics as an SVG file
Presentation Attributes
Style Attributes
Style Attributes (Entity Reference)
Style Elements
Accordingly to W3C specs regarding SVG1.1' Styling
No problem using the first three ways to styling properties, but embedding style sheets into SVG content inside a <style> element cause the problem!
Here my final fiddle test results
<div class="icon-user-default-css1"></div>
<div class="icon-user-default-css2"></div>
<div class="icon-user-default-css3"></div>
<div class="icon-user-default-css4"></div>
I hope will be of help to someone...
If, like me, you have inline SVG in your background
(e.g. <svg xmlns='http://www.w3.org/2000/svg'...></svg>)
You will want to make sure your encoding is charset=utf8 (e.g. url(data:image/svg+xml;charset=utf8,)
Also ensure that reserved URL characters are encoded (e.g. < === %3C and > === %3E) and you use single quotes ' around attributes.
I had this problem too.
In my case, changing the "styling" setting didn't help, but unchecking the "responsive" checkbox in the Illustrator SVG export dialog did, even with an internal CSS element in the SVG.
The difference is that the SVG element needs a width and height attribute.
These attributes are absent when you check the "responsive" checkbox in the Illustrator SVG export dialog. If that's really all it does, then it's poorly named, I think.
If you're using inkscape, or some other tool to make your SVGs, I am sure your observations, when added here, would be of value.
So, if you want SVG background images in CSS to work properly in IE, make sure the root element of the SVG has a width and height attribute. (e.g. by unchecking the "responsive" checkbox in AI).
The width and height attribute do not have to be the correct display size (which may change anyway, via the CSS background-size property), but they do have to be the correct aspect ratio.
If you are hand-coding the SVG markup, and the first two values for viewbox are zero, then you can just use the last two values for width and height respectively.
e.g.
<svg
id="Layer_1"
data-name="Layer 1"
xmlns="http://www.w3.org/2000/svg"
width="298.2"
height="108.8"
viewBox="0 0 298.2 108.8">
In my case, the SVG was also invisible most of the times I tried to load the page. But sometimes, it was loaded.
I noticed that if I add background: red then remove it, SVG would appear.
After converting the file to PNG, I noticed that it behaves the same way as SVG after adding and removing the background style rule.
So, I think Internet Explorer converts SVG to PNG, but sometimes it fails.
Related
I'm using this inside Angular if it matters, but for some unknown reason only in Edge.. as I move the mouse around on the screen the img will either distort and render with some of it missing, or completely disappear
thoughts?
<img class="my_image_class" src="img/My-Svg-ToRender.svg" ng-src="img/My-Svg-ToRender.svg">
associated CSS for this element is as follows.. I've tried setting no height and no width, setting height and width.. behavior doesn't change
img.my_image_class {
width: 100%;
-webkit-user-drag: none;
}
there is other parent CSS, but it looks like just margins, borders, padding
edit :
turning everything I can off, in CSS, I notice the svg will not render UNTIL I mouse over it.. I do not see any directives that could be modifying the svg's CSS and don't see any transformations occurring
I found some open issues on SVGs through Microsoft's feedback portal; it looks like a recent update may have negatively impacted SVG display in Edge (e.g., https://connect.microsoft.com/IE/feedback/details/2350665). Based on what I've read about this issue, it seems like text boxes are a common culprit.
My website displays a logo as an SVG containing text, and it renders without problem in Edge. However, before I exported my SVG from Illustrator, I converted all text to paths. I did this for a similar reason: I was having issues with SVG text display in Safari.
Of course, ideally, SVGs should just work in all browsers. And it seems like this issue is on the fix-list for Edge. But in the meantime, perhaps this workaround will help! Cheers!
I had my inline svg images disappear on hover. I had the following styling:
svg {width: 100%; height: 60px;}
The 'width: 100%' styling was intended to activate the hover styling as soon as the mouse entered the containing block element. This caused som strange behavior on the svg image. Mouse-in from top or bottom functioned as expected, mouse-in from left or right caused the svg to disappear. Removing the 'width' styling, solved the problem.
I'm having problems in understanding what causes this file to be rendered differently in browsers (Chrome: only axes visible, Safari and FF display the main content and axes).
It's a figure that has been exported from DC.js example page, first figure, using SVG-crowbar2.
Basically the Crowbar just looks for any external css rules applied to the SVG element and applies them as inline css. The question is what css rules cause the elements to be shown differently?
The issue appears to be cause by the #yearly-bubble-chart-clip > rect element. It has inline styles that set width and height to auto. In Chrome, this is overriding the width and height attributes, and resulting in a clipping path that is 0 pixels by 0 pixels.
If you remove those styles, like so, it will work in Chrome.
<rect width="888" height="198" transform="translate(-0, -0)" style="overflow-x:visible;overflow-y:visible;perspective-origin:0px 0px;-webkit-perspective-origin:0px 0px;transform-origin:0px 0px;-webkit-transform-origin:0px 0px;"/>
JSFiddle Example
Your chart-body seems to appear in Chrome if you remove the width:auto; and height:auto; from the rect in the yearly-bubble-chart-clip clip path.
Attempting to have three backgrounds with various z indices is resulting in only one layer being shown.
This jsfiddle has the relevant code and examples (minus the huge foundation css file... the behaviour is unaltered without it).
the classes that are failing are
skyline
and
#footer_container
whereas #header_container is running properly.
I've updated your fiddle here.
#footer-container wasn't displaying its background image because of your CSS syntax. Since you combined both the background image URL and no-repeat, you would need to use the background shorthand rather than the background-image property.
A great way to check this sort of thing is to inspect your element with your browser (in Chrome: Right Click > Inspect Element) and find the element that isn't displaying properly. You'd notice that the background image property of your #footer-container div was being literally crossed out by Chrome because of a syntax error.
There was also a bit of a syntax problem in your .skyline class. First, both your body and the inner div have a class of .skyline. This is kind of confusing so you should remove it or be more specific in your CSS, e.g. with p.skyline, div.skyline, etc. As you've got it currently written, both your body and that .skyline div will get the background image. You also didn't include a closing </body> tag. I'm assuming you don't want the background image on both that div and the body, so I removed your body tag in the updated fiddle.
Also, in your .skyline css, you have both height: 546 and height: auto. First of all, height in CSS should have a specific value (e.g. px, em, %). For an <img src="img.jpg" height="546" />, however, simply putting "546" as its height would be fine. Second, you should only have one height value per class.
The skyline problem itself is that you didn't close your curly bracket on line 126, so no styling at all was applied to .skyline. Once it's closed, there's still a problem. It has no width. So let's set it to 100%. Still nada. This is because .skyline's parent div#container also is widthless. So let's toss a 100% width at it too. Then we're in business.
A good text editor that highlights syntax errors could help you out a bunch, especially when you're just starting out.
I've seen some interesting css trick on vk.vom recently
background: url(/images/icons/mono_iconset.gif?8) no-repeat left -237px;
width: 15px;
height: 11px;
Here is this spritesheet: Spritesheet.
How is this works?
? has nothing to do here, its the left -237px which determines which icon to show.
It is the background-position: x y along with height that determines which part of an image needs to be shown.
More about css sprites http://cssglobe.com/creating-easy-and-useful-css-sprites/
Seems that the URL parameters have nothing to do with the spritemap itself.
Different heights, on the other hand, are handled by the height in the CSS you provided. Moreover, the y-offset determines which icon will be used.
The URL parameter is probably inserted to avoid problems with caching when deploying a new version of that stylesheet. If you append something using the query string (like ?8), the browser will be tricked into thinking this is a whole other file, so it will discard the cached file and download the new one instead.
The "trick" you are looking for is a CSS sprite. Basicly, every icon is loaded into a single image and the icons in the sprite are used as a background image for a fixed-width container (like an anchor with display: block; or a div). Then, when playing around with the backgound-position property, different parts of the sprite will be visible.
Read more about CSS sprites in this article.
Is there a CSS hack/technique to take an <img> element (with no other markup) and hide the pixel content of the image while still displaying it as an element with background color and stroke?
For example, take an <img src="foo.jpg"> on the page and make it a 32x32 badge of solid color.
Though I am interested in browser-specific hacks (does Webkit have a solid-fill effect?) or CSS3 awesomesauce (is there an image-content-opacity:0.0?), I need a solution that works on IE8+, FF4+ and thereabouts.
If you are interested in the motivation for this question, see the edit history of this page. It has been removed because it was distracting users into helpfully trying to find workarounds to solve that problem instead of answer this question.
Hide the image and use the background filled with a solid color.
Example here http://jsfiddle.net/notme/ZUvHN/6/
This is a take off of my comments above and notme's solution:
http://jsfiddle.net/ZUvHN/7/
What I did was I removed display:table-cell from the a and then set it to display: block
I then set the img to display: none
This lets you then apply the border and background styles to the a tag instead of the img tag. You'll likely have to tweak the margins and spacing a bit.
I don't know if you have the option or not, but it might be easier to tweak the HTML a bit via JavaScript.