David,
Thank you very much for your comments! You brought up some very good points.
They are helpful.
I've been using the Party Manager application as a testbed for the new layout
methods and it all works very well with Firefox and IE 7. IE 6 has a lot of
problems with DIV based layout, and Mozilla displays well but looks slightly
different. I started researching how to fix the IE 6 layout issues and got
overwhelmed.
Bottom line is, if the development community is okay with requiring users to use
Firefox or IE 7 for the back office apps, then that takes a load off my mind and
it will make the UI refactoring move a lot faster.
Re: eCommerce - I agree that it requires a unique set of guidelines because it
is public facing. I've never used eCommerce, so I'll have to rely upon the
community's suggestions on guidelines for that.
Another unique set of guidelines that comes to mind is designing the UI for
handheld devices. I guess we'll cross that bridge when we get to it.
David E. Jones wrote:
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.
