My first thought is that 2 parts of this seem to contradict each other, namely the first section (Web Standards and Browser Compatibility) and the last section (HTML/CSS Testing Guidelines).

The de-facto standard so far (not perfectly applied, BTW) has been split into 2 parts:

1. the internal applications (all of the managers): work well in standards compliant browsers (test with something like Firefox at least), don't worry too much about IE

2. the public/customer facing application (really just ecommerce right now): things here should be initially developed to be standards compliant and work in standards compliant browsers; however for these we can't stop there as the fact is much of the consuming public uses IE and it is necessary to create sites that work well in IE; this doesn't have to break the standards compliant stuff, but sometimes requires browser-specific variations in order to work well in the needed browsers

-David


On Jan 22, 2007, at 12:51 PM, Adrian Crum wrote:

The proposed HTML/CSS coding guidelines/best practices. My comments are in brackets [] - they are not intended to be a part of the final version.

These guidelines are short and to the point. I could go into more detail, but then that would be bordering on writing a book about web design. Instead, I took the approach that the reader has already read books on HTML and CSS, and they just need some basic guidelines.

Your comments and suggestions are welcome. Once everyone has commented, I will post the final version on the Wiki.

---------------------------------
OFBiz HTML and CSS Best Practices
---------------------------------

--- Web Standards and Browser Compatibility ---

OFBiz HTML and CSS code should strive to conform to the latest W3C standards. Browser-specific extensions should be avoided.

If a particular browser does not conform to the latest standards, then the HTML/CSS code should strive to produce a usable web page with that browser. In other words, OFBiz developers should not "dumb down" the user interface to support a non-conforming browser, yet someone using a non-conforming browser should still be able to use OFBiz.

[As Andy Clarke said, "For such a young and dynamic medium as the web, the notion that designers should not push design boundaries forward because of only one browser, even when that browser is the market leader, seems incompatible with progress."]

--- HTML Guidelines ---

HTML should be well structured, concise, and free of styling information. Well structured HTML is easily styled with style sheets (CSS) - therefore all styling code should be kept in the style sheets.

[Brief "good" versus "bad" code example goes here.]

HTML tables should be used for rendering tabular data only - they should not be used for general layout.

All HTML should pass validation.

--- CSS Guidelines ---

Style sheets should be concise and organized.

Class IDs are preferred over class names.

Build from the bottom up. Assign common properties to basic HTML elements first, then embellish the elements with additional selectors (CSS inheritance).

Give the class names/selectors meaningful names that describe what they are styling. Class names should be easily understood by non- technical people - such as graphics artists. Class names should not imply positioning or styling. Examples of improper class names: "topRightButton" "leftMenuBar" "boldRedText" - those all imply position/style.

Recurring HTML element collections (navigation bars, button bars, screenlets) should be styled as a whole - using contextual or descendant selectors.

Be consistent with property values. Use EMs for sizing - which allows the page to be resized gracefully. Use the hex notation for colors - which allows a graphic artist to search/replace colors.

[Brief "good" versus "bad" code example goes here.]

--- HTML/CSS Testing Guidelines ---

Don't make assumptions in your code. Don't assume everyone reads left-to-right. Don't assume everyone can distinguish between subtle shades of gray. Don't assume everyone uses their browser's default settings. Test your code on several browsers, then change the browser's settings. Reverse the layout direction (CSS direction: rtl;). Change the language. Resize the browser window - make it really tiny. The page should make sense under any circumstance.

After you're satisfied that your HTML/CSS code will display correctly under any circumstance, run the page through a validator to catch any errors.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to