This was built off HTML5 Boilerplate which utilizes normalize.css, but even with this if you view the page on different browsers, different margins and paddings will occur on the navigation bar depending on the browser:
I’m new to the HTML5 Boilerplate/normalize.css and it kind of makes me wonder why use normalize.css if it can’t even get the margins/paddings consistent across browsers unless I’m doing something wrong? I’m pretty sure this wouldn’t be a problem if I used a normal CSS reset…
Anyway, what are my options to get the margins/padding consistent as it looks in the latest version of Chrome and IE 10? No JavaScript should be affecting it so I’m pretty sure you don’t need to look there. I know for sure that the latest versions of Opera (12.14) and Firefox (22.0) don’t render the nvagiation bar like the first two browsers I mentioned, and I don’t have the latest version of Safari since I don’t own a Mac unfortunately. And I haven’t even checked the older browser versions yet either…
Tips on CSS browser compatibility would be helpful as well!
Wow an HTML validator, I haven’t used those since my old XHTML days when I’d validate after almost every save… lol.
Just cleaned it up, but none of the errors were really big issues, mostly just multiple IDs due to some lazy copypasta. One error remains, but it’s reminiscent from the HTML5 Boilerplate so I’m pretty sure it isn’t causing any problems. The inconsistent navigation bar placement still persists.
UPDATE: Another thing I should add is that I’m mainly concerned with the modern browsers. I’m putting off older browser compatibility later so if you want to I’d prefer that you’d prioritize your answers toward modern cross-browser compatibility first. All the CSS is located under “Author’s custom styles” in main.css.
The validator should be routinely checked as the design progresses and should be the FIRST tool utilized when a trouble appears.
Your experience should have taught you just the opposite. Code that is compatible with older browser will almost always work in modern browsers and require minor tweaks only. Code that is compatible with modern-browsers-first forgives so many latent errors that it is unlikely to be backwards compatible. Older browsers expect much more valid code.
On my PC, in Firefox, your page renders exactly like your Firefox screen shot while JavaScript is disabled. When JavaScript is enabled it looks like the Chrome shreenshot.
Code that is compatible with modern-browsers-first forgives so many latent errors that it is unlikely to be backwards compatible.
I think that whole argument should be rephrased… not to age of browser but for standard compliance, just so that is clear. If one is to follow that old vs new rhetoric then star hacks would still be valid on a modern browser and you could never future proof anything.
Code valid, then add ‘tweaks’ and conditionals for ‘bad’ browsers.
Here is something to check for: box-sizing.
FF ONLY allows for ALL box-sizing properties, but other browsers only allow content-box and and border-box ( and don’t forget the vendor prefixes) it is possible that FF is accepting some box-sizing props which were ‘recently’ added to the specs, while other browsers are slightly behind.
What version are you running? Regardless of whether or not JavaScript is enabled or disabled, the problem still persists for me on my 1920x1080 monitor.
I just also noticed that when I’m using my laptop that runs on 1366x768, regardless of whether or not JavaScript is enabled I don’t have these problems which is totally weird because the version is the same.
EDIT: Did some more tests and for the life of me I figure out the source of the problem. It’s kinda mindboggling to me that the same modern version of the browser is rendering differently on two different computers. I reinstalled Firefox on both computers deleting all of my settings and add-ons and it’s still resulting to it rendering properly on my laptop, but not on my desktop. This is also regardless of whether or not JavaScript is enabled or not. Going to check a CSS validator now to see if that’s causing problems.
I’m really not sure what to look at that might help.
I’m running FF21. With JavaScript turned OFF, the html tag says <html class=“no-js”> and the menu resembles your Firefox screen shot.
With JavaScript turned ON, the html tags says
<html class=" js no-flexbox canvas canvastext webgl no-touch geolocation postmessage no-websqldatabase indexeddb hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients no-cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio localstorage sessionstorage webworkers applicationcache svg inlinesvg smil svgclippaths" style=“”>
and the menu looks like your Chrome screen shot.
Can you tell me why the code will not run locally on my PC? Apparently, it has to be run on a server, but I don’t know why. I know the @fontface is server dependent, but don’t see what else is. I must be overlooking something pretty obvious.
I tested on another computer with an identical monitor and it was actually running on Firefox 14 and it rendered okay. I updated it to FF22 and it still rendered it fine. It seems like my main desktop is an anomaly…
So I decided to get my hands on as many devices I could and test if the navigation bar’s spacing was okay. These were my results:
Windows 7 Professional, Desktop, 1920x1080 (Main desktop) Chrome 27: OK FF22: NO Opera 12.14: NO IE10: OK Safari 5.1.7: OK (BUT RENDERED SOME OTHER STUFF IMPROPERLY)
Windows Vista Home Premium, Desktop, 1920x1080 (Identical monitor to main desktop) Chrome 27: OK FF14: OK FF22: OK Opera 12.15: NO IE9: OK
Windows 8, Laptop,1366x768 (Identical monitor to main desktop) Chrome 27: OK FF22: OK Opera 12.15: NO IE10: OK
Samsung Chromebook, Monitor 1366x768 Chrome 27: OK
Windows 8 Laptop, Desktop, 1366x768 Chrome 27: OK FF22: OK Opera 12.15: NO IE10: OK
Windows 7 Professional, Desktop, Monitor 1360x768 FF22: OK IE10: OK
iPhone 4S Safari: OK
iPad 2 Safari: OK
Generic Android Tablet Dolphin: OK
Kin TwoM Browser: LOL
Still have no idea why it’s not working on my main desktop for Firefox… It could be that varying hardware is affecting it. I already tried doing a full, fresh reinstall of Firefox and the results were the same. If it’s really the hardware affecting the bug, then this test makes me skeptical of browser emulation software like IETester unless it’s done on a real virtual machine.
The html element’s classes get manipulated by Modernizr.js which comes with HTML5 Boilerplate. So far in development I haven’t touched anything with it though.
I think this will do the trick. Try before you buy, though
The <h1> element is pushing the <nav> containers down and the <ul>s overflow the bottom of <header>
It would happen if you increased the font size in one of the “good” PCs.
The left <ul> is not floated, but probably should be float:left. The right <ul> is floated and will not need the negative margin-top that is currently assigned, only 8px like the left <ul>.
Fixing the <ul>s will not fix the problem, but it’s a step in the right direction.
Put the <h1> and 2 <nav> containers in separate wrappers. Sorta like the following…
Assign positon:relative to <header id=“mainhead”>. Then attach <div id=“wrapperNew” to the bottom of <header id=“mainhead”> with position:absolute. That will remove any interaction between the <nav>s and <h1> elements.
Although untested, I believe this will solve the problem.
@dresden_phoenix is right! #mainhead should not have been assigned a fixed height to begin with. (My mistake for not noticing the obvious.) Very slick menu fix, too !!! Examples that teach! :tup:
Irrespective of the answers above which are good and relevant the differences you are experiencing are not due to padding or margins but due to line-height which you have not controlled. Browsers apply different defaults for line-heights so you need to set them explicitly to match your designs.
Adjusting the line-height for the h1 and nested span brings Firefox and Chrome into alignment.
#mainhead h1,
#mainhead h1 span{line-height:63px}
I used px line-height because you have a fixed space into which to work (the height you set) so em line-height would not make much sense here.
Normalise.css does not address line-heights (apart from a couple of odd form elements) and leaves it to the browser defaults which it assumes to be constant between browsers but is a slightly flawed approach. The default for line-height is “normal” and the way that “normal” is interpreted is different between browsers in some cases and not specifically defined in the specs.
Most of the time its pretty close but where you have large fonts and font-face rules to take into account things can start to drift apart unless you specifically control them.
Even when you specify a line-height for the body you will find it inherits into elements quite nicely but should you say use a shorthand for the font-size then the omitted value of line height will default to “normal” and will not match the other similar elements although they may at first appear to have the same rules.
e.g.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
body {
font-family:Arial, Helvetica, sans-serif;
line-height:84px;
}
p {
font-size:34px;
background:red
}
.test { font:34px Arial, Helvetica, sans-serif }
</style>
</head>
<body>
</body>
<p>Testing Line-height:40px;</p>
<p class="test">Testing shorthand font rule</p>
</body>
</html>
The second element is much smaller than the first element because its line-height gets reset to normal.
As a rule of thumb any time you set a font-size you should think about setting a line-height at the same time in situations where position and space is critical.
Adopting a less constrained layout (as suggested by Dresden above) will lead to a design that works better and looks ok but not necessarily exactly the same cross browser. It’s only when you force elements into tight spaces with specific heights that these line-height differences may show up. The normalise actual demo shows that things are pretty consistent but blow the fonts up a bit and add more complex issues into the layout and things can become misaligned.
Many thanks for your detailed explanation and clarification.
In future I will set a specific default body {line-height:1.42em} to reduce cross-browser compatibility.
Amended:
In future I will set a specific default body {line-height:1.42em} to increase cross-browser compatibility and reduce cross-browser incompatibility and not to decrease cross-browser compatibility or increase cross-browser incompatibility
