Chiming in a little late… but for what it’s worth.
In answer to your ORIGINAL post, ALWAYS code for STANDARD COMPLIANCE browser. Don’t confuse that phrase for meaning “HEY! FF10 is standard compliant, I’ll just code for FF10”. Unless you are absolulety sure your audience is that narrow( is this an INTRANET page???) it really not a good idea to pick a VENDOR to specifically code for.
As long as I have segwayed into the topic of vendor , ( and possibly CSS3 vendor support) let’s hit on two things. Do include ALL available vendor syntaxes (-o, -moz, -webkit, etc). Yes, It’s going to seem redundant and and be a pain for a bit, but remember the goal is broad support ( it could be worse… I will address that in a moment). However realize your page si not going to look the same on all browser so allow some stylistic wiggle room ( if some old browser doesn’t get fades or rounded corner… it’s nothing to cry about) just don’t code/design in a way that a browser that doesn’t support your CSS3 bg gets blue text on a blue bg, for example. DO NOT however rely on bleeding edge selectors ( :NOT, :FIRST-OF-TYPE, etc). These are handy, and fun… and someday will be of great use but are styll 50/50 on support. Your page should gracefully degrade. That is If your design starts not to function in son browser it should still look "intentional " ( that’s the key to looking good) AND all the information and navigation should be accessible.
As Ryan pointed out coding in small sections and checking often is a great method, as code often interacts with itself. That is line 1&2 could work, line 2 & 3 could work together , even line 1 & 3 could work together … but LO! line 1, 2 & 3 dont work together . So, checking in every few lines helps you to catch those interactions as they happen (as opposed to having to do detective work … figuring out what is not playing nice with what).
As I said earlier code for compliance, and once you have your compliance working. Code in fixes for specific browser bugs, keeping in mind that you can always gracefully degrade.
I wonder if is there any account that tell the advantages and disadvantages of using php rather than a pure html code. Is there any discussion about that?
The right tool for the right project. You will ALWAYS NEED HTML. PHP is for automation. if your site gets to be 1000 html pages… do you want to update by hand or would you not rather have a handful of templates and a database? If your site is just a single message with a few sub pages, PHP is fun but overkill. Think of it this way, if you own a small brownstone in Chicago, do you NEED a riding lawnmower (PHP/ASP, etc)? at the same time if you own a golf course somewhere…would you SICK WITH a push-mower(pure HTML) ?
HTML5… use with EXTREME CAUTION… but experiment with it. It’s coming… eventually. I loathe to say this, but to also research polyfills. And always keep in mind GRACEFUL DEGRADATION and accessibility. Even as an Art Director, I still contend that a flashy & fancy page that cant be read or navigated is no match for a plain and CLEAN page that shows all it’s content and is easily navigated.