SVG bg-image doesn't work well with safari - html

I know there might be plenty of other topics about SVG background-images and browser compatibility, but i really can't find out any solution to my problem. I'm using Foundation 5.
So, I've got three divs in a row. Each div has a svg as a bg-image.
See, on Chrome, works perfectly:
Chrome capture
The svg background isn't the bubble itself but the surrounding, that I filled with blue ( so bg-color is white ).
But if I go on Safari, there is a small white line on the border of my divs : Safari capture
I'd like to get rid of this white line on safari. I mean, I want my row to display as in Chrome. So, I know background images width in safari are set in px, and that mine are set with %. But I don't really think it has something to do with it. I really have no idea of how I can resolve this.

Related

CSS rotation animation breaks in Safari

I stumbled upon a weird behaviour in Safari today, and I cannot figure out what causes the problem.
When creating an animation that rotates an SVG element in a certain pattern, with everything working perfectly fine in Chrome, Safari only shows half the SVG on every animation step.
When I remove the background-color: white; from the .container element, everything works fine. How would a background color be causing such a behaviour?
Here's a demo video as well as the corresponding JSFiddle:
JsFiddle: https://jsfiddle.net/04zgmbup/
Chrome (expected):
Safari (unexpected):
Okay, so apparently I got this problem figured out.
Safari seems to be handling the container background as a plane.
This means that when the item rotates, one half will always get rotated behind the container, which has a white background color which covers the element itself.
I still do not know why other browsers do not behave like this.
A possible solution for Safari could be to translateZ(width /2) the element, so that all rotations happen in front of the background plane.
Here's the updated fiddle, working in Safari:
https://jsfiddle.net/04zgmbup/1/
The problem can be visualized nicely by giving the container a semi-transparent background color. In the below recording, one can clearly see that half the circle gets rotated behind the container.

Firefox CSS and/or D3 difference

So I've got a page on a site that displays exactly like it should in both IE and Chrome, but not Firefox. The link is http://www.jakerevans.com/?page_id=61. In both IE and Chrome, the spinning animation (written with D3.js) displays fully through the padding-left and padding-top, but not in Firefox. Anyone have any idea how I can make this padding in Firefox transparent? Any other possible solutions? I'd really like to resolve this through CSS if possible, and not go back to the drawing board with the D3 code. Obviously I will if I have to though.
Thanks a lot for the help!!!
You need to explicitly set overflow: visible on your <svg> element.
The SVG specifications state that all SVG elements that create viewports should have overflow: hidden in the browser's default stylesheet. However, browsers disagree over whether this should include the padding area or not: if you follow the description in the SVG specs, as Firefox does, padding would not be included. However, general CSS/HTML layout does not consider content in the padding to be overflow, so Webkit/Blink/IE browsers do not clip it with overflow:hidden.
it doesn't seem to be the issue of the padding, it's like to be the firefox transform origin thing, see this Setting transform-origin on SVG group not working in FireFox

Background-gradient with hard stop renders incorrectly in Chrome

I have a html layout with a navigation bar at the top and a main content area below it, with a left and a right area. The top bar has a background gradient with a hard stop in it. The main content's right area (sidebar) has a background color that should line up with the gradient stop of of the navigation area, at 75%.
See this for a simplified version of my layout. In Firefox and Safari this renders fine, but Chrome puts the gradient stop a little further than it should. I tried to use pixel values instead of percentages, but the behaviour stayed the same.
Any idea why this is happening, and suggested workarounds? Thanks!
Specially with modern browsers that deals with anti-aliasing in so different ways. What i have done was a js fix, (which wouldn't be good for your code :D) also you would have to add a custom padding for each element. But you'll need to hire a freelancer to do it for you, because it would take a while to complete (browser targeting, getting each element, adding padding for each element...)
if u can post the code it would be simple for more possibility.however i am looking for more solutions.

Crazy CSS Issue in Firefox Only - position fixed and background color

See this link:
http://lsp2.tpdserver2.co.uk/test.htm
Displays fine in IE/Chrome but in Firefox (6.0.1) there is a 1px border around the blue header.
If I add a background color to the #header-content, the 1px white border dissapears. This seems crazy.
I cannot work out what is going on with this and the related page I am trying to build depends on not having a background colour for the 2nd fixed container.
Here is an image of the problem I see:
Link to Image
It is layout rendering bug in Firefox. This bug was already reported and as I know it is fixed in next release. Only solution I know is to use opacity:0.9999999. It would render correctly as opacity:1, but fix this annoying bug.
Try #header { opacity:0.9999999; }
Bugzilla : Bug 677095
EDIT: Firefox 8 is not affected with this bug and setting opacity to 0.9999999 will result in weird border around the element, so I prefer not to use it anymore
Browsers add different defaults if you don't "reset" the CSS, that may be what is going on here.
If the z-index value of your #header-content is not greater than 10, then the bug is fixed. If it's 11 or greater then I can see the mysterious gap too.
Really weird.
I cannot reproduce in FF 6.0.1; however, you can probably work around this with
background-color: transparent;
on the #header-content, or white if you don't want it being see through.
This should still give the fix you mentioned while remaining a blank div as required.
Update:
Ok thanks for the screenshot, still cannot reproduce, this time with ff 6.0.2 - I had a look around after noticing I can reproduce a similar issue on different zoom levels.
Blog post explaining the zoom border bug, which includes this test page. I am not sure if this is involved, seems similar but not the same thing, zoom bug will take off a slice of the whole page including the border of #header-content.
As for your comments around transparent, you can use it and still supply a background image, does this not work for you?

css border radius bug in chrome with percentages

Hi I'm having troubles with a problem in chrome. I think it might be a bug but I can't find much info on it. Basically I want to apply border radius on an image. The border-radius will be 50% forming a circle. The reason I've set it as a % is because i wont explicity know the width/hieghtt of the image.
Any ideas why chrome doesn't display the border correclty? I haven't tested in FF < 4. but FF4 works well as does IE for a change
What are you trying to do? Do you want a circle to appear behind the image? That is what I see in FF. In Chrome, the circle is clipping the edges of the image.
According to the spec -- http://www.w3.org/TR/css3-background/#corner-clipping -- content is supposed to be truncated.
The content of replaced elements is
always trimmed to the content edge
curve.
Which, to me, means that Chrome is following the spec correctly on this.
Webkit doesn't currently clip corners of images. Remove the src tag from the image and you'll see that the border is being rounded correctly.
One workaround is you could set the background-image property in css: http://jsfiddle.net/tEzwJ/
I figured out a way around it, by adding the border and the border-radius onto the parent . I then applied the border radius to the image too. Although there is a minute gap It works in chrome now. I haven't tested it in FF3.6. But FF4 displays the same result