Refactoring HTML Improving the Design of Existing Web Applications

Elliotte Rusty Harold's REFACTORING HTML: IMPROVING THE DESIGN OF EXISTING WEB APPLICATIONS is also a pick for any library strong in web programming: it explains how to use refactoring to improve a web site or application and is written for all levels of programmers, offering a range of tips on how to modernize existing layouts, update old Web applications, and work with existing code and structure. <br />

The Web means mostly webpages written in HTML. The popularity of HTML is overwhelming. Yet it has well known problems. There is no intrinsic separation of semantic content from presentation details. And the tag syntax is very sloppy. <br /> <br />Harold explains in clear and strong terms why you should clean up your webpages. Mostly by using CSS and by making [and checking] that the pages are well formed and valid under XHTML. This is not a text on CSS, and if you are going to follow the precepts of the book, you will need another book, dedicated to CSS. The strength of Harold's message is in the clarity. He is trying to influence you in a top-down manner. To make these strategic decisions. <br /> <br />For example, by going with CSS, you simplify maintenance. Because files are factored into CSS files, which layout people can work on, and semantic content files, which can be the purview of others who are more involved with intrinsic information processing. The latter files also have the advantage that they can be used with different types of display devices and programs, and not just for the typical web browser. Think of cellphones, or devices for the blind. <br /> <br />The last aspect is another salient point he makes. Writing pages that are also accessible to the blind is not just good for that reason. It lets you focus not on what the page looks like, but on what it means. Why is this good? Because it improves the chance that search engines will look at and positively classify your semantic files. Search engines often deprecate presentation instructions and CSS files. They are also looking for files with high semantic content. <br /> <br />Also, by factoring using CSS files, the resultant set of files gets to be smaller, which reduces outgoing bandwidth from your web server. For large popular sites, this can be a cost saving. <br /> <br />While the writing of well formed and [better yet] XHTML-valid pages increases the chances that different browsers can accurately show the pages. The reason is that browsers have been written to pragmatically show HTML, where the tag structure is sloppy. To do this, a browser has to make certain display assumptions with a badly written file. The problem is that different browsers make different assumptions. And so some HTML files will not display well, or at all. <br /> <br />There are also other smaller level tips scattered thru the book. Like suppose you have an image that shows essentially only text. Replace the image with text. Less bandwidth is consumed. Plus search engines don't really do much with images. [Image analysis is very intensive and hard.] So giving them more meaningful text instead of images helps your page ranking. As a side note, some spammers do precisely the opposite. They have images which are mostly to display text. To evade a search engine or antispam software that keys off suspicious text. <br /> <br />In related wise, your image tag should always have an alt attribute describing the image. Helps the blind visitor. But mostly it helps a search engine classify the image. <br /> <br />There is one unintended ironic aspect of the book's last page. It talks about hiding your email address in the webpage from screen scraper bots run by spammers harvesting email addresses. One way is to use JavaScript to generate the address. The script is run by the visitor's browser as it displays the page. This is to evade spammers. The irony is that a spammer can use this very method, when sending spam email. Many antispam programs now use a blacklist, since spam often has links to the spammer's domain. But the programs usually [always?] check against static links in an email. The spammer can write JavaScript that dynamically makes links, to evade this. Sure, browsers that have JavaScript turned off will not show these links. But in fact, most users turn JavaScript on, because many websites use it. And the spammer might figure that the loss of links due to no JavaScript is greatly outweighed by being able to evade the now almost axiomatic use of blacklists by antispam programs. <br /> <br />Another example of how technology can be used for completely different and opposite purposes!