A couple of years ago I started doing more and more web development and web design, and less and less desktop development. Here's a few things I wish I'd known then: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:
2. Use a Browser Development Plug-In
- 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.
or Yahoo! Pipes
(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:
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
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).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!)
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.
- User does something (eg clicks) in the browser;
- Server replies with an XML document describing what to do;
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.Your Thoughts?
Got your own web development tips? Feel free to share them below!