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