On 1 Sep 2008, at 12:27, Ben Buchanan wrote:

I use basically the same approach, but I code for Opera; checking in Firefox and Safari. Then hack for IE at the end. On very large builds I do the occasional check for IE as well just to make sure things haven't gone really badly wrong in IE in some unpredictable way.

Same here, more or less.

My coding environment is Coda on a Mac, which provides a constant webkit-based preview on the fly. That pretty much takes care of Safari (mac). Then I make frequent checks in FF and Opera to make sure that there are no inconsistencies, with FF probably taking priority over Opera because of its handy development add-ons.

Lastly, I make occasional trips to IE 6/7/8 to check out that browser's own 'exciting' take on things. These tend to be required more frequently in the early stages of page construction when the basic structure is being laid down. That is the time that I most commonly run afoul of IE bugs and/or Trident idiosyncrasies. I try to correct these as I go rather than waiting until the end because otherwise it can be much harder to trace the root of a problem.

On 1 Sep 2008, at 13:30, willdonovan wrote:

I find that if I'm attempting to make the site cross browser, try not to make the CSS too complicated.

I agree. Keeping the CSS simple and thus maintaining the page in 'standards mode' means that many of the IE box model problems can be avoided. Unless I have an overly complex page design I can generally avoid most IE hacks altogether (although I still add in things like display:inline for floated content)
--
Rick Lecoat
www.sharkattack.co.uk



*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************

Reply via email to