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 ---
