I wasn't sure if I should post this in the XHTML/HTML and CSS section, or in this one — if a mod would like to move it, feel free.

 

Hi everyone,

 

I posted this in another thread, and I thought it might be useful as a post on it's own as it contains a lot of generic tips and advice on web design theory and best practice.

 

I will update this post periodically with more tips and advice, as I've only scratched the surface with the ones below. I'm also toying with the idea of splitting the post into sections/areas/topics to make it easier to digest — let me know if you think that would be a good idea.

 

Good luck!

 

 

So without further ado, here are some of my main tips and advice:

 

The Basics

• Never forget to use a valid DOCTYPE, you will just open yourself up to a world of hate otherwise. The only time you wouldn't use a full DOCTYPE is when you deliberately want to trip "quirks mode".
  
• Write all your tags (<html>, <div>, <ul>, etc) in lowercase. This is usually just a personal preference, but it's actually the correct way and makes things a lot easier to read through.
  
• Make sure you keep your tags in order. For example, this is the correct order for a basic HTML Strict page:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
  
  <html>
  <head>
  	<title>Title Of Your Website Goes Here</title>
  	<!-- Meta Tags -->
  	<meta http-equiv="content-type" content="text/html; charset=UTF-8">
  	<!-- Javascript -->
  	<script type="text/javascript" src="path/to/js/file.js" charset="UTF-8"></script>
  	<!-- CSS -->
  	<link type="text/css" href="path/to/css/file.css" rel="stylesheet" media="screen" charset="UTF-8">
  	<style>
  		/* Inline CSS */
  		⋮ css code would go here
  	</style>
  </head>
  <body>
  	<h1>Title Of The Page</h1>
  	<p>Hello World!</p>
  </body>
  </html>

  
  

• Make sure you close all the tags that need to be, and that they are correctly nested.
  • For example, this is incorrect because the tags are closed in the wrong order

    <p>Lemons are <strong>cool</p></strong>

    
    

  [*]Keep your code semantically correct — in order, and using the correct element for the job. For example, don't use random <span> and <div> elements (commonly known as "Div-itus") when you could do it just as well without it. For example, don't wrap text that you want italicised in a <span> (styled with font-style: italic;) when there are perfectly good HTML elements for this — <i>, <em>, <cite>, etc. Just make sure you use the right one for the right situation.

  • The most common issues with Div-itus is that beginners tend to contain absolutely everything in random <div> elements. Most of the time the element that is being contained, like a list — <ul>, would perform perfectly fine without a <div> containing it. This is a hard issue to teach, you'll probably just pick it up over time.
    
  • If every time you add an element you think to yourself, "Is this the correct tag for the job?", you will become a much better coder. You can use the w3schools tag reference to see a list of what is available to you.
    

  [*]K.I.S.S. — Keep It Simple Stupid. If you're trying to do something in HTML or CSS, and it's turning out to be a dogs dinner and really complicated, then you are probably going about it the wrong way. If you keep things as simple as possible (and no simpler ), you will find that most problems can be overcome with a lot less code/no extra code.

  • This relates in particular to cross browser compatibility, where things tend to get quite overwhelming for beginners.
    

CSS and Javascript

• Keep your Javascript and CSS external — Using inline code while developing is fine, but when you go live move it into external files that you link to in the <head>.
  • Don't use the style="…" attribute and try to avoid things like the onLoad="…" and onMouseOver="…" attributes in your HTML elements. These just cause headaches, the correct way is to style elements through external CSS and apply Javascript through external Javascript (using DOM).
    

Cross Browser Support

• Make sure your CSS (and HTML / Javascript) is cross browser compatible — it works and looks the same (or degrades gracefully) in all the major web browsers.
  • Avoid unnecessary CSS hacks to accomplish certain things (usually for IE 6), they just cause extra problems in the long run. You can usually accomplish the same thing by re-factoring your CSS and trying a different method — there are usually many ways to accomplish the same effect in CSS.
    
  • If you find you must do something different for IE (eg. PNG fixes, box model issues), then stick that code in a separate file (eg. ie6.css) and link to it from the header inside conditional comments. That way you avoid clogging up your main CSS file with random IE fixes, they can only be seen by IE, and it makes things a lot easier to update/fix/change in the future.
    

Validation

• Make sure you constantly check your site for validation by using the W3C Validator.
  • Valid code is more likely to work correctly across the browsers, and will encourage you to code to a much higher standard.
    

Nice one. I hope this expands in a good way, organized and so on.

 

Also, <em> is for emphasized text. For italics you can use the good old <i> tag.

You are correct, sir! For some reason I completely forgot about the <i> tag (thought it was depreciated! ) — it has been changed.

Maybe we should put up some examples of the usage of <em> and <strong> as well as when <i> and <b> is appropriate. The <i> and <b> examples needs to be well thought out not to cause confusion though, as we don't really want a new influx of these tags.

Of course — it's just an example of when to use a tag, rather than a debate over which one to use. I'll probably change the example to something less debatable, though — hopefully that will cause less confusion.

I've neatened up the first post a bit and moved some of the tips into separate areas.

 

If anyone thinks a tip should be moved into another area, let me know and I'll change it if I agree with you.

Great guide to semantic HTML. It (and others) advises against the use of the <i> element completely, rather use <em> instead.

See! I knew I had a reason behind using <em> — I'm going to switch it back to <em> for the time being. If anyone can come up to me with a good enough reason for using the <i> element, then I will happily change it back.

 

My reasons for using <em> are because <i> is a visual tag, not a structural one, and so holds little value with accessibility and semantics.

See! I knew I had a reason behind using <em> — I'm going to switch it back to <em> for the time being. If anyone can come up to me with a good enough reason for using the <i> element, then I will happily change it back.

 

My reasons for using <em> are because <i> is a visual tag, not a structural one, and so holds little value with accessibility and semantics.

 

Exactly why we should use <em> in the semantic web! Also looks like it (and other decorative only elements) may get deprecated with HTML 5.

Nice read RobH!

Thanks mate, hopefully it will help some people out. That is the aim anyways!

Exactly why we should use <em> in the semantic web! Also looks like it (and other decorative only elements) may get deprecated with HTML 5.

 

 

Semantics aren't just some kind of HTML concept - they come from the copy. It's just that in the English language, according to established styles, we use italics for many reasons, including:

• emphasis - as in that's not mine!
  
• for technical terms
  
• for foreign phrases - e.g. c'est la vie.
  
• for slang and other idiomatic phrases
  
• certain naming conventions and technical terms - e.g. hms victory
  
• to express internal monologues and other mood-setting sentences from the main prose - e.g. Gosh copy-editing is dull thought Bob.
  

This list isn't even everything - so the question should be why there aren't enough tags!

There are of course <cite>,<dfn>, <q> etc. and, for semantics these should always be used before resorting to <em>.

 

The point being? Italics or any other tag shouldn't really be used as just a design element because they look nice (IMO) - or if they are there should be a general tag called <pretty> or whatever that explicitly states it's not semantic! Italics aren't a decorative only element they're just misunderstood!

Some great points there, and I totally agree with you.

 

I think I'm going to change the example as it's causing a bit of controversy, it was only meant to help explain the situation rather than be a hard and fast rule on italics.

 

[Edit] I've reworded it instead to include more examples for italic tags, and explaining that you should pick the right one for the job.

Italics aren't a decorative only element they're just misunderstood!

 

Interesting notion. I agree with your conclusion. Sometimes websites go so deep into aesthetics they forget they should have a function. More often than not the function is to inform, not to appear pretty. However a balance of aesthetics and functionality gives the website a professional look and feel. I guess the challenge is finding that balance.

 

"Balance" itself might also be a biased term susceptible to personal preference.

 

Thanks Rob! (formely known as RobH ) for the tips. I always throw too many Div's into the pages I design. Must figure out how to cut down on that.

 

Cari.

Thanks Rob! (formely known as RobH ) for the tips. I always throw too many Div's into the pages I design. Must figure out how to cut down on that.

 

So long as you take a look at all the available HTML tags and what they are for, you'll find it gets much easier to work out which ones to use, and when.

 

You can always ask plenty of questions on here if you're not sure

Some great points there, and I totally agree with you.

 

I think I'm going to change the example as it's causing a bit of controversy, it was only meant to help explain the situation rather than be a hard and fast rule on italics.

 

[Edit] I've reworded it instead to include more examples for italic tags, and explaining that you should pick the right one for the job.

 

 

Just reread my earlier post and probably was a bit italicy! I just sometimes get the feeling 'semantics' sometimes takes on a whole different meaning as some sort of technical HTML thing. The short version? Getting the 'inline' elements spot-on makes differentiating text with different functions easier and means you will truly get separation of copy and CSS. That can only help your designs and prevent 'hunt the <em>' nightmares if anything changes later on.

Sorry if your excellent post got a bit hijacked there Rob!

Don't worry about it! I appreciate the post, it made me realise that I need to explain that point a bit better.

 

I'm going to (re)write this all up into a big "Rob's Web Design 101", maybe with video tutorials (depends if I put them on my blog or not ) — but this post will have to do until then.

You can always ask plenty of questions on here if you're not sure

 

Awesome! Now that you mention it... *pulls out a never ending list of questions*

 

Just kidding. My main question at the moment is just positioning, but that's probably a question I should ask in a CSS specific topic. Or ask google... I'm just not entirely sure what the position inherit does and whether I should use it more. I think I understand relative... I'm sure I understand absolute. But I'm sure with practice I'll figure it out.

 

As for HTML. I've come to the conclusion that <ul> is very very handy. And I regularly use the a:hover feature...

 

Cari.

Right.... just one last word on a fundamental part of design and then I'm going to button it! It is a word very close to my heart and I apologise for a breach of etiquette for 'shouting' this but it makes a discussion on semantics moot if we don't mention....

 

 

COPY!

 

Right.... just one last word on a fundamental part of design and then I'm going to button it! It is a word very close to my heart and I apologise for a breach of etiquette for 'shouting' this but it makes a discussion on semantics moot if we don't mention....

COPY!

 

 

I'll make sure to include something about it (probably linking to your posts!) when I add more to the first post.

Awesome! Now that you mention it... *pulls out a never ending list of questions*

 

Just kidding. My main question at the moment is just positioning, but that's probably a question I should ask in a CSS specific topic. Or ask google... I'm just not entirely sure what the position inherit does and whether I should use it more. I think I understand relative... I'm sure I understand absolute. But I'm sure with practice I'll figure it out.

 

As for HTML. I've come to the conclusion that <ul> is very very handy. And I regularly use the a:hover feature...

 

Cari.

 

Inherit is a value that can be used on any CSS property — all it does is assigns the value of the same property from the parent element. For example, if you had a <p> within a <div> element, and you set the value of a property on the <p> to inherit, then it will use the value from the parent element, the <div>, if it has one for that property.

 

Be careful, though, as Internet Explorer has pretty much null support of the inherit value.

Moving away from element/tag pedancy , I'd like to chuck in another one: testing.

 

Test, test, test. If you're going to do it, might as well do it right (I preach but sometimes fail) and that means testing in the latest browsers, testing in old browsers, testing in text readers (maybe going a bit far for most), changing the screen resolution, upping the text size with the built-in browser features and testing for print - yeah sounds weird, but people still want to print some stuff from the web and it doesn't hurt to go that extra mile (or centimetres as it isn't hard).

 

Also testing for colour contrasts - Snook's got a tool to help compare individual colours with another or you can use GrayBit to render the whole iste in B&W.

 

On the validation side, might want to chuck in the CSS validator.

Some excellent areas there Badmotherz, I'll make sure to add something about them when I expand the guide.

Rob... under your CSS and Javascript heading, you have got this phrase... "...and try to avoid the script="…" attribute..." - er... correct me if I'm wrong, but there is (and never was) a script attribute...?

You are correct, I forgot to change that, doh! I meant to say things like onLoad="", onMouseOver="", etc — thanks for pointing it out.

 

[Edit] Fixed — thank you.

I've got one! (From Bulletproof Web Design) - make sure your site holds together in the event of someone re-sizing the text using the browser settings...

Be careful, though, as Internet Explorer has pretty much null support of the inherit value.

 

What's new

 

IE is exasperating.

 

Thanks though. That does make a lot of sense. Guess it's pretty self explanatory.

 

Cari.

Great thread!!!

 

Read over everything. Thanks to Rob and everyone else who contributed. Bookmarked this thread for future study.

Very good work Rob.

 

My 2 cents:

What about write about "comments" ? Sometimes people get a wrong idea about comments. They think that we need comment EVERYTHING... what is wrong. In my view.. the effort in comment must stay in the CSS code. The xhtml is kind of logic, natural.. i think just the major parts.. or something that you did in a way that is off of your standards.. you should comments. But the CSS ... depends the project.. become a very big file... and without the comments you can get lost easily. This talk about that comments make the file bigger... is kind of stupid... i mean..is true.. but some ks.. in a world with high connections.. is not the problem... even with dial up connections.. is not the problem... I am sure that the user will not scream with you because was needed more 0.0002 seconds to load the page. :-)

 

Again.. great post!