Putting Your Best HTML Interface Forward

[Guest.Visitor]

** This thread discusses the article: Putting Your Best HTML Interface Forward **
** This thread discusses the Content article: Putting Your Best HTML Interface Forward **
0

[rdean400@yahoo.com]

Putting Your Best HTML Interface Forward

** This thread discusses the article: Putting Your Best HTML Interface Forward **
The article mentions that IE 5.5+ renders standards-compliant code better than Netscape 6.1. It must be mentioned that IE's rendering engine for CSS/DOM has some non-standard extensions - *not* endorsed by W3C. Many of these extensions are formatting related, and the use of them would cause documents to be rendered "better" in IE than in Netscape 6.

[Guest.Visitor]

Putting Your Best HTML Interface Forward

** This thread discusses the article: Putting Your Best HTML Interface Forward **
Indeed! In other words, IE is better because it renders IE specific incompatibilities better! Although IE is very commonly used, there are many other browsers and user agents out there accessing your web pages. If you don't want to risk offending or alienating visitors, you need to be aware of the differences. It's not difficult to write HTML and CSS code that is W3C compliant. And there are verification tools that can help you write W3C compliant code. (Such as the W3C HTML Validator.) Consider running your HTML through a validator an essential step, like CRTBNDRPG. Developing web pages using IE is probably a bad strategy to begin with. As has been pointed out, it's not as W3C compliant as other browsers like Mozilla, NS6, Opera, and Konquerer. (The latter two are probably the most W3C compliant out there.) I've coded HTML that looks fine in Konq and Moz, but looks crappy in IE. For example, strings of IMG tags - I've seen IE string out IMG's in one long horizontal line, where Moz and Konq spill onto subsequent lines. Another problem with IE is its support of an MS-specific non-standard code page. Non-IE users often see blobs, blanks, or question marks in place of certain non-standard characters. At best, it's just a nuisance that reflects badly on the webmaster. At worst it may cause legal problems since one of the non-standard glyphs is the TM symbol. This is an easy problem to fix, since there are straight-forward alternatives to most of these non-standard characters. The Demoroniser tool can help fix your documents. As always, the best strategy is to develop your HTML/CSS using a W3C compliant browser (like Moz, NS6, Konq, or Opera), and then test on IE. What about tailoring the HTML/CSS to the users specific browser? Some try this, but that just increases the resources required for developing and maintaining your web site. Not only that, but the strategy may not always work. There's no guarantee that the USER_AGENT string accurately reflects the users browser. Anyone can spoof any of the environment variables passed to the server. And in fact, some browsers (like Konq and Opera) actually provide that capability to the user. Why spoof the USER_AGENT? Well, I know of one malicious webmaster who actively tries to prevent Linux users from visiting her site. Even MS tried to lock out certain specific user agents from its MSN site! Now let's consider JavaScript: The situation there is even more complicated, since no two browsers implement the same JavaScript language. As soon as you start using JS, you need to test on all possible browsers that might possibly visit: IE, NS, Konq, Opera, you name it. The most annoying thing when browsing is to get that "JavaScript Error" popup. As discussed earlier, you can't count on USER_AGENT to identify the browser, and so you need to limit yourself to a JS subset that can run on all possible browsers. To emphasize the point again, don't forget to test your JS on all possible browsers, not just your favorite. Furthermore, you need to accomodate the fact that some users will have JS disabled in their browser, for whatever reason, sensible or not. Data validation using JS is fine, but remember that requests to your server might not have passed through that validation code, and so you still need to validate data on the server. In addition, web site navigation using JS not only locks out those with JS disabled, but it also prevents webbots (like the Googlebot) from properly indexing your web site. For many web sites, the primary source of visitors is from search tools like Google. Now let's think about client-side Java. OK, that's enough thinking about Java. (Of course, if you're developing an intranet application and you know for a fact that all users use one specific browser, then you could decide to limit your support to that one browser. But this would also limit your options when time to upgrade your systems and clients.)