1. Use a Reset Stylesheet

Different browsers are free to set default styles for font sizes, margins, and so forth. It’s a silly part of the specification but there you go. Rather than trying to eliminate these differences on a case-by-case basis, many web developers now make use of a reset stylesheet to set all margins to zero, remove all borders, standardize all font sizes, and so forth. There’s dispute over which particular features need to be reset; but to be honest having any one of them is going to be better than none. Here’s a few examples:

• Eric Meyer
• Yahoo!
• Crucial

2. Use a Browser Development Plug-In

When you’re learning it’s useful to be able to visualise “invisible” parts of your web-page – margins, padding, parent positions, and so forth. Unless you fancy setting debugging background and border styles, or guessing why your functions stop half-way through, I’d recommend getting a web development plug-in for your browser. Most plug-ins will let you dig trough your DOM, debug JavaScript functions, and provide statistics about document load times.

Firebug – plug-in for Firefox. This is an absolutely fantastic and invaluable tool for web development.
• Yahoo!’s YSlow – plug-in for the Firebug plug-in. Analyzes web pages and tells you why they’re slow.
• Internet Explorer Developer Toolbar – plug-in for Internet Explorer. It feels like it was written in an afternoon by someone who had no idea what web development involves, but there isn’t really any alternative for IE.

3. Learn JavaScript

Learning JavaScript is still a work-in-progress for me. When I started web design I assumed (please note that word “assumed”!) that JavaScript was a toy language, suitable only for pointless browser effects. Boy was I wrong!

JavaScript, especially with the rise of AJAX, is becoming less an optional add-on, and more and more a vital part of modern web applications. It’s an elegant language, possibly let down by poor IDE support, and used correctly, will let you jump your browser through hoops. Imaging Google Maps or Yahoo! Pipes without it.

4. Pick a JavaScript Framework, and Learn It

Learning JavaScript is all well and good, but once you start trying to use it in anger you soon learn that each browser has a subtly different DOM API (or not so subtly different in the case of Internet Explorer).

You could re-invent the wheel and spend ages handling these different edge cases, or, I’d suggest, you could learn a framework and let it do all the heavy lifting.

Not convinced? How about this jQuery code to stripe table rows (details omitted for clarity):

$(function() {
$(‘.stripe tr:even’).addClass(‘alt’);
});

(Yes I know in theory you should be able to do that in CSS. As always, Internet Explorer raises its middle finger to CSS theory).

Here’s a few links to some major frameworks:

• jQuery
• MooTools
• Prototype
• YUI
• script.aculo.us

5. Learn Photoshop

Ahhh, Photoshop. If you’ve only used simple paint programs before, using Photoshop is like emerging from a cave into the sunlight. (OK, that’s a bit of an exageration).
Traditional paint applications work on the basis that you want to change the color of pixels. Photoshop (at least for web design) works on the basis that you define regions, which are then styled. Pixels are assigned colors as a side-effect. The rules are:

• Layers are king;
• Selections are queen;
• Nothing should ever be destroyed or lost.

So as a little example, if something needs a drop-shadow, you don’t start trying to draw one. (That would destroy or change the original thing). You simply make sure the thing is in its own layer, and apply a drop-shadow style.

6. Use Semantic HTML – And No Cutting Corners

Web design usually starts with graphic design, but really it should start with the content and proceed from there. If you start with the visuals, it’s all too easy to fixate on why things don’t look right, and from there it’s slippery slope to using non-semantic elements and inline styles.

Start with the content; use appropriate elements without regard for style; and only once you’ve done that should you move on to writing an appropriate stylesheet. (Of course, you may sometimes need to add stylistic divs… although you’d be better off using JavaScript to modify the DOM, rather than modifying the source itself).

7. Find Out Why It Doesn’t Work – Don’t Shotgun-Debug

The HTML/CSS visual model is pretty complex: inline vs block elements; different position modes; and so forth. What makes matters worse is that there’s no definitive reference HTML renderer implementation: you can never be sure whether your page doesn’t look right because you’ve made a mistake, or whether it’s some browser bug.
This state of affairs can lead to shotgun-debugging: tweaking a value to see if it fixes the problem; tweaking another value and checking again; and so on and so on…

Obviously this way of learning isn’t ideal. If you ever want to learn, I’ve found that you need to be predicting the effects of your changes. Before you make a change, you should have an idea in your head of the expected effect. If the actual effect isn’t the intended effect, you need to find out why. Is your understanding of HTML/CSS wrong, or is it a browser bug? Test on more browsers, and if your understanding is wrong, correct it. (Of course, if it’s a browser bug, then you’ve learnt something afterall).

A corollary of this point is that tables should only be used for tabular data – there’s no usual need to use them for layout.

8. Test on Internet Explorer Earlier

You might have noticed from my snide comments about Internet Explorer that it’s not exactly my favorite browser. If I’m going to be fair, IE7 isn’t too bad, and IE8 promises to actually be standards compliant (gasp!). What bugs me is that (at the time of writing) about 30% of the world is still using an eight-year-old browser that doesn’t even get the basics of the HTML box model correct, and we web developers are expected to support it.

Anyway… I didn’t intend this paragraph to be a rant, so deep breath… and… we have to live with the situation as it is. Firefox has great standards compliance and great developer tools, so it’s tempting to use it as your primary development platform until right at the end, when you do cross-browser testing.

Don’t do this. I’ve learnt the hard way: you need to test your work at each stage, on all browsers. Even as recently as six months ago I was caught out by this: I spent a lot of time coding some web code that relied on z-indexing, only to discover that IE7 doesn’t support this feature fully. In the end I was able to bludgeon Internet Explorer into working properly with some JavaScript, but it wasn’t fun. Lesson learned: check each feature is going to work properly on IE before coding it completely.

9. Don’t Be Afraid of AJAX

Normal web-pages are pretty easy to understand. The browser makes a request; the web server sends back some HTML. AJAX is a little more difficult to understand, so I steered clear of it for two years.
I finally got stuck in when we started writing EasyAs123Web.com. I wanted the user to be able to edit the website in-place, so that forced the issue.

When you get down to it, AJAX is pretty simple.

1. User does something (eg clicks) in the browser;
2. JavaScript makes request to server (in a thread);
3. Server replies with an XML document describing what to do;
4. JavaScript received the reply and modifies the DOM based on that XML.

Of course, the devil is in the details, but a decent AJAX library hides most of that for you.

10. Charge For Old Browser Support

Asking a client if they need Internet Explorer 6 (or earlier) support is a recipe for extra work. They’re hardly going to say no when you phrase it like that. You then sit down and make a working website, and test it in IE6. Argh! Scrambled website! Eventually, you get it working, and you find that you’ve spent twice as long on the actual HTML/CSS as you planned to. Bad times.

Here’s my suggestion: treat older browser support the same as any other feature: as a chargeable item. Explain to the client that since older browsers work in a different way to modern ones (which they do), that’s extra work and hence extra cost. (I’d suggest approximately 10% on top). Explain that IE6 has approximately 25-30% market share, and let them make the cost/benefit call. Money has an amazing focusing effect: it forces people to really think about what they want and need.

Author:hackification