!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Streamline Training & Documentation: Browser Compatibility Best Practices

Saturday, July 11, 2009

Browser Compatibility Best Practices

The learning aids at developer.com are generally more technical than trainers need for their work, but there is one particular item I've benefited from because it addresses questions I've had concerning how to develop the Streamline Training & Development website in a way that ensures compatibility with all major browsers.

Jeff Ryan, an enterprise architect, has written a tutorial about six printed pages long that explains how the creation and widespread adoption of Web standards has simplified the process of developing a website that will render correctly for visitors using different browsers.

The key portions of Ryan's article for me, and I suspect for other people who are not hardcore software developers, are the sections on best practices and pitfalls.

Ryan describes eight best practices:
  • Use Firefx as the primary browser for development because Firefox adheres closely to W3C standards.


  • In development, periodically test the application in Internet Explorer and other supported browsers. This testing should encompass different versions of the browsers.


  • Use Internet Explorer as the primary browser for quality assurance. This will help catch errors that slipped through the testing done during the development phase.


  • Specify a DOCTYPE to explicitly declare the structure of the webpage. Ryan recommends specifying strict use of HTML or XHTML. "The strict DOCTYPE keeps you honest in adhering to standard and valid markup document structure."


  • Utilize global CSS to separate document structure from presentation and to abstract browser presentation differences.


  • Use third-party libraries in lieu of custom JavaScript code for cross browser support.


  • Utilize Firebug and web developer plug-ins. "It is very easy to inspect and manipulate the structure, presentation and behavior elements of your web page at run time using these tools."


  • Develop a browser compatibility knowledge base. For an individual such as myself, who is doing light-duty web development, this means keeping track of lessons learned in any convenient way that allows easy retrieval and review.
There are three pitfalls that Ryan highlights:
  • Using browser-specific plug-ins (e.g., ActiveX controls). Doing this is obviously asking for compatibility problems.


  • Using code forks. This is an old-fashioned, time-consuming way of catering for multiple browsers that produces hard-to-maintain code.


  • Not considering the implications of any CSS hacks you use. CSS hacks, which take advantage of browser departures from adherence to standards, may be adopted to work around browser compatibility issues. "However, care must be used to ensure they do not create maintainability issues, nor impede behavior in future browser versions."
For me, the bottom line in seeking to understand best practice in achieving browser compatibility for my website is: I end up with pages that my visitors find user-friendly, that have been produced as efficiently as possible, and that can be maintained efficiently.

###

Labels: