http://ofbiz.116.s1.nabble.com/RFC-HTML-CSS-Best-Practices-tp177026p177037.html
As David mentioned, there are actually two sets of guidelines needed for OFBiz -
specific. The EM guideline would be acceptable for the back office apps, but
> Hey Jacques,
>
> Thanks for that excerpt. In reading that did you find any discussion
> on the
> BODY{
> font-size:62.5%;
> }
> trick?
>
> This dampens much of the default font size extremes (though doesn't
> completely eliminate it). This sets the default size of the page to
> the following depending on the user's settings:
>
> Default|Result
> 16px | 10px
> 14px | 8.75px
> 12px | 7.5px
> 10px | 6.25px
>
> Notice it's only decreasing font-size by 1.25 px per 2 px step.
>
> --- Jacques Le Roux <
[hidden email]> wrote:
>
>
>>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" <
[hidden email]>
>>To: <
[hidden email]>
>>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 ---
>>
> === message truncated ===
>
>