Screen Size
The first technical decision when designing the site was what screen size to support. My initial decision was to create resizeable pages so that they would fit on any browser. However it soon became clear that this would cause legibility and usability problems with browsers on high resolution monitors. Elements of the design would be spaced out too far and it would require a lot of mouse movement to navigate around.

Although most monitors support 800 x 600 resolution, I designed the site for 640 x 480 resolutions as I felt it would be negative to exclude the lower resolutions and people don't always open their browser to full screen (like myself) translating to a smaller screen size. The navigation, main image and introduction to the page fall above the fold. Users can decide whether to scroll to read the rest of the page.

Cascading Style Sheets
I initially designed the site so that it would be supported by version 4 browsers upwards. The main problem encountered when attempting to do this is that the implementation of cascading style sheets(CSS) properties was at best inconsistent, at worst not supported at all, even in the latest versions. The least flawed implementation of CSS was on the Mozilla/Netscape 7 browsers which gave predictable results but even then some attributes are not supported. This was followed by IE 5.x. All of the browsers treated the inheritance of styles very differently hence the need for a lot of duplicate lines to ensure that certain formatting is used.

Some properties that did were badly implemented are :

vertical-align; background-repeat; background:position; border-width; padding;

Netscape 4 had particular problems with the CSS conflicting with attributes defined in HTML. The content is supposed to be centered but certain pages are rendered with the menu and/or content aligned left.

XHTML
XHTML is an XML compliant version of HTML 4 and so it imposes very strict rules about use of tags and their related attributes. In relation to this a lot of attributes have to be placed into style sheets which are not always reliable (see above). For example 'width' cannot be used in the td tags and align attributes are deprecated.

The use of XHTML is also very much browser dependent. I have had problems with the XML tag in IE 5 on some platforms (Mac0S 9.2/Windows NT) thus incorrectly rendering the page. I have since removed the tag on all the pages. This does not invalidate the XHTML.

Cellpadding
Opera 5 on the PC seems to have a issue with the cellpadding of tables forcing the cells out. Maybe this is the actual way the table should be rendered and that other browsers are wrong. It is difficult to tell. All other browsers seem to render the tables correctly.

Forms
A general browser problem is the rendering of forms. Specifying the number of columns in a textarea will result in wide boxes on one browser and narrow ones for another. It really depends on the font chosen. The solution was to use a compromise value.

Lists
Again browser render ordered lists with a lot of variability. I wanted to use them in conjunction with the image map but the rendering of the page anchors caused presentational problems so I reverted to using 'div' tags instead.

Javascript
I developed some dynamic Javascript for creating the pop windows for the images instead of creating a static page for each image which would have been tedious and less maintainable.

Javascript implementation is almost as difficult as making the HTML/CSS work with a range of browsers. The only bonus is that you can write different implementations of the code for different browsers. As with CSS, the Javascript code has the most problems on Netscape 4. There are no problems with the random Lomowalls. The issues arise in the dynamic pop up windows that contain the images and descriptions. Firstly the CSS is ignored completely in the pop up and the 'prev'/'next' links do not work at all due to the included Javascript source files being included as links.

Through having some friends test the site on various platforms that I do not have access, it was found that IE also has problems with the dynamic pop up Javascript. Unlike in Netscape 4 where functions would not work the browser would actually crash. I think this is a bug with the browser. I have isolated the problem to the use of included Javascript source files.

The relative parity in the latest versions of Netscape 6/IE 5.x and Opera 5, mean that the use of basic Javascript functions is quite safe, however in this instance due to particular problems I have had to write browser detection scripts in order to reduce functionality where the script causes problems.

Text Only Version
The text only version uses a minimal set of HTML and strips out all image tags. This version was tested on the Lynx browser on the PC. To really appreciate the Lomographic camera qualities you do really need to be able to view the Lomographs. I have replicated the textual content from the graphics version and placed indicators directing the users to view the graphics version as required e.g. Lomowalls page. With much of the formatting and Javascript stripped out, the site is extremely fast. Surprisingly the graphics version is also quite viewable in Lynx as 'alt' tags have been used with all images.

Platform Issues
The colours on a Mac monitor appear brighter than the PC even on a variety of monitors. I have used web safe hex colours for any colour block area e.g. orange and crimson in order to reduce any unpredictable rendering. There is of course no guarantee what the main images will look like on monitors with reduced colour.

Mac and PC browsers of the same major version also renders things differently. Internet Explorer editions vary greatly depending on the build version, this is especially true in terms of their CSS and XHTML support.