Login  Register

Re: RFC: HTML/CSS Best Practices

Posted by Jacques Le Roux on Jan 23, 2007; 4:56pm
URL: http://ofbiz.116.s1.nabble.com/RFC-HTML-CSS-Best-Practices-tp177026p177029.html

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" <[hidden email]>
To: <[hidden email]>
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.
> >>
> >