I'm currently working on a page which has a series of svgs on it, created dynamically using (the frankly amazing) d3.js.
Everything is fine, except I'm getting a weird issue in Safari (Version 9.1.1 (10601.6.17) on Mac OS X (Yosemite, repeatable on El Capitan with latest Safari 9.1)) whereby things are misaligned. I have two svgs right next to each other which for all intents and purposes have all of the same margin, padding etc. definitions, yet one of them sits properly (with 14px of padding-top), whereas the other (in theory also with 14px padding-top) seems to completely ignore this padding and sit 14px higher. As can be seen in the below images, I've used Safari's built in developer tools, and the padding does seem to be correctly defined, it's just decided not to care.
compared to:
It's worth noting that this issue repeats for as many of these svg-pairs as I have, so it's not just happening in a single instance (in both images you can see the same phenomenon recurring).
Another weird / interesting element of this is that when I zoom out (using ⌘ + ⇧ + -), the issue seems to resolve itself. This only occurs at the default zoom level.
Any help / pointers are greatly appreciated. I wouldn't describe myself as a front-end developer in any meaningful fashion, I'm really doing this due to necessity, so it's entirely possible I'm doing something very very silly.
This all works perfectly on Chrome.
After following up on olivier's suggestion, I was fixing some non-integer widths / heights which unfortunately didn't work, but while doing that I was looking at the padding and decided to try tweaking it. Long story short, apparently Safari was throwing a fit because of the svgs attempting to perfectly touch. Having padding-right as 0 on the left-hand svg and padding-left as 0 on the right svg seemed to be the issue. The fix was to set both paddings to 0.02px (seems to be the lowest I could go without it giving trouble). This leaves a very VERY subtle seam between the two svgs, but obviously this is a vast improvement on misaligning them.
Related
I recently updated to Safari 7.0.2 (comes along with Maverick) and noticed a significant change on colors on my webpage. Namely the grey tones are darker and the css generated gradients show ugly steps, no longer fluid. Colors with Chrome under Maverick are still the same, no longer comparable to Safari. So I have to define different CSS colors to have the same results on Chrome and Safari? Weird. Never had this problem of different colors not even among other browsers (Firefox and so on, all the same)
www.stefanseifert.com
Maybe I’d have to add that I am using a custom monitor color profile.
Edit:
Thanks Unmut for your quick answer and your interest! What you showed me is interesting, in fact I didn’t know about this. Leaned something. Unfortunately, yet, this is not the case here. First because it isn’t about the colors within images but about the ones defined by css. (which is very very bad in my eyes)
I will try to attach 3 pics to explain. Second, yes, the difference is not big but it is significant enough for me as a designer. On the bigger pic you see 3 screenshots. The grey color as I defined it in css should be #787878. All browsers display it correctly (as also Safari did before Maverick!) Safaris grey now is deeper.
color_difference http://www.stefanseifert.com/Color_difference.png.
And what’s even worse are the gradients created in css (plus transparency) that show very well on all browsers (as in the first pic), but with slightly visible scales in Safari (also NOT so with Safari before Maverick) as in the last pic.
gradient_1 http://www.stefanseifert.com/gradient_Chrome_andOthers.png.
gradient_2 http://www.stefanseifert.com/gradient_Safari_7.0.2.png.
I retain this a serious problem. All around I read about Mavericks improvement of color, for me this is a great disadvantage for it doesn’t give reliable # css colors. Someone with help?
I figured one problem out, at least. I work with a customized own color profile on my iMac. And it seems that this creates the confusion. If I turn to the standard iMac profile all browsers look the same and the screenshots give the right hex color values. Yet, this is what I don’t want to do. So no real solution here for me. Somewhere I read that it depends on srgb that are not used by Safari 7, don’t know if this is true but it maybe a useful hint for someone.
For what regards the less fluid css gradients, another problem that remains. New Safari is bad at this! Much more preferable Google Chrome now, but the sad thing is that one can’t force users to use Chrome instead of Safari. All standard Mac users will use Safari I am afraid.
Second I observed performance problems in Safari with complex css transitions. It helped a little force elements around to hardware acceleration or introduce back face visibility hidden all over the place, but this is not very satisfying and good part of the lousy performance remains even with it. I thought Apple wanted to better performance of its browser, but for me it seems worse now. Everything was just fine with Safari 6 and css transitions instead. A petty.
I think it has got a problem about Color Rendering & Color Profiles.
Why don't you check these links:
http://css-tricks.com/color-rendering-difference-firefox-vs-safari/
http://www.color.org/version4html.xalter
http://news.cnet.com/Safari-ushers-in-better-browser-colors/2100-1012_3-6191815.html
Note: I checked it Mac OSX Mountain Lion, Safari 6.03 and i didn't see big difference.
I found this:
Apple Safari Safari supports both v2 and v4 ICC profiles.
Unfortunately, it has no control over color on other page elements.
Tagged images look right, but every other page element has
over-saturated colors on a wide gamut LCD.
on
http://cameratico.com/guides/web-browser-color-management-guide/
Seems that Safari forces the webpage to use the full range of Monitor LCD while others like Chrome don’t. So if you changed your monitor color profile it is ignored by Safari or at least differently managed.
If you could influence on the way Safari interprets images color by tagging the images this is not possible with the rest of the elements as divs defined by CSS values.
I've noticed some strange behavior with both Chrome and Safari on my Mac:
Mountain Lion
Safari 6.0 (8536.25)
Chrome 21.0.1180.89
The page is a simple fixed div with some text in it, I added a second div that does a simple CSS translation over 5 seconds so you can easily see the difference. My web app is using CSS transitions to show and hide portions, and while it was doing this large portions of the screen seemed to shift.
I've placed example code and a .mov file out on a server so hopefully you will see the same issue:
http://physicaltable.com/index.html and http://physicaltable.com/CSS_JIGGLE_TEST_2.mov
The strange bolding doesn't occur in Chrome on Windows 7, nor does it happen on the iPad 2 (v5.1.1)
Has anyone else seen this type of issue?
I realize this isn't much of an answer, but I've found that it's mostly because of the rendering of the elements. If the element needs to use hardware or any other type of graphics rendering, it basically takes an image of the text, adjusts it, then rerenders the text (if it can).
The "taking a picture" is where the boldness is lost, since the browser/display/something is adding the flair that makes the text look good. Of course it doesn't look that good, but that's just me.
I've noticed with different colors other than all white/black, it can behave differently. I'm hoping things will get smoothed out as browsers and rendering advances.
I found solution for this bug
its enough simply force your browser to rerender that at moment move is stopped
E.g.
$("your_element_selector").css("color", "color");
where color can be even same color as your text has
One of my clients presented me with a page that's not displaying properly and I can't figure out why. The URL of the page in question is http://www.honeysucklehillfarm.com/fun-farm and if you view the page in Firefox (and IE, amazingly) it works fine, but in Chrome the three sets of rotating images are much smaller and squished together. From what I can tell, Chrome is changing the inline style (set by the jQuery rorator, I assume) of the DIV "views_slideshow_cycle_teaser_section_food_on_the_farm_shows-block" to 45px x 46px instead of the 180x185 shown everywhere else.
Does anyone have any idea what could be causing this?
Thanks in advance!
In http://www.honeysucklehillfarm.com/sites/all/themes/hshf/styles/style.css?m6v7zv, line 383 you have the code: width:11.375; This width is invalid, it should be either px, em or % value.
As j08691 said, you should consider fixing the errors & warnings that come up, but without investigating for a long time, these kinds of errors might be your problem.
Why are there so many nested <div>'s though? That seems to be an excessive amount, which is screaming for errors to occur..!
I have built a CSS layout for a page that appears to work in tested browsers thus far and has previously validated CSS and HTML.
Randomly though, the layout breaks and divs move as if they lost their floats. The breaks occur in Firefox 4 and IE8 for sure so it's not browser specific. There have been at times four divs that have moved but at other times only one — so it doesn't break the same way every time. The breaks typically happen after a period of time away from the site and are fixed with either one or two refreshes. The breaks cannot be triggered with an empty cache/cleared browser history. The breaks happen whether the header is on the actual page or as an include. The breaks happen probably one time out of 20 — but it really seems like it's more about the time passed between page loads than about anything else. I am not understanding how this could purely be a cache issue since I cannot recreate the issue when I delete the cache.
Originally, another forum answer said that it was the use of #fontface but today I saw the layout break in IE8 and Firefox with the 2 #fontface fonts loaded....so it is only the layout that broke while the fonts loaded. So I am not sure if that is the issue. The layout is built to work even if the #fontface does not load.
Here is the link to the site that breaks - http://rg.isolatedfilmproductions.com. Screenshot:
Broken layout as seen inIE8 http://rg.isolatedfilmproductions.com/img/css_not_loading.png
The site is on a shared Apache server. My internet speed is 12mbps cable using Windows Vista laptop.
Set the widths of the two divs explicitly, navigation_menu_container and company_name_container and ensure that they're less than 100% of the parent window size. IE has issues with size plus margin and padding (and the box model in general) and it almost always rears its ugly head when floating two elements.....resulting in an element being bumped down.
This is the reason that I enjoy using 960.gs....no need to worry about box model messes on IE.
As an aside, the font is pretty choppy looking on Chrome....
After fiddling around with an issue I am having I have come to this conclusion:
my list Elements are displaying smaller in Safari on my Macbook than they are on Safari on my PC. IE, and Firefox are displaying properly also.
What might be causing this difference? It is hindering my ability to complete this design.
www.christopherbier.com/gbg
Please let me know if there are any css tags that might be causing this.
Here is my previous question that includes my css etc. CSS spacing issues with Safari?
Any help is appreciated.
You might want to consider including css reset stylesheet. You can find a good one here:
YUI CSS Reset
This basically "removes and neutralizes the inconsistent default styling of HTML elements, creating a level playing field across A-grade browsers".
Hopefully that will solve your problem!
My guess is that it may well not be a css tag that's causing the issue, but just a difference in defaults on the two different browser versions. Each version is probably tailored to the OS to some extent, and may look different, which is expected.
Overriding this default behavior should raise a warning flag, because you're changing the overall look and feel, and it may not match well with the OS layout in general. It doesn't mean don't do it, but it does mean that you might want to proceed with caution.