Moved from XHTML Transitional to Strict causing display issue

Hi guys,
I’m been building the following website and had the site working on all browsers but IE was not quite right - there is a gap between the main 3 columns and the “main bottom”.

Asking a colleague I was informed that I should be building in XHTML Strict rather than transitional. So I amended the code above the header to reflect this. The gap is now appearing in all browsers. Using Firebug I’ve discovered that the <div> that holds the picture in the middle is overflowing by <5px I believe this is the problem but don’t know why it is doing this.

I have considered removing the margin-left and floating left on the central <div> and then setting the main-bottom div to float left - This causes the same issue but the <div> that the image is stored in is the correct size (see images below).

This is with the margin-left and instead the image floated left

This image uses the margin and no floating to be positioned.

I have added a version of the site with these changes on available here.
Is this a better way of coding the layout?

Can anyone advise please.

Many thanks, Jonno.

Possibly the second of the two validation errors may be part of the problem.

Line 186, Column 44: required attribute “alt” not specified
Line 204, Column 20: there is no attribute “align”

At least fixing those errors will eliminate the possibility of their causing problems

  1. what the devil are you wasting flash for on that page… Especially since they all need “click to activate” making your goofy animated effect just break the buttons from working.

  2. What on earth:

    <h1><span class="h1Large">BUDDY-UP</span></h1>

Makes those separate headings?!? Or are you choosing your tags based on their default appearance instead of what they are FOR? You’ve got three tags there for what should only be one, MAYBE two.

<h2 style="margin-top:60px;"><span class="green">OUR SUMMER SPECIAL RATES</span></h2>

Why is that a H2, what’s with the extra span for nothing, and why are you inlining CSS?

The whole document is filled with that type of nonsense. Endless DIV for nothing, improper use of semantic elements, Flash breaking things that shouldn’t even be flash in the first place, obvious quote not in blockquote tags with no CITE, px metric fonts and color combinations adding up to an accessibility train wreck… It’s a laundry list of how not to build a website.

If I was writing that same page, the markup would go something like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

	content="text/html; charset=utf-8"



	Hull Sport &amp; Fitness Centre


<div id="pageWrapper">

	<ul id="topMenu">
		<li class="first"><a href="#">Accessibility</a></li>
		<li><a href="#">Change scheme</a></li>
		<li><a href="#">Contact us</a></li>

		<span>HULL</span> Sport & Fitness Centre

	<blockquote id="headerTestimonial">
			"Motivation is what gets you started. Habit is what keeps you going."
			<cite>Jim Ryun</cite>

	<ul id="mainMenu">
		<li><a href="#">About Us</a></li>
		<li><a href="#">Facility Hire</a></li>
		<li><a href="#">Classes</a></li>
		<li><a href="#">Memberships</a></li>
		<li><a href="#">Active Campus</a></li>
		<li><a href="#">Location</a></li>
		<li><a href="#">Contact Us</a></li>
		<li><a href="#">FAQs</a></li>
		<li class="last"><a href="#">Events</a></li>

	<div class="columnWrapper">

		<div id="memberships" class="subSection">
				Lorem ipsum dolor sit amet, consectetur <span class="green">adipiscing elit</span>. Pellentesque eleifend egestas ipsum nec facilisis. Maecenas blandit malesuada est, eu ultrices diam malesuada quis. Donec <span class="green">auctor</span> lacinia elit, a commodo ipsum laoreet eget.
			<div id="specialRates">OUR SUMMER SPECIAL RATES</div>
		<!-- #memberships --></div>

		<div id="bigPlate" class="subSection">
				alt="Some women exercising"
		<!-- #bigPlate --></div>

		<div id="sideMenu" class="subSection">
				<li class="whyGetActive"><a href="#">Why Get Active</a></li>
				<li class="intramuralSport"><a href="#">Intramural Sport</a></li>
				<li class="activeStudents"><a href="#">Active Students</a></li>
				<li class="activeStaff"><a href="#">Active Staff</a></li>
		<!-- #sideMenu --></div>

	<!-- .columnWrapper --></div>

	<div class="columnWrapper">

		<div id="getActive" class="subSection">
			<h2 class="getActive">
				<span><!-- image replacement --></span>
				Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque eleifend egestas ipsum nec facilisis. Maecenas blandit malesuada est, eu ultrices diam malesuada quis. Donec auctor lacinia elit, a commodo ipsum laoreet eget.
			<p class="standout">
				<strong>Work out, have fun, feel fantastic</strong>
		<!-- #getActive --></div>

		<div id="news" class="subSection">
				Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque eleifend egestas ipsum nec facilisis. Maecenas blandit malesuada est, eu ultrices diam malesuada quis. Donec auctor lacinia elit, a commodo ipsum laoreet eget.
			<a href="#" class="readMore">Read more...</a>
		<!-- #news --></div>

	<!-- .columnWrapper --></div>

	<div id="footer">
			<li class="first"><a href="#">Legal</a></li>
			<li><a href="#">Customer care</a></li>
			<li><a href="#">Feedback</a></li>
	<!-- #footer --></div>

<!-- #pageWrapper --></div>


Gimme a few minutes and I’ll slap together the CSS to go with that…

though that center image? What I like to call a non-viable design element if you change the fonts to an ACCESSIBLE size or have dynamic content… It’s one of those “But I can do it in photoshop” moments… I’d be half tempted to use a taller version of the image so it can expand-shrink height-wise revealing more of it, and moving it into the CSS as presentational instead of having it in the markup.

Maybe Center-center so the thing could be opened up semi-fluid… since fixed width goes hand in hand with your illegible color contrasts and uselessly undersized fixed metric fonts.

Took me a bit longer to get to it – but here we go:

as with all my examples the directory:

Index of /for_others/jonnoW

is open for easy access.

I cropped and resized that center image so I could make a really tall slice – large font users will get taller columns, so you need the image taller. I’d suggest going back to your source and doing that, making a 420x640ish image to be loaded there, with the face almost dead center like I have it. The image is aligned “center center” so as different systems (or different content) give you different sized side columns, it will show more of the image top/bottom. I added min-height to the wrapping div so that at least 300px of image height is shown. The menu on the right got the “absolute positioning to center vertically” trick applied to it – so that as the size of the columns change (which that left column should!) be it due to content changes or font sizes (due to things like the system metric) it will stay centered to the image/column height.

I also gave it some hover states and CSS3 corners while I was in there… and of course switched it to dynamic fonts on all the content, and tweaked the colors up to meet accessibility norms on contrast.

Just to show you what I meant up above about too much markup, accessibility issues, and ‘non-viable’ approaches to layout/presentation… and getting rid of the unneccessary/wasteful/bloated flashtard stuff.

Further improvements I’d suggest include opening it up fluid or semi-fluid, though that would change the column widths even more and require rethinking the menu. fixed width is trash.

First, I’ll answer your question.

Asking a colleague I was informed that I should be building in XHTML Strict rather than transitional. So I amended the code above the header to reflect this. The gap is now appearing in all browsers. Using Firebug I’ve discovered that the <div> that holds the picture in the middle is overflowing by <5px I believe this is the problem but don’t know why it is doing this.

Your colleague is correct in that you should use a strict doctype whenever possible… “transitional” was for people taking an existing document from, I dunno, 1997? and slowly trying to modernise it while keeping it “live”. Or something. Transitional lets you use <center> tags and other garbage. It’s useless for any pages built in this millenium because then the W3C validator can’t tell you your page has major suckage.

As for the gap? This was caused by your image in the middle.

Images are inlines (unless you say otherwise in the CSS), and inlines usually contain text. So for that reason, inlines have different alignments possible: a baseline, which is where the bottoms of most letters sit, but also room underneath the baseline for all the “descenders” (the dangly bottoms of letters like y,p,q,g,j…). Most inline default their bottoms to “baseline” instead of the actual “bottom”.
With CSS you can manually move that image to the bottom though:

img {
vertical-align: bottom;

(actually, the gap will vanish if you set vertical-align to anything other than “baseline”. It will also vanish if you make the image something other than an inline: display: block, display: inline-block or float: left/right would also do it, but I only would if that’s what you wanted in the first place)

Why did all browsers show it when you switched doctypes?
Likely because when browser vendors build their browsers, they make assumptions like
-if the page doesn’t have a doctype at all, or an incomplete doctype, then the page might have been written back in the heady days of grunge and the internet Dot-Com bubble, so render in quirks mode

-if the page has an incomplete or transitional doctype, it’s probably filled with garbage but maybe written after the new millenium… use “almost standards” mode or quirks (Mozilla has an almost-standards mode though so far as I know it’s only specifically supposed to deal with gaps under table cells, not images in general… I dunno)

-if the page has a complete and strict doctype, then render everything in “standards mode”.

That’s my guess anyway.

The two errors Felgall pointed out shouldn’t affect how your page looks (maybe the align, I dunno) but you should get those fixed anyway for the same reason your colleague suggested using a Strict doctype. Less garbage usually means less chance of cross-browser issues (or, eliminates many common issues).

And Crusty’s (deathshadow’s) rewrites are usually a good way to go. If you cannot implement code like that, then at least take some time to study it as it has many good design/code ideas in it that you would want to implement in future projects.

That’s great, thanks for the help and advice. Really makes me realise how much I still have to learn! But I guess that will come with time. When I began on the site I did raise the point about Flash but to no avail, so I will bring it up at the next meeting. I was thinking if they still wanted the colour/font transitions then jQuery would be a better route to follow?

That’s such a great help I’m going to get on with rejigging everything and I’ll be sure to only build in strict from now on!

Just out of interest DeathShadow, how long did it take you to rewrite that page?

Thanks again


About five minutes, maybe less for the base HTML, another ten to fifteen for the layout CSS, five more to re-master the images and hang them on the layout.

Which is the process I work in – When I write the HTML “first pass” I assume the layout and presentation doesn’t even exist, this allows me to be 100% sure I’m using semantic markup saying what things ARE. A second pass for some common styling looks is all I need before I build the layout using CSS. I only go through and apply image-based style at the very end.

Given that jquery is a fat bloated mess that just results in massive page loads for NOTHING, I’d not ruin a perfectly good page with it. Using flash for navigational elements isn’t called “flashtard design” for nothing – but given what that flash was doing for ‘animation’ looked more like a rendering error than good design, I’m not sure why you’d even want that ruining the page in the first place – especially since it flushed accessibility down the toilet.

But if the client wants to be a dumbass, there’s often not a lot you can do.

Cheers, you’ve given some good points that I’ll be able to use in the future.

Thanks again.

Hi again DeathShadow, I’ve been going through the page and I was just wondering why you chose the method you did for aligning the right side menu? I.e. positioning absolute, and aligning top:50% and finally using a negative margin value to then position it?


View the page on a large fonts/120dpi machine – the columns get taller because the text is by default taller while the image is not. Having it in the normal flow position of top aligned actually looked stupid, so I used that method to center them vertically… so as more of the image is revealed on systems with larger default fonts, the menu stays centered to the image and more of the image is revealed.

Not all computers and browsers default to 96dpi.

If you want to introduce the animated links back into the design it can be achieved in a graceful degrading manor with CSS3 transitions fyi.

Cheers oddz I’ll check it out when I get a chance!

DeathShadow, I have another query I hope you can clear up. With regards to displaying the background of the right hand menu could you tell me why you have done it this way - that is, by pushing the one underneath it down using background-position? Is the best way to do it? And could you just cut that one image up into 4 individual ones and display it like that?

Look forward to hearing from you,

Cheers, Jonno

You COULD split them up, but then you have to worry about the fact that it’s more separate file requests.

Every time a new file is requested from the server, it takes 100ms to 3 seconds depending on the connection and network congestion – the real world average most agree on is 200ms… A browser typically requests 8 (FF, IE) to 16 (Opera) files simultaneously, but for each file past that limit there’s little overlap meaning quite often that “ping time * 2” gets added to the page load time. First load (every time someone visits cache emptY) this can add up to minutes of page load time regardless of how fast the connection bandwidth is. A loose guesstimate of the penalty I use is:

(number of files - 12) * 0.15 seconds.

So a page with 48 separate files works out to 5.4 seconds overhead on a ‘middle of the road’ connection; but you get on a choked out work connection or free internet at your local Panera Bread or McD’s with a 2500ms ping time (bordering on timing out), it could EASILY go past a minute and a half for the same number of files. This is why typically I try to keep the number of separate files – at least for the template not counting content images – below 12… and try to avoid having more than another 12 content images. 24 images total seems a reasonable limit and keeps the page load time peppy; as opposed to the multi megabyte in hundreds of files monstrosities some people vomit up and try to call websites.

It’s why I also set a fixed limit of two external .js and two external CSS per media type limit. IF a design is going to need more than that, I throw the design away as being “non-viable for web deployment.”

Goes hand in hand with another of the formulas I use, which is a ballpark guesstimate of how big the HTML file should be.

1.5K + Text content * 1.5 + 128 bytes per form element (input, textarea, select, option, button) + 256 bytes per object (object, img, audio, video, etc.)

If an HTML file is significantly larger than that formula returns, it’s probably poorly coded. If it’s more than twice that, it IS poorly coded. Usually my code ends up at about 80% to 110% of that number.

Which goes with my page size limits – which for the past five years have been 70k ideal and 140k max… That’s HTML+CSS+IMAGES+Scripts. If a page goes past that and isn’t something that should obviously break that (like say, a gallery page full of thumbs) then it’s time to throw out the concept and start over. I’ve been playing with the idea of upping that to 96k/192k – but can’t bring myself to actually do it when my phone plan tops out at 768kbps, half my friends are in canada with their wonderful new bandwidth caps, and the mere fact that while I can get 22mbps at home, I travel 50 miles north to Coos County, 33.6k dialup (as a long distance phone call) is a good day for the folks up there! (also see the Dakota’s, much of Utah, etc, etc)… and that’s before we talk about server load; theres a reason my specialty was taking sites that were choking out dual quad-core Xeons and running them on a single core P4 at four times the traffic levels.

In any case, sliding backgrounds, aka “CSS sprites” (never liked that term – I think “sprite” I think of hardware sprites moving around the screen), are a common way to reduce that number of files and quite often result in a smaller file as well. When you color reduce to 17 to 256 colors a ‘palette’ of 768 bytes (256*3) is stored in your PNG/GIF/BMP… as four separate files that’s four palettes – as one file it’s one, saving you 2.3k… if the image shares like colors in a narrow palette you can use less colors – and with long horizontal runs of the same color as .png they can get really small.

The savings in file size AND handshakes means a faster loading page, even if it does end up a wee bit of extra CSS…

The same technique is often used on menus for hover states. I wrote up a quick tutorial about that not too long ago… draft content for cutcodedown when/if I ever launch the blasted thing. (Project has been stagnant since Dan’s passing since he was the idea guy, I was the content guy)

CSS Background-Image Sliding Doors Demo

All three menu states in the demo being stored in one file.

Very common technique – I use it a LOT. It’s a technique I suggest everyone learn – and use a LOT. Combine it with sliding doors, and you can do things like my Eight Corners under One Roof

Though as Oddz mentioned, CSS3 is supplanting a lot of these techniques and can be used to replace a lot of javascripted effects; not only do you have border-radius and box-shadow, there’s also border-image for when a simple corner just ain’t enough… I’m using them on some sites, but not all. Comes down to how important your IE support is and/or if you’re willing to bloat out the page with javascript to do it… Frankly, with the size of those scripts and the bloated IE conditional nonsense associated with them, I’d rather do it the old way if legacy IE support is needed.