No taxation without representation

[ Developers] [ Using CVS] [ Reporting Bugs ] [ Using SF ] [ Coding Guides] [ Documentation ] [ NewsLetter ]

Project Web-sites

Project 1040 has one major website and two sister sites. The main website (which your probably at right now), has the URL: < http://tenforty.sf.net/ > The current sister sites are : LinuxTax.com and Jay Scherrer.com. < http://www.linuxtax.com > and < http://jayscherrer.com > . Development for the first 2 sites is handled by this team. Jay's page is of course his own.

Both the main sites servers support cgi Perl and php. PHP and XHTML are the main scripting languages used, their use does not exclude others.

Hopefully the structure of this site is sensible, there is an attempt to separate content into two main streams. A users stream and a developers stream. There is some cross over and no attempt to exclude either user from the other. This is deliberate. The rationale is to attempt to keep the site quick and simple for end users with task specific information ready to hand while enabling more detailed (and more complicated) information to be made easily available for developer level users.

The main visual indicator of this is the type of menu presented on each page. The developers pages use a standard header style menu with area specific links presented as required. The user stream uses a right hand side bar and a narrower effective page width (80%)(this is set by the paragraph tag). One of the reasons for this is a desire to keep the user information short and simple and layed out cleanly. The developers pages need not have that restriction though I do attempt to be succinct though not terse.

Advantage is taken of Cascading Style Sheets and PHP includes. At this point there has been no need to use more advanced techniques and I have to some degree deliberately avoided them in an attempt at portability and simplicity.

Browser Compatibility

This site is tested using level 5 browsers only. However I do attempt and occasionally check using Lynx and Amaya to make sure that it stays navigable at least on these non CSS browsers. Netscape 4 is the only widely used browser that will have major problems with fonts or nesting.. even so I believe it should work at at least 90% on NS4. I do not use KDE or it's default browsers but trust other project members to report problems.

The following will become apparent from a short study of the code: divisions and absolute positioning are used widely, page layout is done were possible using percentages, font sizes ditto, the em is used for layout issues such as padding and indentation. (occasionally other issues). In short I attempt to get around IE5/ns4 issues with font sizes and positioning by not using pixels and never point sizes. Most fonts selected are MS compatible or at least fall back to standard well used fonts. Colours are a little more free form as I simply forget to "web-safe" them. Still anybody running at least 16 bit displays should be fine.

The Rules then

There aren't any. There is an approach though and it goes like this:

Keep Developers information under the developers site

Use ems and percentages in preference to other sizing units

Try to use the existing style sheets by all means extend them but firstly consider starting an area specific sheet if that is appropriate. You can include any number of sheets; remember last definition takes precedence.

Use predefined classes where possible. By all means "override" a class attribute at the page level. (I have often done that)

NO FRAMES

Use tables and forms for the things they were designed for: Tables and forms :) OK tables for layout too if you really need to .. At least nest it in a div so that we can treat it site wide and remember classes work in tables too. (well mostly)

Try to stick with the fixed menu approach, it leaves you free to lay in content without worrying too much about layout.

Try to avoid the gif format. Make sure you index any png's and gifs you use. Some browsers don't handle "semi transparent" transparency very well so watch that. Until the SVG and mng formats are more widely supported we are stuck with gifs or hairy scripting for animation. I leave the decision up to you. The scripting can be server side but do remember we are guests here. (and who need that headache in any case --- use gifs or javascript (client side)) personally I feel the graphics content is about right when looked at per page. This should NEVER exclude using a graphic where it informs. (e.g. screen-shots, flowcharts etc.) If you need to do lots you might think about thumbnails and links.

SVG can and should be used, I am happy to investigate this if needed.

The future

I guess one day when I get the time I will investigate using server parsed XML for this site.(Not client side as it's going through it's own little "browser war" (ah ya gotta luv dem capitalists) and most browsers don't support it yet) If for no other reason than the fact that we could then natively show program output. I have only done enough homework to know that this is possible right now with what we have in place. I will make sure the XML sub project takes this into account.

Finally I would like to apologise for taking so long to say so little. I figured it's better to get something "out there" and happening and come back and tidy up later. The next step is to use the following space to write a "how-to contribute to the web-sites". I'll probably tidy this then.

Pete. September 2002