Horizontal CSS Nav Padding differences in Firefox,IE9 vs Chrome, Opera - html

I have a weird problem on a CSS menu. There's a difference in padding applied by both
Firefox & IE9 vs Chrome & Opera browsers. The space left after the last menu item at the end of the menu is different on both the browsers.
Please see the chrome.jpg and firefox.jpg inside zip file to see what I mean.
I have also attached the source html file.
here is the zip file -
https://www.sugarsync.com/pf/D6612639_7394829_952554
Chrome:
Firefox:

This is not padding but likely a difference in how the fonts are rendered in different browsers. Yeah that is pretty much impossible to solve unless you make the menu items fixed width. :)
The firefox version looks bolder (see it?!)... These are brainbreaking problems not fun to deal with but quite easy to explain.

IE9/Firefox use a different technique to render text than Chrome/Opera do.
IE9/Firefox use DirectWrite, and so the text comes out ever so slightly wider, adding up to a few pixels difference over all the menu items.
Read more here: http://www.basschouten.com/blog1.php/font-rendering-gdi-versus-directwrite
And read this, particularly the "Hinting and spacing differences" section: http://blog.mozilla.com/nattokirai/2011/08/11/directwrite-text-rendering-in-firefox-6/
Short of setting a fixed width on each menu item (don't), you can't fix it. However, you don't need to fix it: a few pixels difference between browsers does not matter. Remember, the users of your site are only looking at it using one browser.

Related

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.

Html paragraph spacing different in Firefox only

I've created a webpage that has several divs containing text. The right hand side of the page contains one large div made up of several paragraphs using the p tags. At the bottom of this large div after the closing p tag i have left some space so that the writing does not go right to the bottom of the webpage.
This space varies between browsers. It seems to display exactly how it shows in Dreamweaver in IE9 and Safari but when previewing in Firefox it seems to cut off some of the text at the bottom. This can be fixed by increasing the height of that div but then this also increases the space more in Safari and IE.
I've come to the conclusion that the spacing between each paragraph down the page is larger in Firefox than IE9 or Safari for some reason which is why the last bit of text is getting cut off in Firefox.
Has anyone else had this problem?
Here is link to my webpage: See the difference in the paragraph spacing in firefox compared to IE/Safari, most noticable at the bottom as it cuts off the writing:
www.athatravel.com/NewSite21/srilanka_highlights.html
Do you tried to set a fixed margin-bottom to your -Element... Maybe that is a solution for your issue.
Thanks Eray the reset.css file worked a treat. Thanks for everyones help and advice.I wasnt sure how to accept your's as the accepted answer as you posted it as a comment rather than an answer.

IE8 layout broken - IE7 mode correct

after 3-4 hours of searching with IE's "dev tools", I can't understand why.
This code: https://tinker.io/b2c10 produces the layout correctly in IE7 mode, Chrome, Firefox. In IE8 Standards mode, here's the result when you make the viewport smaller:
And here is how the layout should be / is in all other browsers (IE7 included):
Needless to say I experimented with all including:
reducing the max-width of the img
removing the Who's Who part with the display:inline-block's
removing the image completely from the middle column...
It seems there was a problem in how Sharepoint was converting my source html making it not valid...
In a not so clean way you can start by setting min-width on the divs with that content. That will also help to keep it from overlapping as it scales down. Also I think you might want to switch to spans for the div width. I feel like I am preaching Scaffolding to a lot of people but it really does help keep things scaling nicely.
.ms-WPBody {padding:0;overflow:visible;min-width:190px;}
http://jsfiddle.net/R8LEE/
http://twitter.github.com/bootstrap/scaffolding.html
p wich is block by default, with div using float: right, padding instead of margin....not sure how this is working, you need to improve your css a bit dude. I sugest you review it all.

webpage items change size when zoom in and out

My page, it keeps on getting different menu width when i zoom in and out. It is fine in IE, and no one else. I did not spot any fixed positioning, this seems to be using relative position.
have tried playing and disabling all CSS property to my menu bar through google chrome inspect element.
turn this from none to auto: " -webkit-text-size-adjust: auto "
Tried to use em ex px for my font-szie and padding. I am juiced out of ideas, save me internet!!!
www.magentek.com
Try zooming out, you will find press room gets pushed down. I got this SimplyBiz theme from wpcrunchy. It seems even the paid version have this problem too. The CSS and html is way too large to post, too much bloated codes, i think is sufficient to just use chrome inspect element.
I took a look at the site, and my opinion is that the css and js that make up the menu functionality are creating a 6th menu element. That would explain why an extra little tab is hanging off the end there. Since it doesn't have any content, the browsers are all handling the whitespace a little differently.
Did you by any chance modify the menu to take it from 6 elements to 5?

IE7 / IE8 Compatibility View: Element on page shifts to correct position when ANY css changes

I have an extremely strange problem in IE that I can't seem to track down. I have two boxes, both floated left, with a margin-left on the right box to give some spacing between the two. In Firefox (of course), it all displays correctly, but in IE when the page is first loaded, the boxes have no separation (no margin).
Here's the crazy part. If ANY CSS changes on the page at all, the box magically jumps to the correct position. And when I say any, I mean any. I modified the final font name of 3 in the font-family list of the body tag, and the box shifted to the correct position (this wasn't a change that would even modify the look of anything on the page).
I could post my HTML and CSS on the page, but it's fairly routine. I just wondered if anyone had come across or heard of this problem in the past? Incidentally, IE8 seems to render it fine.
Thanks.
Follow-Up:
So I was able to at least patch the problem by floating the box on the right to the right, and removing its margin-left property. Because my container div is just wide enough to accommodate the two boxes, this works for my situation, but it wouldn't be nearly as nice if the two boxes weren't contained so tightly in their container div.
Older versions of IE can be pretty buggy about how they handle floats. Try defining a width on your floated elements. This will help make the layout more explicit (so harder for IE to misunderstand) and trigger hasLayout if you haven't already (a weird internal IE property that causes a lot of layout bugs).