Exported SVG file rendered differently in browsers - css

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.

Related

How to make SVG clip-path work correctly in Google Chrome?

I'm using an inline SVG together with CSS clip-path property to create a beveled corner on a div element.
On Firefox, the size of the beveled corner is correct. However, on Google Chrome, not only the size of the beveled corner is incorrectly smaller, but the size of the div element also become incorrectly smaller.
Here is the demo on jsFiddle.
How do I make Google Chrome works correctly with SVG and clip-path?
P.S. I know CSS generated content can simulate the beveled corner effect. But in my case, I have to use SVG and clip-path.
I had found the solution in this article. The solution is adding clipPathUnits="objectBoundingBox" to the clipPath element, and then change the value of the points attribute of the polygon element to percentage value.
Here is the updated demo on jsFiddle.
The previous problem was that Google Chrome incorrectly applies the clipping path to the document instead of the HTML element that references it. According to the aforementioned article, setting the value of the clipPathUnits attribute to objectBoundingBox makes the clipping path honors the boundaries of the HTML element that references it.
One thing that helped me solve this was adding a unique clip-path ID. This, along with the vendor prefix for webkit, helped me get everything working!
Example:
<svg>
(...normal svg stuff...)
<clipPath id="uniqueId" transform="translate(-0.01)">
<rect width="90.96" height="78" style="fill: none"/>
</clipPath>
...other svg stuff...
<g style="clip-path: url(#uniqueId); -webkit-clip-path: url(#uniqueId);">
</svg>
This was for multiple inline svgs and there must have been collision with the Adobe Illustrator-generated "clip-path" ID that the clipPath was given.

SVG in MSFT Edge sometimes goes invisible or distorts

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.

IE11 using svg as background-image fails

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.

html and body height confusion

I have this simple code:
<html xmlns="http://www.w3.org/1999/xhtml">
<body bgcolor="#000000">
</body>
</html>
Questions
Why I am getting html height 8px in Chrome and Firefox? HTML height should be auto (0px).
The body height is 0px, so why is the background color (black) filling the whole screen?
Before I answer your questions let me tell you that even browsers have their default CSS style which is applied to every webpage! (To give you more insight let's say these default styles are the reason why normal HTML Buttons appear differently in Chrome, Firefox and IE)
Now for your first question: As per browser's default CSS HTML has padding of 4px! That's why you are getting HTML height 8px.
Now you must be wondering how to get rid of them? So for that we can use Normalize CSS
Now for your second question: you can say BODY is the special case tag which has a exceptional way of rendering it's background! (Or say it's not like a normal DIV tag)
In the absence of a background on the html element, the body background will cover the page. If there is a background on the html element, the body background behaves just like any other element.
You can read more about it here
Hope you found your answers.
You have a line break:
<body bgcolor="#000000">
^---- here
</body>
which gets rendered as a space character, causing you to have an implicit single line of text in your page.
If you look at the page using Chrome devtools, you'll see that the 8px height is coming from the user-agent stylesheet; that is, browsers apply their own default styles.
One common technique to wipe this away and start from a 'clean slate' is to use one of the many css reset libs.
See here for some options.
You are getting margin as 8px, not the height. Each browser has some default settings that's why you are seeing that. Check out the default settings for each browser using the below links:
Firefox
Webkit
IE

Mozilla vs Chrome Div width issue. Counting vs not counting borders?

Hey guys I am having a small issue with an assignment. I have to create this page and it looks great in Chrome but every div cell renders one pixel smaller in Firefox, I believe it has something to do with border width. Is there a work around or something I am doing wrong?
I am using a CSS reset, and I have declared my doc type.
Should I have just built this page using tables instead? Sorry no link to published code, also when I place the code in the code block it still displays the HTML.
https://docs.google.com/file/d/0B8uifJLGRXapcHF1VzRNNGo1b2M/edit?pli=1
Thanks in advance.
Try using CSS outline that will also work. An outline is a line that is drawn around elements (outside the borders) to make the element "stand out".
However, the outline property is different from the border property.
The outline is not a part of an element's dimensions; the element's total width and height is not affected by the width of the outline.
ie.
.example {outline: 1px solid pink;}
Try using the box-sizing property in CSS to fix this problem. box-sizing:border-box; will render the border and padding inside the actual width and height of the element. For a better description check this http://css-tricks.com/box-sizing/

Resources