CSS IN THE TRENCHES, Part Two
Advanced Features & Incompatibilities
REVIEW
Style Sheets (CSS) are an important Web standard, allowing designers
to specify the font family, size, margins, and leading of type on the
Web; permitting designers to create advanced Web layouts without
abusing HTML; and enabling Web designers, HTML practitioners, and
programmers to separate design elements (presentation) from
content.
The ability to separate presentation from content empowers Web
designers to create attractive sites without excluding visitors who
cannot use graphical browsers, and paves the way for the future
expansion of the Web beyond the desktop computer and onto a variety
of hand-held and other Web devices.
Fortunately, CSS is easy to learn and use.
Unfortunately, full support for CSS has been a long time coming. Even
though the CSS Level 1 standard was finalized in 1996, the first
browser to fully support it did not appear until the year 2000 (Internet
Explorer 5, Macintosh Edition). Netscape Navigator 6, unreleased as of
this writing, will also fully support CSS Level 1. And Opera Software's
Opera browser will support most of it. Sadly, these browsers are used
by a minority. Internet Explorer 5 for Windows, used by the majority,
does not fully support Style Sheets, and may not do so before the
release of IE6 (if then). And Netscape Navigator 4, still used by tens of
millions, does such a poor job of handling Style Sheets that it has been
known to crash upon encountering them.
Article:
http://www.alistapart.com/stories/died/
"The Day the Browser Died"
Faced with these inconsistencies, many Web designers have avoided
using CSS altogether. This is not necessary or recommended,
however. Below, we will discuss methods of using CSS safely and
highlight problem areas to avoid.
CSS PROBLEM AREAS
Web Review publishes useful information on CSS problem areas and
"safe" uses of CSS. Take some time to look over the following:
http://webreview.com/wr/pub/guides/style/style.html
Web Review Compatibility Charts.
Of special note:
http://webreview.com/wr/pub/guides/style/mastergrid.html
The Master List
"The mother of all CSS (Cascading Style Sheet) charts," listing every aspect
of the CSS spec and identifying how well it is supported by Netscape 4.x and
Internet Explorer 3.x, 4.x, and 5.x for both Macintosh and Windows 95, and
Opera 3.6 for Windows
http://webreview.com/wr/pub/guides/style/safegrid.html
Safe CSS Properties
These charts show which CSS properties are supported in various browsers.
Web designers may draw their own conclusions about which properties to
use, and which to avoid, based on the browsers used to visit their clients'
sites, or on industry reports which attempt to show which browsers are used,
and by how many people.
These charts portray a fragmented browser space, where it appears
that few CSS properties may be safely used. And it is fair to say that
the full power of Cascading Style Sheets will elude Web designers until
Internet Explorer, Netscape Navigator, and Opera completely support
all CSS properties on all computing platforms. Even then, Web
designers will have to wait until the majority of Web users have had
sufficient time to upgrade to these standards-compliant browsers, a
process that usually takes up to 18 months.
In the meantime, however, Web designers can begin using CSS
conservatively, by following the "No-Fault CSS" Plan outlined in A List
Apart. We will summarize the plan below, and then provide links for
further reading.
NO-FAULT CSS
The "No-Fault CSS" Plan advises Web designers to use those parts of
the standard which are supported in most browsers. This generally
means using CSS (instead of FONT FACE and FONT SIZE tags) to
specify Web typography in terms of font family, size, and leading, and
avoiding the use of CSS as a full-fledged layout tool until it is properly
supported in all browsers. Even that plan can snag on some "gotchas,"
but we will point those out as well.
CSS AND LAYOUT
One of the great strengths of CSS is its ability to position elements on
a Web page. Elements may be positioned by exact pixel coordinates
(400 pixels from the top, 32 pixels from the left, for example). They
may be positioned relatively to each other. They may be positioned via
percentages, permitting Web designers to easily set up "liquid"
layouts, as previously discussed.
Unfortunately, CSS positioning is not supported in IE3, and is buggily
supported in Netscape Navigator 4 (ie., it can cause the browser to
crash). Therefore, Web designers are advised to continue using HTML
tables for layout purposes, and to avoid CSS layouts until we have
better browsers. Web pages laid out with HTML tables will work in
Netscape 1, 2, 3, 4, and 6; in IE 2, 3, 4, and 5; and in all other
graphical browsers.
This means that Web designers cannot yet separate form from
content, and that they will continue to face difficulties in creating Web
sites that work well outside the traditional desktop computer-based
browser. But in the trenches, where work gets done, it also means
that they can create sites that work for their clients and their clients'
audiences.
CSS AND TYPOGRAPHY
By using CSS instead of FONT FACE and FONT SIZE tags, Web
designers may specify the design of typography on Web pages,
including recommended font families, sizes, colors, background colors,
and leading (line-height). This practice will not only provide access to
functions which FONT FACE and FONT SIZE tags cannot offer (leading,
background colors). It will also:
1.
Conserve bandwidth by replacing hundreds or even
thousands of FONT FACE and FONT SIZE tags with a single
line of code that resides on a separate Style Sheet.
2.
Reduce the time necessary to implement a site, since the
Web designer or the HTML practitioner need not type
unnecessary tags for every headline and paragraph.
3.
Make it easier for the Web designer to update the site's
look and feel. Doing so is as easy as replacing a single line
of code on a separate Style Sheet document, instead of
hunting through every page of the Web site in search of
FONT FACE and FONT SIZE tags.
4.
Bring the site closer into line with current World Wide Web
Consortium (W3C) recommendations.
5.
Make it easier to further streamline and update the code
when additional Web standards are supported, and the
client is ready to begin employing powerful standards such
as XML and the Document Object Model.
There are, however, a few problems to watch out for, even when
following this relatively conservative approach to using CSS.
FONT SIZE CHALLENGES
CSS allows Web designers to specify the size of typography on Web
pages. As shown below, font sizes may be indicated using any of the
following: points, pixels, absolute keywords, relative keywords, length
units, and percentage units.
H1 {font-size: 14pt}
H1 {font-size: 14px}
H1 {font-size: x-large}
H1 {font-size: larger}
H1 {font-size: 1.5 em}
H1 {font-size: 125%}
Points. This is the terminology with which designers are most familiar,
from their years of creating print layouts in Quark Xpress and similar
programs. Unfortunately, points are meaningless on the Web. Due to
platform and resolution differences, 14pt could be large or small. Not
recommended.
Pixels. Though screen resolutions vary, a pixel is always equal to a
pixel. Pixels are the only reliable means of sizing typography if the
designer absolutely must control the size of type on the Web page.
Unfortunately, this practice may cause problems for some readers. For
instance, if the designer has specified ten pixel type:
1.
The visually impaired may have difficulty reading the type.
This is not a problem in IE5/Mac, which allows users to
resize type at their discretion. Most other browsers,
however, do not allow the user to resize CSS type specified
in pixels. Thus, there is a serious usability issue involved in
this practice.
2.
On some computing platforms, notably Linux, if the user
does not have the font specified, at the exact size
specified, the type will display jaggedly, and be
unreadable. The only safe sizes for Linux users appear to
be 11px, 12px, and 14px. This is extremely limiting for
Web designers.
Absolute size keywords. There are seven absolute size keywords in
CSS.
xx-small
x-small
small
medium
large
x-large
xx-large
If implemented correctly and uniformly, they would allow designers to
specify approximate sizes without running into either of the usability
problems associated with pixels (above). For that reason, the W3C
recommends their use. Unfortunately, absolute size keywords are
unusable in current browsers, since only IE5/Mac renders them
correctly. Netscape 4 ignores them. Netscape 4.5 and IE3 render them
at illegible sizes. (For instance, Netscape 4.5 and IE3 render xx-small
at 6 pixels, which is 3 pixels below the threshold of readability). IE
renders them correctly in IE5/Mac, and incorrectly in IE5/Windows,
where they are all too large. (In IE5/Windows, small is displayed as
medium, medium is displayed as large, and so on.) Sadly, then, Web
designers cannot follow W3C recommendations and use absolute size
keywords until the browsers shape up.
Relative keywords are limited to two: smaller and larger. These in
turn refer to the size of the parent element. For example, consider the
example below, in which the BODY is 12px, and BOLD is "larger."
<HTML>
<STYLE TYPE="text/css">
<!-BODY {font: 12px verdana, arial, geneva;}
B {font-weight: bold; font-size: larger;}
-->
</STYLE>
Bold type would be 14 px tall in this example, because 14px is one
"notch" up from 12px. Like absolute size keywords, relative keywords
are ignored or bungled in some popular browsers (Explorer 3 ignores
them, as does Navigator 4 for the Mac.) And even if they worked
correctly, they would be insufficient for the needs of most Web
designers and their clients.
Length units include the following:
1.
em (a unit of distance equal to the point size of a font. In
14-point type, an em is 14pts wide.)
2.
ex (X-height refers to the height of lowercase letters.)
When used with the font-size property, em and ex units refer to the
font size of the parent element.
<HTML>
<STYLE TYPE="text/css">
<!-BODY {font: 12px verdana, arial, geneva;}
B {font-weight: bold; font-size: 2em;}
-->
</STYLE>
In the example above, BOLD would be 24px tall, or 2em (two times
the font size of the parent element, which is the BODY tag). In theory,
a Web designer could create a design, using em or ex units, where all
elements were sized relative to each other. This would avoid the
usability problems associated with pixels. Unfortunately, the browsers
make this impossible for the time being. Netscape 4 ignores em and ex
units. IE3 treats em units as pixels. Thus, 2em is mis-translated as 2
pixels tall (!). Not recommended.
Percentage units, like length units and relative keywords, refer to the
size of the parent element.
<HTML>
<STYLE TYPE="text/css">
<!-BODY {font: 12px verdana, arial, geneva;}
B {font-weight: bold; font-size: 200%;}
-->
</STYLE>
In the example above, BOLD would be 24px tall, or 200% of the font
size of the parent element, which is the BODY tag. In theory, a Web
designer could create a design, using percentages, and avoid the
usability problems associated with pixels. Uh-uh. Netscape 4 for Mac
ignores percentage values entirely. Netscape 4 for Windows treats
percentages as pixels. (Thus, 200% is stupidly translated as 200
pixels.) And IE3 drops the ball by sizing percentages relative to the
user's default font size, rather than to the parent element. Sadly, not
recommended.
CONCLUSION: In the trenches, where work gets done, Web
designers will continue to be limited to using pixels in their style
sheets - with all the usability issues associated with that practice until standards-compliant browsers exist and are widely used.
LEADING AND IMAGE OVERLAP
Leading - the ability to specify an exact or relative amount of vertical
white space between lines of text - is one of the greatest attractions of
CSS. Prior to style sheets, Web designers had to manually insert
invisible spacer pixel gifs between lines of HTML text in order to
simulate leading; or they had to set type in Illustrator or Photoshop,
and export it as a gif image rather than actual HTML text. Both
practices yoked content to presentation, wasted bandwidth, and
presented usability problems. Displays based on invisible spacer pixel
gifs could break in some browsers. Text gifs were useless to the
visually impaired and other users of text-based browsers, and
prevented search engines from indexing important site content.
The CSS line-height property solves all those problems, but it can lead
to new problems, particularly in older browsers whose support for CSS
is largely theoretical. For instance, in the example below, if CSS lineheight is specified for the <P> tag, the image will float on top of the
text in both IE3 and early versions of Navigator 4:
<p><img src="dog.gif" width="100" height="100" alt="My dog, Pookie."
Title="Pookie is a friendly mutt." align="left">My dog Pookie liked this text
so much, he decided to sit on it in IE3 and Navigator 4.</p>
The solution to image overlap is to keep images outside of paragraphs
and <div> tags. Unfortunately, doing so brings up yet another
problem in Netscape Navigator 4:
<img src="dog.gif" width="100" height="100" alt="My dog, Pookie."
Title="Pookie is a friendly mutt." align="left">
<p>My dog Pookie liked this text so much, he decided to shove it to the right
in its own little column in Navigator 4.</p>
With a left-aligned image placed outside the <p></p>, later versions
of Netscape Navigator 4 will stick all the paragraph text in an
imaginary column to the right of the image, as if the Web designer had
desired to create such a column. New paragraphs, in turn, will also
appear in that unwanted column. Many a simple layout has been
ruined in this way.
There is no solution to this problem. No matter which approach is
used, some Netscape 4 users are going to get an ugly layout. Since an
unwanted and mindlessly stupid column is preferable to text that is
hidden behind an image, it is best to hope and pray that most
Netscape 4.x users are equipped with a more recent version of the
browser. Alternately, the Web designer can create pages that use no
images whatsoever - always an attractive option. Finally, the designer
can wrap images inside table cells, since that seems to solve most of
these problems - at the terrible cost of adding needless, bandwidthwasting and time-consuming code to every single Web page.
The good news is that Netscape Navigator 6, soon to be released, will
be free of all such problems. And when it is released, at least 22
million AOL users will be migrated to the new browser by their
provider.
Margins
As mentioned earlier, margins work well in all CSS-capable browsers,
except that certain margin combinations can cause Netscape Navigator
4 to crash. More recent versions of Navigator 4 have fixed some, not
all, of these crashing bugs.
Font-Style
Using CSS, it is easy to specify font styles such as italic.
.snappy {font-style: italic;}
H2 {font: 12px italic arial, helvetica, sans-serif;}
ADDRESS {font-style: italic;}
Unfortunately, many browsers style certain elements by default. For
instance, in Explorer, ADDRESS is italic by default. Therefore,
specifying italic in the Style Sheet causes the text to be doubly
italicized. Leaving out "italic" causes the ADDRESS to be non-italicized
in Navigator. The Web designer must decide which is a more
disagreeable problem.
Possible font-styles are: normal (no style), italic, and oblique (same as
italic, but not recognized in some browsers, with some fonts; have a
nice day).
Font-Weight
Using CSS, it is easy to specify font weights such as bold. Sometimes,
this is necessary. For instance, Netscape may not style <B>BOLD</B>
text as bold unless the designer indicates the obvious in his or her
Style Sheet.
.fatboy {font-style: bold;}
H2 {font: bold italic arial, helvetica, sans-serif;}
On the other hand, many versions of Explorer and Netscape will style
certain elements bold by default. As a result, if the style sheet also
indicates bold, the result may be twice-bolded typography.
H2 {font-style: bold;}
In Netscape, this headline will be twice-bolded. The look can be
interesting on a platform, such as Mac OS, that handles typography
well, and includes built-in text anti-aliasing. In Linux, the effect is ugly,
and the text may be illegible, or at least tough to read. Have a nice
day.
Summary and Further Reading
Pointing out these problems is not meant to discourage Web designers
from harnessing the power of CSS, any more than a tour guide who
warns you of potholes on the scenic road means to discourage you
from exploring his city. Designers need to know what works and what
doesn't in order to effectively use the good stuff.
The "Fear of Style Sheets" series at A List Apart discusses CSS
problems and solutions in greater detail, and should be read by
anyone who makes Web sites:
http://www.alistapart.com/stories/fear/
FEAR OF STYLE SHEETS
http://www.alistapart.com/stories/fear2/
FEAR OF STYLE SHEETS 2
http://www.alistapart.com/stories/fear3/
FEAR OF STYLE SHEETS 3