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 <[EMAIL PROTECTED]> 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" <[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 ---
>
=== message truncated ===
