| SitePoint Sponsor |
Hey guys
I have a site where I have put in a header and a footer for a body text layer and for some reason it is creating space between the header and the main body and the footer and the main body. I am sure there is something simple I am missing, because I have been staring at code all day. Any help would be great!
the site is posted at
http://www.themastersinn.com/lbf_new.html
the css is posted at
http://www.themastersinn.com/lbf_layout.css
Why did you put the top_header image in an < h4 > tag and the footer image in a < p > tag? It's very unorthodox (in CSS-ology) to my knowledge.
Why don't you take the images out of those tags and set them up in appropriately named div tags?
Or, come to think of it (i.e. I just noticed it) try closing the "header" div before starting the "body_text" div. That might do it.
You should also be able to put the "header" and "footer" id divs inside the "body_text" div. Just leave a little more margin before the beginning and after the end of your text. Maybe?
First validate your code http://validator.w3.org and fix the errors it describes so that you can ensure the problems lie within the CSS.
Then I'd consider scrapping your navigation as there's no need for a table. Use an unordered list and don't use heading tags within your menu as they aren't headings.
Stu's CSSplay has some great examples as to how you should be doing this
http://www.cssplay.co.uk/menus/
As ValerieM has pointed out, next you should look at the rest of the markup as you should be using <h1> for your page heading and then using headings in order to show their sub-headings.
If the style of these are wrong then simply use CSS to change the styling
Add this to your css:
#header h5 img {
display: block;
}
Zero the top margin out on this <p> tag, as shown:
<p style="margin-top: 0;"><strong>LBF TAKES ON 3 NEW CHURCH PLANTS/strong><br>
Zero the bottom margin out on the <p> tag with the non-breaking-space in it, as shown:
<p class="style3"> </p>
<p style="margin-bottom: 0;"> </p>
Should'nt be using empty <p> tags to create some space between the content and border. Use some padding on a 'legitimate' styled element in your page.
Or, come to think of it (i.e. I just noticed it) try closing the "header" div before starting the "body_text" div. That might do it.
Why not just put the image which is currently in the header <div> in the body_text <div>
Its one less <div> to worry about.
It looks as though the poster is in an early stage in the learning process when it comes to using <divs> and semantic mark-up.
Refining ones skills comes with trial and error. I think we all were at that stage at some point.
osgood, zero-ing out padding and margin's for specific elements will have no impact when the global reset method has already been used at the top of the page
I agree that the original poster is in the early stage of the learning process but I don't think there's ever a time when I'd suggest fixing bad code with a quick fix rather than taking the time to fix invalid code.Code:* { padding:0; margin:0; }
It will cause more problems as problems won't be consistent especially once you start looking at cross browser support. It'll also get people into bad habits right from the start so I'd always encourage people to learn the correct way with valid, semantic code.
There's plenty of people willing to offer help and advice around here so there's no excuse for not taking the time to learn properly in my opinion.
I think he must have reset the margins somewhere else in the css. I didnt look thoroughly but I took the page down, added the fixes I metoined in my post and the spaces went, at least in Firefox.Originally Posted by csswiz
And that's why I personally think using the * method to zero out ALL margins on all elements as a starting point is a very very bad idea.
Because a 'strict' doctype is being used you would need the to add display: block; to the image within the <h5> other wise a small gap will appear under the image.
Thats why I mentioned to put the image in the main <div> because even though the gap would still be present it won't notice as the bg image will fill it in.
I agree that the original poster is in the early stage of the learning process but I don't think there's ever a time when I'd suggest fixing bad code with a quick fix rather than taking the time to fix invalid code.
It will cause more problems as problems won't be consistent especially once you start looking at cross browser support. It'll also get people into bad habits right from the start so I'd always encourage people to learn the correct way with valid, semantic code.
There's plenty of people willing to offer help and advice around here so there's no excuse for not taking the time to learn properly in my opinion.
I agree, howver one has to be realistic. It's a steep learning curve and quick fixes may be what is required at the time, given some people are on tight deadlines and budgets.
You're right quick fixed do mask for the real problem that's why I said 'you shouldn't be using non-braking spaces to create a margin'.
However what I suggested were NOT quick fixes for the problem the poster ask help with. They were legitimate fixes and ones which will put the page right, which is a bit more helpful than saying 'dont use a table for your navigation'
Its up to the poster to learn in their own time. Hopefully they will take on board the good advice that is offered.
And there it is...... right at the bottom:
div#body_text p{
clear:left;
font-family: Arial, Helvetica, sans-serif;
font-weight: lighter;
font-size: 16px;
color: #000000;
line-height: 22px;
margin:10px 10px;
}
The global reset method works fine. The only problem you'll have with it is when dealing with forms in which case I'd suggest something like Eric Meyer's reset method.
They are quick fix methods because you're overwriting styles inline to compensate for problems within the CSS which you've later discovered yourselfHowever what I suggested were NOT quick fixes for the problem the poster ask help with. They were legitimate fixes and ones which will put the page right,
The style should be modified in the div#body_text p otherwise he'll run into even more problems later where inline and external styles start conflicting if something needs changing.
This is completely mis-quoting what I said. You've neglected to mention that I've provided a link to numerous examples of how valid, semantic, unordered lists can be used for navigationwhich is a bit more helpful than saying 'dont use a table for your navigation''
I appreciate that there are sometimes tight deadlines and there are always quick fixes for problems but in this situation I feel it better to suggest how to improve the overall code to ensure that it's valid and will work cross browser.
Its fine but you obviously missed it..........as do many
They are NOT quick fixes....only TWO paragraphs in the body_text <div> need redifining.......otherwise you would alter them all by redifining the css in the body_text css. If I wanted a paragraph/s to be red I could either use a span style, a class style or some inline styling.......to just target that/those paragraph/s.........neither method is a quick fix.They are quick fix methods because you're overwriting styles inline to compensate for problems within the CSS which you've later discovered yourself
The style should be modified in the div#body_text p otherwise he'll run into even more problems later where inline and external styles start conflicting if something needs changing.
I originally didnt look at the css styling in the body_text <div> so maybe the poster could have used a different combination of css to achieve the required layout but theres really no 'quick fixes' involved in my reply.
Maybe this person at this time is comfortable with using a table for certain objectives. There IS nothing wrong in using tables whilst you explore other methods when you have time.....infact if you dont like other methods use a simple accessible table.This is completely mis-quoting what I said. You've neglected to mention that I've provided a link to numerous examples of how valid, semantic, unordered lists can be used for navigation
And whats validation got to do with anything? It proves nothing apart from all your tags are correct and present. It certainly DOSENT mean everyting is going to work correctly cross-browser as you seem to think, far from it infact. Validation is a misconception spewed out by people who live in cloud cuckoo land. I'm not infering writing bad code but beyond a certain point validation becomes a meaningless goal.I appreciate that there are sometimes tight deadlines and there are always quick fixes for problems but in this situation I feel it better to suggest how to improve the overall code to ensure that it's valid and will work cross browser.
I'd obviously missed what? The global method of resetting is consistent and works cross browser and that by redefining margin's or padding's to zero are completely unnecessary as there will be something else set somewhere else in the code which will be over-riding this.
I'd not had a look at the CSS properly as I'd always suggest the other steps I outlined above first before moving onto the step of correcting presentational code but you yourself spotted the problem which was over-riding the global selector which is a much better approach than simply throwing in margin: 0; because you can't track exactly where the problem lies.
Sorry, maybe you misunderstood my quick-fixes response. If HTML is invalid and doesn't use semantic markup correctly then you're dealing with a quick fix in my opinion.
Validation has got everything to do with it. If your code is invalid then you are at the mercy of the different browsers error handling which will be inconsistent.
If you code the HTML first, ensure that it's all valid then you'll be sure that any problems that arise visually are being caused by the CSS and you can address the problem.
I'm not one for telling everyone that they should deal with valid code; even some of my own sites don't validate. But, I know why my sites don't validate and why they can't but know that these won't currently cause any problems.
If someone is asking for help then ensuring that the HTML is valid with a valid doctype is always my first step otherwise it can be a nightmare to debug.
Validation isn't the be all and end all by any means but it's certainly important as an initial step.
There lies the issue. You see this at the top of the page:
* {
margin: 0;
padding: 0;
}
It suggests that all margins and paddings have been zeroed out which may not be the case, as in this instance. For some reason it catches you off guard, which is what happened to you this time. My reason for personally believing its a bad method to use, but each to his/her own.
Not really....this was a simple procedure to put right but you decided to look for something else, which was'nt causing the issue. Thats why, in my opinion relying heavily on validation is also a bad decision to make.Sorry, maybe you misunderstood my quick-fixes response. If HTML is invalid and doesn't use semantic markup correctly then you're dealing with a quick fix in my opinion.
Really.... come on you've been around long enough to know validation is no measure of a page rendering correctly x-browser. It gives you a better chance of course but one should'nt overplay the importance of it. A vaild page can and often does appear inconsistant x-browser.Validation has got everything to do with it. If your code is invalid then you are at the mercy of the different browsers error handling which will be inconsistent.
That wont stop people consitantly saying 'hey what's going on... my html and css validates but it doesnt look right in this or that browser...........validation is NO measure of how a page displays whether you like to think it is or not.If you code the HTML first, ensure that it's all valid then you'll be sure that any problems that arise visually are being caused by the CSS and you can address the problem.
Absolutely...as I said in my previous post beyond a certain point it become pointlessI'm not one for telling everyone that they should deal with valid code; even some of my own sites don't validate. But, I know why my sites don't validate and why they can't but know that these won't currently cause any problems.
Maybe, it depends. You have to make a calculated judgement about that when you look at the code.......some I just walk away from, others are not so bad.If someone is asking for help then ensuring that the HTML is valid with a valid doctype is always my first step otherwise it can be a nightmare to debug.
Learning to write html/css correctly is the most important step.....not validation. In my opinion you can do that quite easily without having to run to the validator to keep checking.Validation isn't the be all and end all by any means but it's certainly important as an initial step.
* {
margin: 0;
padding: 0;
}
This code will reset all paddings and margins. If you then choose to over-ride this and apply padding and margin's then you can't blame this bit of code. This gives you a base to work from and has no problems unless dealing with forms.
I think we're both arguing for the same thing but in a different way. I've never said that HTML validation will ensure that your page renders correctly but for beginners it's vital as it will ensure that the problem lies in the CSS and not the HTML.
If you're dealing with invalid HTML with 100's of errors where do you start looking? A problem could be because of a simple missing tag or could lie elsewhere in the CSS, by validating the HTML you are ensuring that the problem is within the CSS whilst also ensuring that browsers understand the code you're delivering too them.
As I've said before, if people write invalid code that isn't in the spec then you have every chance that future releases of browsers will understand the wrong code differently, hence why lots of people had problems with IE7 when it was released.
It's not hard to write valid code and I'm sure most experienced designers rarely have a need to use the validator as they know how to write valid code.
For a beginner who is starting out with HTML though then it's a great starting point and getting these beginners to write valid code right from the start should be a priority in my honest opinion.
That's obvioulsy where we agree to disagree. I think setting that piece of code can lead one into thinking that all the margins/padding are zeroed when infact they are not.* {
margin: 0;
padding: 0;
}
This code will reset all paddings and margins. If you then choose to over-ride this and apply padding and margin's then you can't blame this bit of code. This gives you a base to work from and has no problems unless dealing with forms.
Personally I prefer to work the other way around, leave all the margins set and just zero out the ones I don't need. Its the same difference in the end. It's all down to what you prefer. There IS no correct way its just how one prefers to work.
But as I've pointed out even if you make both validate it still doesnt mean youre not going to have rendering issues.I think we're both arguing for the same thing but in a different way. I've never said that HTML validation will ensure that your page renders correctly but for beginners it's vital as it will ensure that the problem lies in the CSS and not the HTML.
Sure... but often peoples answers will say 'theres 12 errors in your code put them right first and I'll help you. Those errors may be minor, like missing alt tags which play no part in the underlying issue. You have to access the code and make a judgement based on that, not just dismiss everything that doesnt validate.If you're dealing with invalid HTML with 100's of errors where do you start looking? A problem could be because of a simple missing tag or could lie elsewhere in the CSS, by validating the HTML you are ensuring that the problem is within the CSS whilst also ensuring that browsers understand the code you're delivering too them.
People had issues with IE7 because they most had issues with badly coded css not html.As I've said before, if people write invalid code that isn't in the spec then you have every chance that future releases of browsers will understand the wrong code differently, hence why lots of people had problems with IE7 when it was released.
For the beginner unfortunately the W3c validator will fail them. The catch 22 situation is you have to know html before you know what the validator is trying to tell you.It's not hard to write valid code and I'm sure most experienced designers rarely have a need to use the validator as they know how to write valid code.
For a beginner who is starting out with HTML though then it's a great starting point and getting these beginners to write valid code right from the start should be a priority in my honest opinion.
That's absolutely fine if you're happy working that way but I fail to see how it's hard to understand that the global selector will set everything to zero and then you can apply it where you want it instead of negotiating a browsers defaults? Even if you don't like the global reset method can you not see the advantages of the YUI or Meyer methods of reset?That's obvioulsy where we agree to disagree. I think setting that piece of code can lead one into thinking that all the margins/padding are zeroed when infact they are not.
Personally I prefer to work the other way around, leave all the margins set and just zero out the ones I don't need. Its the same difference in the end. It's all down to what you prefer. There IS no correct way its just how one prefers to work.
Completely agree, all this does is ensure that the problem lies within the CSS.But as I've pointed out even if you make both validate it still doesnt mean youre not going to have rendering issues.
Quite often this is the case but if they're simple fixes, I'd rather explain how to fix these as you never know how future browsers will render these error. They seem small now but what if a browser in the future decided not to display images without the alt attribute seeing as this would be invalid HTML? The alt attribute is also vital for accessibility which is certainly a good habit to consider.Sure... but often peoples answers will say 'theres 12 errors in your code put them right first and I'll help you. Those errors may be minor, like missing alt tags which play no part in the underlying issue. You have to access the code and make a judgement based on that, not just dismiss everything that doesnt validate.
If you understand topics like accessibility and search engine optimisation from the start by writing valid and semantic HTML then it's not such a huge burden latter on. Validating HTML isn't about being able to stick a badge on your site, it has other benefits.
A lot of these were probably due to hacks in the CSS so I do agree but browsers do rely on error handling and each one is different so you never know how that error is going to be handled in future browsers.People had issues with IE7 because they most had issues with badly coded css not html.
Isn't that the point? You wouldn't try fixing a car until you understood the mechanics of it so why would you be writing a webpage until you understood HTML?For the beginner unfortunately the W3c validator will fail them. The catch 22 situation is you have to know html before you know what the validator is trying to tell you.
You may be able to put together the basis of an engine on a car and tie a few bits together with a bit of rope so that you get up and running but you'd have no guarantees as to how long that car would remain running.
Its NOT hard to understand. That's not the debate. The debate is whether or not it is better to leave the default margins on elements or zero them out. In my experience it's better to leave them at the default settting, in yours, well obviously it's not.That's absolutely fine if you're happy working that way but I fail to see how it's hard to understand that the global selector will set everything to zero and then you can apply it where you want it instead of negotiating a browsers defaults? Even if you don't like the global reset method can you not see the advantages of the YUI or Meyer methods of reset?
Don't mention Eric as I don't regard him as a mainstream web-developer. Yes, he knows his css stuff but at times what he does is very experimental and I wouldn't advice anyone new to css to follow that route. That's probably why I see so much css that uses a sledge-hammer approach to crack a nut.
Quite often this is the case but if they're simple fixes, I'd rather explain how to fix these as you never know how future browsers will render these error. They seem small now but what if a browser in the future decided not to display images without the alt attribute seeing as this would be invalid HTML? The alt attribute is also vital for accessibility which is certainly a good habit to consider.
Look at the bigger picture. It's not in any browser producers interest NOT to support invalid code, why? Simply because so many sites like Amazon, Yahoo, etc etc are not valid. The first browser that sticks its neck out and spits out invalid code will die a quick death. As much as that's sad news, its a fact.
In the case that we are discussing there's is nothing wrong with the solutions I provided.
We are not discusssing accessibility just the ability to provide a simple answer to a simple question. Leave it up to the developer if they want to entertain valid code or accessibility. They know their target audience better than you or I do.
Let me reiterate that I am not supporting ugly code just I don't care for people being told all the time 'your site doesn't validate' as if that's the answer to solve all problems.
In this case even if the page did validate there would have still been a gap below the image as a 'strict' doctype requires display: block;. That has NOTHING to do with validation, but everything to do with knowing about doctypes and html/css.
It's has NOT been proven that valid and semantic code is the real key to higher ranking in the search engines. Many sites you see at the top of google use awful code. The single most important aspect of high rankings is incoming links. The spider will then assume the site is of greater importnace and rank it higher than anything that is valid and semantically written.If you understand topics like accessibility and search engine optimisation from the start by writing valid and semantic HTML then it's not such a huge burden latter on. Validating HTML isn't about being able to stick a badge on your site, it has other benefits.
The only other benefit I can think of is it makes maintenance easier but what with this I must make my page validate 100%. So what if there are some minor errors. Take Flash for instance. Does anyone really waste time with making that validate by writing the file to the page instead of just inserting it into the page and why on earth do they, if they do?
Sure you don't but you don't know for sure that any future browser will support tags that are deemed to be alright to use now. The chances are they will because it's in their interest to do so.A lot of these were probably due to hacks in the CSS so I do agree but browsers do rely on error handling and each one is different so you never know how that error is going to be handled in future browsers.
Most errors in new browsers will be caused by it not rendering css correctly, not html.
I agree but I dont subcribe to beginners being told to go to the validator because chances are they would just be confused by the results returned. I have difficulty sometimes interpreting what it's trying to say. Fortunately I know my way around the html code so I can, if needs be, track the fault down. Personally I think you need to know html before the validator can be of any use and when you do know html it become a bit obsolete.Isn't that the point? You wouldn't try fixing a car until you understood the mechanics of it so why would you be writing a webpage until you understood HTML?
However IF it helps some people then all well and good but I dont think it will help evreyone.
I'm not suggesting anybody do anything of the sort. I'm suggesting this overplay of validation is an issue which leaves people suprised when things still dont work.You may be able to put together the basis of an engine on a car and tie a few bits together with a bit of rope so that you get up and running but you'd have no guarantees as to how long that car would remain running.
I suppose we're both coming at it from different angles and I do appreciate your point of view.
I see problems on here regularly where code's full of errors, has no doctype, has been designed initially for IE6 and then the designer is amazed when it doesn't work in standards compliant browsers.
My approach to these problems is to try and get these people into good habits. Yes, the current problem doesn't relate to bad HTML but the next time and the time after that once they start getting into complex layouts it may be but by this stage they'll be in the habit of writing bad HTML and then writing CSS to compensate for this so I'd rather promote good habits and best practice from the start.
I'm not trying to overplay the importance of validation but for people just starting out and who don't know the difference between valid code and bad code, I feel it's important to educate.
I completely agree that the validator is a little hard to understand but I'm always willing to explain validation errors if someone doesn't understand them
e.g. http://www.sitepoint.com/forums/showthread.php?t=506582
There are good habits and ones that can be a bit paranoid. I agree it's in the best interests for some to fully understand html/css others don't care but need an answer to their current 'crisis'.I suppose we're both coming at it from different angles and I do appreciate your point of view.
I see problems on here regularly where code's full of errors, has no doctype, has been designed initially for IE6 and then the designer is amazed when it doesn't work in standards compliant browsers.
My approach to these problems is to try and get these people into good habits.
The issue is how does one learn good html. Personally, as I've said before, I don't think it's through the validator service. The only way, unfortunately, is to practice, practice and still more practice. A little at a time adds up to a lot in the end.
One can only hope that those that are serious will take onboard answers given here in small sizable chunks and implement them into their next project. It's a bridge too far in my opinion to expect a fairly inexperience operator to suddenly re-write all of their current code when sometimes it can be solved with simple remedies.Yes, the current problem doesn't relate to bad HTML but the next time and the time after that once they start getting into complex layouts it may be but by this stage they'll be in the habit of writing bad HTML and then writing CSS to compensate for this so I'd rather promote good habits and best practice from the start.
Yes, it is important to educate. I think its more advantagous to latch onto those people, perhaps like maxdesign.com.au who use a simplistic approach to css and html and yet one that gets the job done. Take some of their code down, look at it, see what's being used and how. It will get you a lot further than any remarks which the validator throws back at you.I'm not trying to overplay the importance of validation but for people just starting out and who don't know the difference between valid code and bad code, I feel it's important to educate.
Thats at least good to know.I completely agree that the validator is a little hard to understand but I'm always willing to explain validation errors if someone doesn't understand them
Posting Permissions
Bookmarks