Curious how Future Now's HTML objectively stacks up against its critic's HTML? Wonder which criteria we consider important in evaluating the effectiveness of the various compatibility issues that face designers? Below are some comparative analytic results. Several of these links generate a real-time report – be patient if the results take a minute or so to load for you.
The following comparisons address the issue at hand - errors and browser compatibility:
Public sites should render in all browsers at an acceptable degree of visual consistency. While pixel precision may not be possible to achieve in all situations, priority should be given to content readability. Compare the results for our site versus Ms Caroll’s site (at a resolution of 800x600). The short of it: both sites have minor browser compatibility problems.
HTML elements should be used according to their intended semantic meaning. For example, the table tag is for displaying tabular data, not layout element positioning.
We code using semantic markup; Ms Caroll codes using tables and spacer images. Iva Koberg of LiveStoryboard explains the far-reaching implications of favoring meaningful semantic markup over pixel-precise layout.
Designers who choose to target 100% pixel precision between browsers and operating systems by using tables for layout often neglect the benefits of clean semantic markup - the more compelling issue at stake here. Logically structured semantic markup provides numerous benefits that should not be ignored: faster rendering, simplified maintenance, forward compatibility, wider audience reach, and it helps search robots better interpret, index and rank your site. All that is going to directly impact your online conversion potential.
Behind the HTML/CSS scenes are other important compatibility-related issues:
A Web site’s code should be easy to maintain. Constant change is a given in this biz. When we want to make a change, we fuss with a line or two of code and we’re done. Given the missing spacer images and deprecated elements on Ms Caroll’s home page alone, she’ll spend substantially more time recoding changes. That time carries a price tag!
(My sincere thanks to Bryan Eisenberg and John Quarto-vonTivadar (HTML gurus par excellance!), especially to Iva and Rob, the aces-up-our-sleeve at LiveStoryboard, for all their help with the critical connections between features and benefits!)