Monday, May 25, 2009

Hitchhiker’s Guide to HTML development


My first encounter with the Internet was in the late 80′ties. A friend of mine was fetching games for his Commodore64 through a modem link. This modem looked like it had been stolen from a sovjet military base in a spy movie or something. In 1993 I started at collegue, and since then I have been using the Internet allmost on a daily basis. Initially I was using Bulletin Board Systems (BBS) through telnet connections, but in 1995 I discovered the World Wide Web. Using Emacs and Netscape Navigator I started to make simple websites. With blinking text, large headers, fuzzy GIFs and nasty colors it worked, but looked awful. I learned HTML at a time when the markup language itself was so new. As a result of this, I early discovered many of the pitfalls that you can encounter when developing thin web applications. Many years have pasted since then.



HTML has been extended several times, and it can be utilized further by JavaScript, Cascading Stylesheet and multiple forms of active content. This article will focus on how you can achieve success with web development and which pitfalls to look out for. It doesn’t matter if you are using static HTML or dynamic HTML through languages like PHP, ASP, JSP or whatever. The guidelines and pitfalls are the same.

Follow standards


During the browser war between Netscape and Microsoft, web developers often found themself writing if-then statements which checked for browser vendor before supplying browser specific HTML and possibly JavaScript code. Today most end users are using Internet Explorer, but that should not prevent a web developer from using markup that any other modern web browser can understand.



The way to do this without complicated if-then statements is simply to follow the HTML or XHTML specifications produced by the World Wide Web Consortium (W3C). All modern browser should follow these standards to ensure your website looks allmost the same in any browser. The World Wide Web Consortium also has a W3C validator service which checks your HTML/XHTML code and let’s you know if it doesn’t follow the standard. In general, you should keep your HTML files clean. In other words they should contain plain HTML/XHTML and nothing else.

Today many websites are not W3C compliant, causing a very bad user experience for those not using Internet Explorer. Also remember that the ones using alternate browsers often are those likely to shop online anyway, so make sure they are happy.

Use stylesheets


All colors, sizes and layout should be kept in CSS files (Cascading Stylesheet). In addition to a clean source, it also makes it incredible easy to replace all colors, sizes and layout without changing your markup. There is a similar W3C service for validating your Cascading Stylesheet. If you are not a web developer, but are getting your website made by a web design agency, you should demand that their finished product is fully W3C HTML/XHTML and CSS compliant.



Use naming standards


When naming HTML, CSS or image files there are a few standards you should enforce. Filenames should be written in lowercase letters only, and they should only contain A-Z charcters and 0-9 number. Stay away from national alphabet extentions or special characters. You should also limit the lenght of the filenames. The reasons for these strict rules are as follows: Your website might be developed on one operating system (for instance Mac OS X), but shall run on another operating system (for instance Linux or Windows 2003 Server). Some operating systems are case sensitive - others are not. Therefore it’s vital to use just one case all over the place, and lowercase looks far better than uppercase. When you refer to these files from within other files, make sure to use the same case (lowercase). For instance, imagine you have an image called logo.png that you want to refer to in an HTML page. The code <img src=”Logo.PNG“> would not work on most operating systems. Instead you should have written it in the correct case: <img src=”logo.png”>



Limit bandwidth usage


Unless you are developing a website for an art gallery or something, you should limit the number and size of images shown on your website. The general rule is: Only show images that have some relevance. Also you should take efforts to reduce the size of the image file. Ideally no image file should be larger than 25K, preferably much smaller.



When people visit your website they are not there to look at graphics (unless it’s an art gallery). They are there to read, and if it takes too long to load the page, they will give up and go somewhere else. Please remember that not all users are sitting on fast DSL connections.

Use Portable Network Graphics


In general the PNG format has better compression than JPEG. This of course will give slightly less quality to your graphics, but for the human eye it won’t make much difference. And then again, unless you are running an art gallery, image quality is not the first priority. In addition to JPEG and PNG there is another very popular format which are mostly used for icons. It’s called GIF. Unfortunatly GIF is a commercial format, so unless you have made your GIF files using an image editor that pays royalties to Unisys., you are in trouble. Both legally and finacially. PNG on the other hand is a free format, and can be used anywhere without having to think about royalties, and it’s of far better quality than GIF.



Be careful with JavaScript


When Netscape introduced JavaScript as standardized language to bring life to else boring HTML files, I thought it was a good idea. So did Microsoft, but their implementation of it extended Netscape’s standard in such a way it only worked in Internet Explorer. Web developers either had to make browser specific sets of JavaScript functions - or simply write JavaScript that excluded all browsers except Internet Explorer. Very few web developers actually took the time to write something that worked in multiple browsers. Naturally Microsoft’s implementation of JavaScript was full of security holes, so many end users completly disabled JavaScript regardless of which browser they were using.



Instead of writing lots of if-then statements to cover every possible scenario, I would recommend that you write JavaScript only when appropriate, and make sure to actually test it in mainstreaim browsers before you release it.

Avoid active content


Some people and companies uses active content heavily on their website. For instance applications written with Java Web Start, commersials written with Flash, charts written in SVG, and all kinds of other plugins. In my experience, end users hate this. Unless the active content has a valid use, don’t have it on your website! In addition to annoying users, it also spends lots of bandwidth.



Final remarks


Don’t panic! These were just my top pics, but I could also have written about pop-up ads, dead links or other issues. If you have any other guidelines for HTML development, please share them with me. Also keep in mind that travelling through cyberspace does not require a towel.



No comments:

Post a Comment