When embedding html inside of SVG using the foreignObject tag, webkit based browsers render the backgrounds of the embedded html elements behind the svg elements. See http://code.google.com/p/chromium/issues/detail?id=35545 .
Here's an example : http://www.mxgraph.com/demo/markup/webkitbg.html
The green div should be on top of the red.
Does anyone know of a workaround for this issue? Maybe some incantation of z-index and/or grouping of elements or something in svg to fool webkit into doing the right thing?
This is webkit bug 58417, fixed on 2011-11-10. The fix is in Chromium version 17, which is currently in beta as of 2012-01-09, and should be released in early February. Not sure when the fix will land in Safari, but luckily I don't need to support it.
So the workaround seems to be "wait a month"...
I've just been hit by the same issue. Even though the bug is fixed since a long time in Chrome, Safari seems to be ages behind with the codebase.
My solution is to add style="display:inline-block" to the first child of the foreignObject tag. This seems to fix the problem.
Related
I am displaying a set of properties on Bing map. It works all fine in Chrome, FireFox, IE, and Safari on Windows (version is 5.1.7 - their latest version for Windows). But it doesn't work in Safari 7 on Mac.
When displayed correctly, all properties are located on a green residential area. But on Safari 7, all properties are displayed on the far left of that area - on a totally wrong location. Also, the larger left part of the map is blank (there is no map!).
I saw a similar post Bing Maps Issue on Safari 7. The left part of their map is also blank. The problem there seems not solved. I followed Microsoft's guideline (meta, CSS position/width/height etc), none of them work.
I suspect that's a Bing bug? Or a Safari bug?
Sorry I don't have enough reputation to post images...
Now that I solve the problem, I confirm that this is NOT a bug of Safari or Bing.
the <div> that load the the map is embedded in many other divs, panels, fieldset, Telerik ajax panel, RadTabStrip etc. You have to remove some of divs, and also some styles of divs to make it work. It's tricky, you have to do many tests to finally pin down which element caused the problem and remove that element.
I took me several days to figure this out.
Having a bit of a conundrum with cross-browser compatibility and could use some help.
Our live version linked to below, seems to work perfectly fine on most browsers, including IE9+, but the controls appear hidden in a non-emulated stock out-of-the-box version of IE8:
http://dig-houston.com/portfolio/inspiron
Here's a screenshot of what it looks like in IE8:
At one point, I was still able to slightly see the controls sticking up from the bottom (and click) which lead me to believe something had gone awry in absolute positioning or the rejection of newer CSS techniques. But as my fine tuning progressed and heights were adjusted, I believe the controls were hidden further out of view outside the box.
That being said, I think this is just a CSS issue, but haven't targeted the right styles being applied yet. To anyone else out there using Video.js
when testing my website using Opera Mobile, I discovered some serious problems which I've no idea why they happen and how to fix them.
Here's a comparison between FF (Windows) and Opera Mobile (FF renders as expected):
Here's the jsfiddle with the source
Here are the differences:
1st image looks weird.
4th image disappeared.
Images has partially/missing border-radius.
box-shadow is missing.
I'm pretty sure that the box-shadow and border-radius are the main cause for the problems, because when removing them everything looks fine.
I would like to know why it occur and how to fix it....
Thank you very much!
When you are removing opacity does it work better? It seems there is a very unfortunate bug mixing box-shadow and opacity. And it is tracked by CORE-39908 at Opera. I will add your example jsfiddle example to the bug report.
I'm having a problem with Twitter Bootstrap Inputs showing correctly on safari 6.0.
Im pretty sure this was fine before I moved to Mountain Lion, and it does seem to be an issue with Chrome.
Basically in Safari, the right end of the input seems cut off an is not displaying correctly. Ive taken a screen shot to demo what I mean...
Safari:
Chrome:
Any ideas?
EDIT: Just looking at the Twitter Bootstrap site and I see that alot of their inputs have the same problem!
Anyone else seeing this?
The artifact appears to be an issue with Safari's rendering of border-radius, and is not specific to Twitter Bootstrap. See rendering borders on Apple's support forum. The inputs usually render normally after you select them.
Disabling border-radius on the affected elements with the following two lines removes the artifact. Be careful though, sometimes this causes even more puzzling artifacts on nearby buttons.
-webkit-border-radius: 0;
border-radius: 0;
I'm having a problem with layout in Safari that works fine in Chrome and FF. It seems that Safari includes the padding within the width while Chrome and FF don't. So what's 630px in FF
due to width + padding is only 600px in Safari. This: Padding in mozilla firefox and in safari seems to show that the box model is different in Safari. If so I would expect a standard solution would already have come up but when I google this, it seems that hardly anyone has this problem.
Is the box model in Safari really different and is there a standard solution? Or do I just have to 'debug' my CSS?
EDIT: apparently it's because the div was using display: table. When I changed it to display: block, it worked as expected. It's still strange though because it's working fine in other browsers (display: table).
Which doctype are you using? When I use < !DOCTYPE html > (the HTML5 doctype declaration) Safari and Chrome's padding behaviour is definitely exactly the same, and as the standards dictate.
In CSS box-sizing handles the box model. By default it's set to the 'normal' but probably incorrect 'content-box'. Support for box-sizing is reasonable across browsers now so you can probably move to 'border-box' but will need to handle it differently in IE6/7 (if you support them).
AFAIK Safari (webkit) should respect this.