 |
First, the disclaimer. As with other CodingStandards, what is on this page is subject to change based on what browsers people are actually testing with, discussion among developers, etc. So feel free to ask on the ListServ if you are working on some code and have questions. Also note that the current mifos code obeys some of these rules more than others. So to the extent that it doesn't, it can be considered a to-do task.
Write javascript to the W3C? DOM; it is neither necessary or desirable to cater to older javascript DOMs (roughly, W3C? DOM means IE5, Mozilla, or newer, but not Netscape 4, IE4 or older).
Don't use javascript when there is a perfectly good way of doing something in HTML or CSS. Usually this kind of javascript gets subtle details wrong (for example, whether the user can see the destination of a link by hovering over it). Input should not be validated until form submission.
Assume a relatively capable CSS implementation (again, corresponding to IE5 or Mozilla). I think this means CSS1 and parts of CSS2, roughly.
Don't layout with non-breaking-spaces all over the place, transparent gifs, or tons of tables. Those are obsolete practices given the CSS criterion above.
However, don't be afraid to use some tables for layout. There are things that CSS does not yet do well (for example, dividing the horizontal space between a sidebar and a main pane, keeping in mind that the window might be resized by the user).
All HTML should be well-formed XML. If you render via XmlBuilder, this is basically provided for you. (Quick summary of what "well-formed" means: start tags like <p> are always balanced by end tags like </p>; single tags like <br /> have the trailing slash - see XML spec for details).
Making our pages valid XHTML 1.0 is a good idea too, but might be farther down the road.
It is desirable to work with textual browsers such as lynx/links/w3m, cell phone browsers, browsers without javascript enabled, etc.
(However, whether this happens depends largely on whether people test with those devices and send in patches. Don't get too worried about what might happen on some browser you don't have access to. On the flip side, don't go through contortions to make things Just Right on one particular browser. Hackery will probably just break in a future release of that browser, anyway. Instead, focus on straightforward HTML).
See also
|