Adrian, all, I do not agree on em being best practise let me explain why with this extract from chapter 13 of Jeffrey Zeldman's "Designing With Web Standards" (as I said before it's a little verbose):
============================================================================== The Heartbreak of Ems Accessibility advocates and the creators of CSS have long agreed that ems are the way to go. Sadly, they are often the way to go to hell. Listen to all the lectures, read all the books and articles, and you will come away feeling dirty and ashamed if you use anything other than ems to specify your type sizes. But the beautiful theory of ems breaks down in coarse practice and not only in browsers that fail to support the common default font size. On a minor note, there is the problem of old browsers. Netscape 4 ignores em and ex units that are applied to text, although it bizarrely respects these units when they are used for line height. IE3 treats em units as pixels. Thus, 2em is mistranslated as 2 pixels tall. Almost no one uses IE3 any more, but still. Likewise, older browsers often bungle inheritance on nested elements sized with em units. Because fewer and fewer people are stuck with Netscape 4, we won't waste your time going into the details of that browser's mishandling of relatively sized nested elements. Just know that if you need to support outdated browsers and if you use em units (especially on nested elements), you are letting yourself and your users in for a world of pain [13.11]. 13.11. What's in an em? Not cross-platform, cross-browser size consistency, that's for sure (http://www.thenoodleincident.com/tutorials/box_lesson/font/). User Choices and Em Units A more common problem with em units is that users often downsize their default font size settings as noted several times in this chapter. Mac users switch back to 12px/72ppi; Windows folks set their browsers' View: Text Size menu to "small" rather than "medium." Such changes make any text sized below 1em smaller than it is supposed to be and might make it too small to be read. In 2002, CSS/DHTML expert Owen Briggs tested every available text sizing method across a vast range of browsers and platforms to find out what worked and what failed. 264 screen shots later, despite hoping to prove that ems were always viable, he had actually discovered the opposite [13.11]. Ems work well as long as you never spec your text below the user's default size. Ems work well as long as users never adjust their preferences. But most designers and many clients favor smaller type and many designs require them. Many users consider the 16px default size uncomfortable for normal reading and change their preference settings accordingly. When em units are used to design sites, the designer's and user's shrinkage efforts compound on one another, resulting in text that might be hard to read or even entirely illegible. When you set small type with em units (or percentages), you run afoul of a universe of unknowable, uncontrollable user preference settings. What looks elegant on your monitor might be mouse type on your users'. If you commit this act in the name of accessibility, you're kidding yourself. In the i3Forum site, we tried to minimize the potential damage by sticking to sizes that were only slightly smaller than 1em. But the user's mileage might vary. Alternatively (http://www.alistapart.com/stories/dao/), client and aesthetics permitting, you can design all your sites using only normal or oversized type set with em units. This will avoid size-based accessibility problems. But very few designs work with a default size of 16px and higherand some users will complain that your site is ugly because the text is "too big." If the moral seems to be that you can't please everybody, the additional moral is that you are even less likely to please everybody when you use em units to specify your text size. Some standards evangelists and some accessibility advocates will choose to disbelieve what we've said, just as some people choose to believe that the 1969 moon landing was a hoax. Was it T.S. Eliot or Woody Allen who said, "Too much reality is not what the people want."? Whoever said it first, he was right. So what do the people want? They might want the two methods described in the remainder of this chapter, which seem to work better than any we have considered so far, although even the methods we are about to discuss have their problems. ============================================================================== The 2 methods he advocates are "Pixels Prove Pixels Work" and "The Font Size Keyword Method" (Fahrner's Method). If you are interested by those I may put a link on my site for this stuffes (perhaps I should have better do that for extract above also) Jacques ----- Original Message ----- From: "Adrian Crum" <[EMAIL PROTECTED]> To: <dev@ofbiz.apache.org> Sent: Monday, January 22, 2007 8:51 PM Subject: RFC: HTML/CSS Best Practices > 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.
