RFC: HTML/CSS Best Practices
Posted by Adrian Crum on Jan 22, 2007; 7:51pm
URL: http://ofbiz.116.s1.nabble.com/RFC-HTML-CSS-Best-Practices-tp177026.html
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.