I've finished a site but it doesn't work well on Safari.
I used (don't blame me!) frames and two white weird spaces appeared on the left ant the right of the frame "body"
you can se the result here:
http://www.yves-ratheau.com/
I didn't find any help on google, forums, etc...
thanks to any suggestion
Since I'm installing windows on my main Mac, I grabbed a really old laptop (Powerbook g3/safari4.04 on OS X 10.4.11) to test this and didn't get any white lines anywhere. What safari version are you using to test?
You may need to set some CSS padding/margin/border styles to "none" to have it work in older versions of Safari, but I've never seen this problem before.
Related
Im a new developer, and I just finished my first site. Works fine in all browsers, except safari.
Unfortunately I didn't install a copy of safari while I was developing it, so these issues went unnoticed. I did check every other large browser tho.
Figuring, if it worked in IE it should work in anything else...
Please open up www.enniya.net in safari, and than in chrome or some other browser to see what I am taking about.
By looking at it I do have a theory.
The background, font, colors, transparencies of divs, border colors, thats all their, but the positioning is destroyed.
But the logo position is correct, so my first theory is that
90% of the content is positioned with vw and vh
while the logo actually uses % for positioning...
Except that the latest readings tell me the newest versions of safari understand VH and VW ??? So I dont know.
If you need to see my code let me know, I didn't provide it initialy because Im not really sure what specifically I could provide that would solve this problem.
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.
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;
This is working in Chrome but not in Safari:
background: -webkit-radial-gradient(center, ellipse cover, #fdfdfd, #d3d3d3);
How can I fix it for Safari?
It doesn't even work correctly in Chrome, as it shows a circular gradient, not an elliptical one. It does work correctly in Webkit nightlies.
The reason it doesn't work in Safari is that the syntax hasn't propagated yet to a stable version of Safari. Eventually it will. You need to learn patience my young padawan :)
For now, you may use -webkit-gradient, but always include the -webkit-radial-gradient equivalent after it. And while we're at it, don't forget the other prefixes too (-o-,-moz-,-ms-)
Try using for Safari:
background: -webkit-gradient( radial, <point>, <radius>, <point>, <radius>[, <stop>]* ) <color>;
Examples and more explanation can be found here: http://www.the-art-of-web.com/css/radial-gradients/
I've tested in Chrome, do I need to test in Safari?
I've noticed Safari handles Asian characters better than Chrome.
Also Chrome and Safari rely on the same Webkit for rendering pages, but their Javascript engines are totally different, so if you use Javascript in your pages you need to check both.
Browsershots will send you screen shots of your page in just about every browser ever made.
Safari uses 'mac' fonts, but Chrome would use 'Windows' fonts. I've noticed that there can sometimes be problems where using a font like Arial, it shows up fine in firefox/chrome/ie, but on Safari, it can cause a line to wrap because the font is slightly bigger.
Yes, but only for your fonts and JavaScripts.
I have noticed some of the default fonts are smaller on Safari then Chrome, also Chrome uses the V8 JavaScript engine which has caused some people problems, especially if you have a lot of form logic.
yes.
Oh, you wanted more detail? Simply, Chrome and Safari have a lot of different features in their implementations, and Safari is pretty widely used. If you expect the general public, and particularly those of us who work on Macs, to use your application, it would behoove you to test in the Safari browser.
Yes, safari and chrome even though they are using webkit the two versions of webkit that are being used are significantly different. So you need to restest.
In a word, No. You can't assume that because it works in one it will definitely work in all cases in the other. Sure, 99% of the time, it might be the same - but 99% isn't 100% - at least, it wasn't last time I checked. Call me a pedantic git if you like.