Chrome Ok , IE ok, Firefox a bit off little help needed

http://my.switchmia.com/miami-hosting

Viewed on Chrome perfect, same with IE ... on firefox the image if pulled to the right

Any help will be great, thanks

 

You didn't clear the float above it, so it's riding up next to the DIV#grid4... setting clear:both on #homepage should fix it, though I'd be tempted to set overflow:hidden and a haslayout trigger on HEADER instead. I was able to determine this using a mix of Opera Dragonfly and FF Firebug -- two tools you really should have. They overlap in functionality a lot, but each has things the other misses.

That said, some observations -- you've got accessibility issues with the fixed width layout, fixed metric (px) fonts, and illegible color contrasts in the footer. That massive bandwidth and code wasting banner adds nothing of value to the page, and you're way too content-light when it comes to the only first class citizen of the web -- TEXT. The page blows 10k of code on delivering 790 bytes of plaintext, so possibly as much as three times the markup necessary. The MASSIVE amount of "CSS for nothing" in dozens of separate files makes debugging nigh impossible, and having been built using that 'grid' nonsense is really biting you in the backside. In many ways you have design and layout concepts that have no business on a website like fixing the heights of so many elements.

You've got META nothing actually cares about, an invalid 'robots' meta (since there's no such thing as index or follow), incomplete media targets (don't forget projection and TV), endless pointless DIV for nothing, classes for nothing, those stupid malfing fantasyland 'data' attributes, broken/missing headers (H2 with no H1 preceeding them is gibberish), multiple tracking packages just wasting bandwidth to do what should be gleaned from your server logs, and a dozen plus scripts totalling half a megabyte doing 16k or less scripting's job!

Worse, there's tags like FONT and attributes like TARGET that have no business on any website written after 1997!

Much less the ungodly bandwidth wasting 2.41 MEGABYTES in 35 files (not even counting the bandwidth wasting webfonts) making it slower than molasses in february... on a site that to be frank most likely has no business having a template (HTML+CSS+IMAGES+SCRIPTS) of more than 140k in a dozen files.

... which is why (and I say this a LOT) I'd toss that entire mess and start over with semantic markup, separation of presentation from content, and accessible style -- doing yourself a HUGE favor and staying away from the 'gee ain't it neat' scripttard bull -- since again you've got 432k of JS for nothing -- and outright halfwit garbage like 'grids' -- since they by definition make you use presentational classes.

Yes, it's THAT bad.

 

your the man, that did it!

Also cleanup the code a bit .. any input?

 

Well, there are a few things that would help alleviate the problems right off... First and foremost is that MASSIVE 2 megabyte background image. If I can see it loading and drawing on a 45mbps connection, there's something wrong with it. That image ALONE is twelve times the upper limit I usually set for an entire PAGE on a site.

Since it doesn't seem to enlarge to more than 480px tall, I'd resize it to there and go ape-shit with the encoding. That image seems to have NO 'lossy' compression - given it's just a background I'd see if I could get away with ~25% or so lossy, which should give you a file of around 120k if you resized that to say... 1280x460; about as big as you would ever really need it.

Either that or I'd axe that image and the weird 'slide in' scripting nonsense... of course that image is PRESENTATION, and as such has no business in the markup. (which I suspect is an 'artifact' of that goofy bloated javascript?)

While the social media links are 'nice', you've got perfectly good FB and twitter ones. You want more, add them like you did those. That MASSIVE 120k 'addthis' script is 90% the upper limit I'd allow for an entire page of HTML+CSS+SCRIPTS+IMAGES all by itself, and most certainly isn't worth the half-dozen links it provides. I often wonder what possesses people to even try using scripts like that.

To be frank I would probably axe ALL the scripting on the page, most of it isn't doing anything useful apart from making the page load take forever, and the handful of things that they might provide of use aren't worth the insane bandwidth and code bloat they need to function.

I'd also forget HTML 5 -- it provides nothing over 4 STRICT or XHTML 1.0 STRICT of real value, at least in terms of semantic markup. Even if I were to deploy HTML 5 because I needed to give apple-tards VIDEO and AUDIO, I'd design in STRICT and then just slap the doctype on to shut the validator up. Generally speaking IMHO HTML 5 is designed to set coding practices back a decade or more -- it's little more than "the new transitional"; I'm also leery of it because it's in draft and in flux, apparently nobody remembers what happened the last time a browser maker went bleeding edge implementing a draft specification; the result was IE 5.x and 6. EVERYTHING 'wrong' with IE6/earlier people bitch about today stems from people deploying DRAFT specifications.

That said I do use CSS3 so...

If I were to retain your home page's style, (which I wouldn't, I'd axe the banner area and get some CONTENT on the page) the markup would probably go something like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<meta
	name="viewport"
	content="width=device-width; initial-scale=1.0"
/>

<meta
	name="keywords"
	content="server,colocation,IP transit,network,vps"
/>

<link
	rel="shortcut icon"
	href="favicon.ico"
/>

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

<title>
	SwitchMIA - Miami Colocation, Dedicated Servers, VPS Hosting, IP Transit
</title>

</head><body>

<div id="top"><div class="widthWrapper">

	<h1>
		<a href="/">
			Switch<span>MIA</span><br />
			<small>Servers, Colocation, IP Transit</small>
			<b><!-- image sandbag --></b>
		</a>
	</h1>

	<ul id="mainMenu">
		<li><a href="/about">About</a> </li>
		<li><a href="/network">Network</a></li>
		<li><a href="/colo">Miami Colocation &amp; IPTransit</a></li>
		<li><a href="/vps">HighSpeed VPS</a></li>
		<li><a class="button" href="http://nocroom.com/clientarea.php">Client Portal</a></li>
	</ul>

<!-- .widthWrapper, #top --></div></div>

<div id="homeBanner"><div class="widthWrapper">
	<h2>Fastest Servers, Fastest Network, 24/7 Support</h2>
	<ul>
		<li class="happyVPS">
			<span>RAID-10 <b>+</b> SSD <b>+</b> HighSpeed Fiber <b>=</b> Happy VPS Clients</span>
		</li>
		<li class="testAndTour">
			<a href="/network">Test Me, Network Tour</a><br />
		</li>
		<li class="viewAndDeploy">
			<span>View VPS Plans, Deploy in 60 seconds</span>
		</li>
		<li class="requestQuote">
			<a href="/colo">
				Colo Floor, Request a Quote
			</a>
		</li>
	</ul>
<!-- .widthWrapper, #homeBanner --></div></div>

<div id="footerLinks"><div class="widthWrapper">

	<div id="resources">
		<h2>Resources</h2>
		<ul>
			<li>
				<a href="/nocroom">
					Client Billing / Support Portal / MRTG
				</a>
			</li>
		</ul>
	</div>
	
	<div id="switchMIA">
		<h2>SwitchMIA</h2>
		<ul>
			<li><a href="/about">About</a></li>
			<li><a href="/tos">Terms and Conditions</a></li>
			<li><a href="/use">Acceptable Use</a></li>
			<li><a href="/contact-us">Contact</a></li>
		</ul>
	<!-- #switchMIA --></div>
	
	<div id="social">
		<hr />
		<img
			src="images/Miami-SOC-report-SSAE-16.png"
			alt="Miami-SOC-report-SSAE-16.png"
		/>
		<a href="http://fb.com/pages/SwitchMIA-Miami-Colocation/472101976242965?ref=br_tf">
			<img
				src="images/facebook.png"
				alt="facebook.png"
			/>
		</a>
		<a href="http://twitter.com/switch_miami">
			<img
				src="images/twitter.png"
				alt="twitter.png"
			/>
		</a>
	</div>
	
<!-- .widthWrapper, #footerLinks --></div></div>

<hr />

<div id="disclaimer" class="widthWrapper">
	&copy; 2014 SwitchMIA All Right Reserved. #MiamiColocation #MiamiDedicatedServers #MiamiIPTransit<br />
	33149, 33129, 33131, 33132, 33139, 33130 ,33145, 33133, 33146, 33134, 33135, 33130, 33136, 33137, 33147, 33142, 33125, 33136, 33144
<!-- .disclaimer --></div>

</body></html>

Code (markup):

That's +/- 5% of what I'd have 'final' for code. It might gain a few SPAN and DIV, maybe even a couple BR during styling -- particularly for media targets, but really that 3k of code is about all I'd use.

Gimme... eh, about fifteen minutes and I'll toss a copy up on my server live with working CSS to show you what I mean. Well... maybe more like 20 minutes since I'll be re-mastering the images to get the sizes under control. After I get it working I'll post up breakdowns of the HTML and CSS (laugh being those will probably take longer than it does to make the page!)

 

... and here it is:
http://www.cutcodedown.com/for_others/switchMIA/template.html

As with all my examples the directory:
http://www.cutcodedown.com/for_others/switchMIA/

is wide open for access to the gooey bits and pieces. It's behind a robots so don't worry about it stealing link mojo, and it's tested working perfect in modern browsers and IE 10+, no transitions in IE9, and gracefully degrades as functional in older browsers. (just don't expect it to look as good).

I made the layout completely responsive, though I had to take some liberties with the design to do it in a practical and minimalist fashion.

As I suspected, re-mastering the background image:
http://www.cutcodedown.com/for_others/switchMIA/images/homeBanner.jpg

Didn't have that big an impact on appearance, and cut it down to 108k (to your originals massive 2 megabytes). The whole page is now accessible, has hover effects, media queries, and comes in at a mere 127k in 8 files -- at which point yeah, you could probably keep that image. I hid the image on narrow displays because there just wasn't enough of it showing to bother -- which also lets us axe the whole trying to scale it thing.

I'll start in on a HTML and CSS breakdowns to explain the how/what/where/why of each file so you can learn from it.

 

HTML Breakdown
--------------

As I mentioned, I work in XHTML 1.0 Strict -- it's the most recent recommendation, and makes sure I can't use things that have no business in any code written after 1997 like FONT, CENTER, ALIGN, TARGET, etc, etc...

You'll notice I'm a bit rabid in my formatting -- I just find it clearer to have properties and values separated to their own lines. Also explains why I like the /> closing on empty tags. (BTW, when the specification says empty, it means cannot contain content, not does not. <div></div> is NOT an 'empty tag' by the specification).

I have a viewport META in there to tell mobile browsers "we know what we're doing" so they don't screw up our formatting. I only set initial-scale so that mobile users can still zoom. (some people incorrectly set max-scale)

I added a keywords META -- remember that said meta should be seven to eight words (or proper names) that EXIST INSIDE BODY.

While I included the code for a favicon, I did not create the file as your original PNG isn't working here in any browser. Really you shouldn't have a PNG as your primary favicon as browser support is still spotty -- good old-fashioned ICO file is still your best bet.

Notice that in the CSS LINK, I have the media target "screen, projection, tv" -- this covers all screen targets one might want to nab -- there are STILL some WebTV users out there, as well as devices like the Wii, and don't forget that some browsers in kiosk mode obey projection instead of screen.

I also name the file something meaningful -- it's media target, instead of the uselessly vague names some folks use like 'style'... Keeping it to a single file also cuts down on the handshakes, and even if you add style for the sub-pages to it, you're just pre-caching those on first-load.

I put <html><head>, </head><body> and </body></html> all on lines together as a reminder that nothing should EVER go between those elements. A lot of people make that mistake, so making it clearer is a good thing.

#top is of course the outer wrapper for the header. Because it's an ID if you wanted to add a 'back to top' link you can target it as href="#top" if desired.

.widthWrapper -- this class is applied to multiple div on the page to set our semi-fluid elastic widths on content. Beats constantly declaring the widths on child elements even if it is an extra div and class.

h1 -- A H1 is the heading under which EVERYTHING on the page is a subsection, so it's the first content element you should have on a page! You're H2 are then subsections of that H1 and kin to each-other, h3 the start of subsections of the h2 and so forth. The Anchor inside it really doesn't need a whole lot of explanation, but the rest...

I put the text for the header in there so I could use a technique called "gilder-levin image replacement" on it. I use span to apply the blue color and small to declare the tagline/de-emphasized text (whcih IS semantic use of SMALL). The SPAN inside the small is to force a wordwrap at certain widths. This gives an images-off appearance roughly akin to your image. The B tag is the image-replacement, which in the CSS is placed over the text to hide it.

#mainMenu -- a simple list/menu. The .middle class and the BR in same are there for tweaking the appearance at certain widths with media queries.

Also, notice when I close .widthWrapper and #top I use closing comments. I don't say "end" or "closing" because that's what </div> means (duh) -- I put them before the elements because there's this bizarre bug in some versions of IE and FF that if a comment ends up betweeen sibling elements content can be drawn twice (double render bug), or not be drawn at all (disappearing content bug). Just moving the comment before the close means they can never end up between sibling elements.

#homeBanner, .widthWrapper and .inner -- I HATE nesting this deep on div, but with the full-width background, restricted inner width, and desire to center the content, it's the cleanest way of doing it. I could have used display:table-cell on .widthWrapper, but that's unreliable; you have a fixed amount of content, so with some media queries it's no big deal to reposition it as desired.

#homeBanner h2 -- I made this a heading so the section, well... HAS a heading. The SPAN inside them are there to keep those words paired when it word-wraps.

#homeBanner ul -- Rest of these just struck me as a list of features... so unordered list it is. Each gets a unique class. The ones that are not anchors got span so it's easier to style them consistently, particularly since we usually will want to make the LI have no styling. (thanks to IE8 being a re-re)

#footerLinks -- again gets a .widthWrapper inside it, other than that the various subsections are pretty simple and not that different from what you had. With the loss of the 'addThis' script it seemed better to put that image (which I found the original and redid the scaling on)

Oh, thinking of the IMG tags, I pulled all the title -- there is NO reason to EVER put TITLE on a IMG... The anchor around the IMG maybe, but ALT is the text equivalent -- and if your title is the same as the text inside the tag, there's NO reason to add a title. (well, unless you're building an accesskeys menu and don't want the URI's on the menu)

HR -- you'll notice a few HR in there. Horizontal rules in semantic markup (just as in professional writing) indicate a change in section where a heading is unwanted or unwarranted. It says "this is NOT a subsection of the heading before it" -- which is why there's one at the start of #social, saying "this is not a subsection of <h2>SwitchMIA</h2>... between using numbered headings and HR properly, well... see why I consider HTML 5's HEADER, SECTION, NAV, ASIDE and FOOTER to be pointless bloat.

#disclaimer.widthWrapper -- To make the footer appear to have it's color go to the bottom of the page, we'll be setting that on BODY. As such we don't need the widthwrapper as a separate div.


... and that's the markup. I'll start in on a breakdown of the CSS.

 

CSS Breakdown
-------------

I always start out with a reset. Since HTML is not actually supposed to say what things look like, appearance is left to the discretion of the user-agents (browsers)... this can bite you in the ass since when left to their own devices browser makers can go all sorts of different directions -- so a reset gets you back to a consistent baseline.

There are smaller ones like the so-called universal reset; "* { margin:0; padding:0; }" -- but that can nab some things like form elements (INPUT, SELECT, TEXTAREA) which don't recieve styling consistently across browsers. There are larger resets like Eric Meyer's "Reset reloaded", but that's so fat and bloated it's almost a framework, and is IMHO the number one reason 'resets' have a bad reputation. The one I use (developed by Dan Schulz, RIP) nabs the elements that need resetting without going overboard on it.

HR -- I hide these since they are in the markup for semantics and non-screen.css targets. We don't need them once our screen style is applied.

-text-size-adjust -- These also tells mobile browsers "we know what we're doing", in this case "don't dick with the font sizes". I put these in a media query since only older small screen iOS and Windows handhelds need this.

body -- I like to set the font size most of the page is going to use on BODY. I also set the color and background for the footer here, so it will show through right to the bottom of the screen.

.widthWrapper -- for our widths I set 95% so that at all widths it's pushed off a bit from the edges, while the min-width is there for non media query browsers (IE 8/earlier) so they don't try to go narrower than the page works at. The max-width is there so any lines of text when you have paragraphs don't get too long -- combined min and max-width is called "semi-fluid layout"... Because I set those min and max-widths in EM's, based on the default size, which in body is set in % -- the layout is also elastic, automatically adjusting to the end users default font size... (like the windows large fonts / 120dpi setting I run on my computer!)... and of course the auto-margins centers it.

#top -- I set float wrapping to contain the floated H1, so our white background extends to full height.

H1 -- position:relative is so we can aPo the bold tag inside it over the text. I set the height in EM's so we can center the anchor and bold tag while staying elastic. This makes positioning the menu easier. Unfortunately FF and Opera screw up and calculate EM's based on the largest child's inline level elements font-size, so we have to force the issue on that by declaring 100%.

h1 a -- aPo (absolute positioned) 50% down the page, we use px metric fonts so it fits under the image instead of auto-enlarging (which would make it peek out). A negative top margin equal to half our total height (48px on this and 16px on small from the line-heights == 64px, /2 = 32px) then centers it vertically.

h1 a span -- that blue color to mimic the image appearance.

h1 small -- The display:block makes styling this easier (and gets rid of a pesky extra line that appears randomly in some browsers).

h1 small span -- this is for media queries, not colors. It's easier to undo it than adding classes to the markup. Remember, CSS is cached, markup is not.

h1 b -- our image replacement. It's just absolute positioned over the anchor text hiding it. Images off, you get the styled text. Images on you get your logo.

h2 -- I set these up ahead of time. I skipped using webfonts as they aren't worth the ridiculous filesizes just for a two or three dozen characters per page.

#mainMenu -- turn off bullets, set our alignment, and I set a really tall line-height to make that 'button' one easier to deal with. The top and bottom padding add up with our line-height to equal the same as the height of the H1.

#mainMenu li -- I set these to display:inline and don't even TRY to do anything else to them for a reason; IE 8 is an idiot. There's a bug called the 'staircase effect' that can really bite you in the ass if you don't know how to get around it.

Thankfully this means we can make our anchors inline-block, far easier to style.

#mainMenu li a -- The overflow:hidden fixes a bug in trying to make them nowrap in Opera and nabs an IE6 bug with the margins. Left margin to space them apart, from there it's just style and color. I added CSS3 transitions to make the hover effects a bit smoother.

#mainMenu li a:psuedostates -- using :active, :focus and :hover nabs not just mouse, but keyboard nave too for our color effect.

#mainMenu br -- I hide these, we'll show them at certian widths using media queries to control the page's appearance.

#mainMenu .button -- Different padding and shorter line-height adds up to the same height as our 2em tall line-height buttons. Apart from that it's just some simple styling.

#mainMenu li .button:psuedostates -- the hover effect. YAWN.

#homeBanner -- image, alignment... pretty simple.

#homeBanner .widthWrapper -- relative positioning to help with trying to vertically center the content, and a fixed height. It's simpler to just fix the height than to try and play those resizing games you were in the javascript.

#homeBanner .inner -- again the 50% from top aPo and negative margin trick to center it. I actually made it a hair higher than the math said due to that 'hallway' effect creating the optical illusion of it being off center.

#homeBanner h2 -- the heading. I added the max width as it looked a bit silly at the really really wide width at large fonts -- particularly since it got WAY wider than the elements below it. Fonts, colors, I added a text-shadow as the white on blue was right on the edge of accessibility minimums in terms of contrast. Helps with legibility.

#homeBanner h2 span -- nowrap so if it ends up too narrow, the word pairings stay together. SPAN is semantically the correct tag for that as it adds no meaning to the content -- we're doing this for style, not meaning.

#homeBanner ul -- float wrapping, turn off bullets, set the font size.

#homeBanner li -- again, just set these to inline and pretend they don't exist.

#homeBanner ul a,
#homeBanner ul span -- these share a lot of properties, so set that here. inline-block so we can have padding obeyed height-wise, padding, colors, border radius.

#homeBanner subsections -- these all just get colors, nothing fancy here. I do set text-shadow on hover to make them glow, seemed the easiest visual style to implement fast.

#footerLinks -- again float wrapping. Padding, colors, ooh pretty.

#resources, #switchMIA -- float 'em, pad them apart. We also turn off the bullets in their UL.

#social -- alignment, no wrapping so if they want to float drop, they all drop.

#social a -- on both the social links I switched to palette transparency PNG files without the rounded corners or backgrounds, then use border-radius to make them round. This lets us use CSS3 effects on the background-color on the hover states! Simple, easy, and pretty cool looking.

#social img -- just make sure all the images vertically align with each-other.

#disclaimer -- some simple padding to make it pretty.

That's our base layout. I then use media queries to make it 'responsive'.


MEDIA QUERIES
-------------

@media (max-width:61em) -- I lower the min-width since we know media queries work, again that min-width on .widthWrapper was for legacy browsers that don't know media queries. The menu gets broken into two lines by turning the BR back on, so we change it's padding to keep it the same height and centered next to the h1. That's all we need to fix at this point.

@media (max-width:46em) -- at this width we break the menu into three lines, so again we shrink the padding to keep it all nice and lined up. I turn off the background image on #homeBanner as there's just not enough of it showing to make it worth even loading/showing, so we also strip off the positioning of .inner and set it back to automatically make it's own height. Any extra formatting there gets killed off as we try and make all fo them get the same basic appearance and padding. In #footerLinks we make the first two boxes 50% width with no padding, taking up the full width. IE has a bug where two 50% width floats can accidentally 'drop' one below the other, setting a negative margin on the right-hand one prevents this. This moves #social down to it's own line, so we change out it's formatting to look better like that. I also tweaked the padding on the H2 as they seemed a bit too big in this layout.

@media (max-width:38em) -- at this width we basically strip off all the columns/floats and just center and place everything one below the other. While there's a lot here, it's all just changing alignment, stripping floats, and adjusting padding/margins.

@media (max-width:360px) -- down this narrow there's not enough room for that logo, so we just pull it and show the text. Anything that wants a layout this small probably wouldn't want images anyways. I shrink the font sizes in the H1 even further and change them to dynamic; likewise the text in the H2 is way too big for this size display, so we give them a bit of a trim as well...

... and that's the CSS.

I know that's a lot to take in, read through, compare to the code, and any questions fire away.

Hope all this helps. It's what I do.

 

Wow, i will have to look at all this in more time next week.

But meanwhile i did remove "addthis " and made adjustments to the image

 

@deathshadow working on a beta, im sure you would like this one better http://test.switchmia.com/

this time made into $smarty templates

 

Well, it still suffers from the inaccessible fixed metric (px) fonts, and illegible color contrasts... and the webfonts REALLY aren't helping with that. There are RULES for choosing colors and the WCAG says to declare fonts in %/em for a REASON.

The stupid malfing script-tard "switch the menu" for mobile (that makes it even LESS useful on mobile) is garbage, as is the pointless markup. (I dunno who started that trend, but they need a good swift kick in the junk)

The HTML 5 bloat sure isn't helping either especially with that ****tard "let's wrap the HTML tag in a half dozen IE CC's" crap Paul Irish came up with. There's a reason I say dial it back to a *SHOCK* RECCOMENDATION doctype. (though even if HTML 5 were a recommendation you couldn't pay me to use it.)

There's no graceful degradation, comment placements known to trip rendering bugs, pointless comments, empty elements that probably shouldn't even be in there...

Really I'm not seeing that big a difference from what you had before. It's still an accessibility wreck; and it's still very poorly coded and filled with things that I'd never put on a website in the first place.

The lack of actual content on the main page not helping much either. Probably why I'd cut your "about us" page in half and make it the landing page, swinging an axe at that giant pointless bandwidth hogging full width image trash.

Of course, I'm not exactly a fan of idiocy like Smarty either, since running a template engine on top of a template engine (php) seems pretty damned redundant and pointless.

Oh, and that 60k train wreck of CSS? Uhg... and that's with it being the re-re stuff everything onto a single incomprehensible line... did you do something silly like use that halfwit "LESS" garbage on it or something? It has some of the hallmarks of that.

 

remember still beta still no where to be done