Kyle's Guide

Just a placeholder for now, move along. Going to add what I consider vital design & development practices for use somewhere else in more complete form.

I am writing this down so I remember it. I have been writing HTML & CSS since somewhere around 1998, and much of what I have ingrained in my brain is outdated (body{ text-align:center; } anyone?). I need to rid this of my brain, and this is the only way I know how.

CSS Practices

Unless otherwise noted, all rules here can be assumed to be fully compliant in the following browsers:

• IE7 & above
• Firefox 2 & above
• Safari 2 & above

Supporting any other browsers is foolish (even Firefox 2 & Safari 2 is borderline foolish). The only other browser you may consider is Opera — but I would strongly advise against it. There are more people using MobileWebkit than Opera users for most sites. Use your time wisely, affect the most users you can.

• The > selector is your friend. You should use it by default when writing rules like ul.subnav>li (instead of the more common ul li which affects all li descendants)

• Multiple classes are your friend.

• When you have the choice, use :first-child over :last-child IE (all) does not support the latter, while it does support the former. Mind that it is static in some browsers (so be careful with elements inserted via javascript)

Images

• Use pngs everywhere you need any transparency. IE6 died a long time ago.

• Empty space is relatively free in .gif and .png files, so use this to your advantage. When making image matricies, separate your icons/pieces by easily divisible numbers (25/50/100) -- makes the CSS math easy as pie

Version Control

Version control should be the default, not an exception to your code. Every single line of code you write should be in version control. There is absolutely no reason not to use it. This does not mean you need to have a remote copy. Using modern VCS (git, mercurial, bazarr, darcs, etc) it should take you somewhere around 10-15 seconds to create a local repository.

• Do not use Subversion. It is slow, requires network access, requires remote administration, does not have a concept of a local repository, and does not allow you to work with branches easily. There is no reason to use Subversion when you have the choice (fe: it's understandable if your company demands your code be checked into svn). Call this decision opinionated: I prefer the term intelligent.

• If you must use Subversion, subvert the process. Use tools such as git-svn to develop locally using git and push to your svn repo when ready.

• Branch all the time. New feature? New branch. You should almost never be coding on the master branch (only perhaps to fix small, known bugs). Branching helps keep your commits atomic since you aren't afraid to "break" anything.

• Keep your commits atomic. This means that the change is isolated and specific to one idea. All modern VCS allow to you commit parts of changed files, or only some changed files (so even if you have added 3 features, you can make 3 commits without changing your files). Learn how to use this feature in your VCS of choice (fe: git add -i) or find a GUI that helps you (fe: GitX on git/OSX)