In The Beginning

Over the past five years, the Club has grown enormously, and the website, initially about a dozen pages produced using a simple, freeware WYSIWYG (What You See Is What You Get) html editor, has grown with it. In that time too, the various flavours of markup languages have developed and become more sophisticated, as have the browsers themselves. Our simple webpage html coding was beginning to display strange anomalies.

I and other Club members gradually became aware that our web pages didn't look the same in Firefox, my favourite browser, as they did in Internet Explorer. In fact some pages looked very odd, with background colours that stopped part way down, or part way across the page. Border colours were black in Firefox, instead of the more pleasing light orange/brown we had chosen as part of our "house colours". There were other differences as well which occurred less frequently, but in parts the site looked distinctly amateurish.

The site was initially developed by our former webmaster using a highly respected commercially available Website design application, and Internet Explorer, but as users of Firefox began to – not complain exactly, but to point out – the strange appearance of the pages in their favourite Browser, I asked myself if we needed to live with these differences, or could they be fixed. When I took over as Webmaster as part of our "Management load sharing" reshuffle in 2008, I decided to investigate.

A detailed look at some of the code uncovered a lot of redundancy, which is often produced by semi-automatic WYSIWYG page editors. It happens when changes are made to an existing page, with the author trying first one way, and then another until satisfied with the result. Unfortunately the WYSIWYG editor isn't always able to amend the original codes, and it ends up inserting additional new codes to override what it had created previously, hence the "mess".

For browsers to do their job and display web pages, the text on the page has to be enclosed in various tags. Most tags come in pairs, one to open a definition and the other to close it. The text between these tags is presented to the user after the tags are interpreted by the browser. They might describe and enclose a header, a paragraph, a list, or a table, for example.

As well as redundant duplication of code, I found that some parts were missing. Sections weren't finished properly before other sections began. In the early days of the html markup language, this didn’t matter, the browser would ignore the absence of these closing tags, but today, as standards have become established, it does matter.

Another thing which had been bothering me was the waste involved in printing those parts of web pages which are only relevant on screen, such as the menu of links to other pages, and the picture below it. I wondered if might be possible to leave them out of the printed copy. Pete Allnutt suggested that it could be done using specific style definitions designed for that purpose. I needed more information, and went to look for it in books and on the web.

Some Research

My research led me to the W3Schools web site which provides free tutorials on all the various languages used to write web site code. Those tutorials are backed up by excellent reference material, including some details of known browser differences. The W3Schools site is developed and maintained by a Norwegian company, Refsnes Data, who state "Our mission is to develop well-organized and easy-to-understand online tutorials based on the W3C Web standards." Following this discovery, I became intent on making our code conform with those international standards as set by the World Wide Web Consortium - W3C. Initially I chose the HTML 4.01 Transitional standard, but very soon decided it would be better to adopt the more recent XHTML 1.0 Transitional standard. XHTML is the same as HTML, but is written within the additional constraints of the XML standard.

I have been surprised to find that none of the web development WYSIWYG editors that were in use by other team members produce code which conforms to the W3C standards. In fact, they seem quite happy to leave out some required closing tags, effectively starting a new section without finishing the previous one, as I mentioned above. This was probably at least in part caused by the members responsible for the various website sections not upgrading their (expensive) web development tools in parallel to the development of the markup languages. I believe that such unfinished code was the cause of some of the observed differences in the way the pages were being displayed by the different browsers.

Also, depending on user actions, the WYSIWYG editors add in many unnecessary tags. In particular, if the user changes his mind about which font to use for a section of text, the editor encloses that text in either "span" or "div" tags, despite the fact that the text may be already enclosed as a cell in a table. If he changes his mind again and reverts to his original choice, the text is enclosed yet again in more tags. I suppose that's the easiest way for the development application to handle the situation, but it leaves quite a mess to be unravelled by the browser.

Conforming to International Standards

Since early in 2008, behind the scenes, and mostly transparently, I've been chipping away at the code used on our club website to increase its compliance with the standards laid down by the W3C. My first move was to convert some of my own pages from the original, very basic, code, into a stricter and more compliant format. I've always preferred working at code level rather than using a "proper" web development application, so at first I used Wordpad to review and edit the code in one of my pages. I removed the redundancies, and added some missing closures. Then I used the excellent free validation service, which is also provided by the W3C, to help me find and fix a lot of errors which I had missed.

Later I discovered and downloaded a couple of free code editors, and now I use PSPad to do the job. The other one was FoxEditor, which was almost as good, and I still use it occasionally. These editors both make it much easier to edit the code/text combination. One of the more useful features of PSPad is that it it highlights matching tags. If you place the cursor in a tag that marks the beginning of a paragraph, both that tag and the matching closing tag are highlighted in blue. If the closing tag is missing, the opening tag is shown red.

By the end of 2008 I had managed to work through most of the 264 pages on the club web site, tidying up and converting them to XHTML. During this process it became blindingly obvious that there was a great deal of duplication across these pages. In particular, the navigation menu was repeated in all the main page files, and most of the header section was the same on every page. If we needed to add to, remove from, or change any of the menu entries, it would mean going through and editing every main page - a monotonous task, very prone to human error. I considered how we might be able to hold a single copy of the menu, such that it could be loaded as required by any web page.

Some New Ideas

At about the same time, Pete Allnutt was investigating a couple of suggestions: keeping a count of the number of times each page was viewed, and making a random selection of pictures to be shown in the header bar and below the menu. Both of these and the use of common sections for our web pages would require some programming. The obvious choice was to use PHP, because it was already in use for the forum, and in some of our existing pages.

Including PHP code meant that in order to get the server to interpret the new instructions, we would have to rename all the web pages to use a new file name extension. The home page, index.htm would become index.php, meaning the default initial web site page must be changed. I left that problem to Pete, while I started work on separating the menu, header and trailer sections of our web pages.

The External Reference List

The majority of links to other pages on our web site used relative addressing. So it was necessary to develop a method to hold a standard value for each link and to modify that link according to the folder level of the page using the link. I chose to do this by building a complete list of all the web site pages, with the page name and a link to that page. Now I could replace every existing link with a reference to this list using the page name as an index to get the link.

Using the reference list had the added benefit of making it very easy to move or rename any page file, and ensure every link to that page still works by simply changing the link details in the list. As long as the page name remains unchanged, all existing links will find the renamed file. That proved to be very useful, because most pages were going to be renamed when they were converted to use PHP.

The Decision To Go

I wanted to be sure that other members of the Management Team could continue to maintain their own pages after the common parts were separated. I provided a couple of examples of modified pages for them to test. Whilst the pages looked a bit strange with the common sections removed, they were able to work with the modified files. So it was OK to go ahead.

Pete and I both finished testing our updates at about the same time. Pete managed to find a way to change the default page name for the site. So I decided to go ahead and roll out the changes across the whole site.

Execution

I hit all the main pages first, before working down to lower levels. It was simply a matter of deleting the common sections and replacing them with PHP code to include the already separated common page sections. A few variables at the start of each file had to be edited to suit each page. These consisted of the page title, and some unique header details. As each page was completed, its filename was changed, and its link in the page list file was updated.

It took some time to work through updating the page files, during which the old HTML files were kept alongside the new PHP files, so that users would see the same page regardless of which file was selected. Once I was sure that all the main pages had been updated, I replaced the HTML versions of each page with a common error page. This shows details of the unmodified link, and gives the user several options to help fix the problem and continue through a link to the new page.

There are still a number of page files which have not yet been updated. These are mainly old event briefing documents, and picture galleries. They will be modified in time to complete the task.

The Benefit

In order to demonstrate how easy it is to modify the navigation menu, two changes have recently been made; a new link was added, and the format of the list was changed. Both of these changes involved a simple edit of the now separate menu list file. All our pages picked up the change without themselves being touched, which saved a huge amount of work.

Another benefit is to the Club’s standing in the community of website owners and developers. The two W3C logos displayed at the bottom of each page are a quality assurance guarantee that the code conforms to the latest XHTML 1.0 Transitional standard. Whilst this is excellent progress, it is not the end of the story. There is much more work to be done in order to comply fully with the higher level of the W3C standard: XHTML 1.0 Strict.

Feature by Tony Driver   dated 19/03/09
With thanks to my editor, Peter Dodds