Adrian, IMO it may be possible to use only Firefox or even IE 7 for backend (and recommend them).
Just a question I'm asking myself : could that have any implications in the future ? Jacques ----- Original Message ----- From: "Adrian Crum" <[EMAIL PROTECTED]> To: <dev@ofbiz.apache.org> Sent: Tuesday, January 23, 2007 4:57 PM Subject: Re: RFC: HTML/CSS Best Practices > 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. > >> > >
