HTML would present content and structure, and the browser (or User Agent) would interpret it visually, according
to its own built-in rules
of display. <h1>Headlines</h1> would look like whatever the browser
decided they should look like (typically, 24pt. Times). <p>Paragraphs</p>
would look like whatever the browser decided they should look like
(typically, 12pt. Times).
In early browsers such as
Mosaic and Netscape 1.0, web page backgrounds were generally gray. Why
did browser developers choose this dingy color? The answers are lost in the
mists of time. In other words, we have no idea.
But we do have a theory.
Namely, images seemed to want to appear against a black background for
maximum contrast and impact. Text, of course, wanted to appear on white.
We’re guessing that the makers of the first browsers compromised by
giving us a washed-out gray that would provide rudimentary contrast for
either type of foreground element. Regardless of
their reasons, the
resulting web pages were not much to look at.
TAG
SOUP
AND CRACKERS
Designers and their
clients, however, were not about to sit still for such limited presentational
capabilities, so browser companies (mainly Netscape at first) began “extending”
HTML willy-nilly to offer web designers more control over the visual appearance
of their sites. Netscape extended the <BODY> tag, allowing
us to choose background colors as well as text and link colors. Microsoft gave
us proprietary <BODY> tag extensions that allowed us to create margins
of a limited sort.
Netscape gave us the
<FONT> tag. We could control the size of our text, regardless of its
structural context. (We could, for instance, make paragraphs really big <FONT
SIZE=”7”> and headlines really small <FONTSIZE=”1”> even if such
approaches contradicted the underlying document structure.) Microsoft gave
us the <FACE> attribute for the <FONT> tag. We could control typography in
a limited, Flintstonian fashion. <FONTFACE=”ARIAL, HELVETICA”>
would make text on the page appear in Arial if the visitor’s operating
system offered that font. If not, the text would appear as Helvetica.
If
neither font were available, visitors would see their default typeface (probably
Times). While browser companies
corrupted HTML in a well-meaning but wrongheaded effort to serve designers
and their clients, designers began setting
their text in Photoshop and
saving the images in web-friendly GIF format.
14pt. Meta or Futura, with
precise kerning and leading, looked a lot better than <FONT FACE=”ARIAL,
HELVETICA”>. Instead of using HTML to present text, designers used it to
embed visual representations of text.
What we gained in
presentational spiffiness, we lost in usability. GIF images of text could not be
searched, indexed, copied, or pasted. They could not even be seen by some people
or in some browsers. At the same time, designers
began using HTML tables to control their layouts, a practice most of us still
follow, though it runs counter to the structural nature of HTML. The
practice has another downside as well: It yokes our presentation to our
content, making it harder or even impossible for those with disabilities or
those using nontraditional browsers to access the information on our sites.
Many of us went beyond
using tables and text images. We harnessed invisible powers to our task. As you
know, in Photoshop any layer may be fully or partially transparent.
Images in the GIF format are limited to 256 (or fewer) colors, any one of
which may be designated as transparent. Using Photoshop, web designers
created small (1 pixel by 1 pixel) GIFs filled with a single, transparent
color. We then used these transparent GIF images to control the positioning of
elements on the page, as if we were designing for a fixed medium like
print. We used these transparent
GIF images again to simulate leading, inserting “spacer GIFs” between lines
of HTML text.
<IMG WIDTH=”100”
HEIGHT=”100” ALT=” “ SRC=”transparent.gif”> Notice the height and
width. Netscape’s browser likes it when you indicate the size of images used.
This helps the browser leave space for the images, even before they have
finished downloading. A tangential aspect of the whole affair is that
browsers will display your images at any size you tell
them to. Thus a 1 pixel by
1 pixel transparent.gif could be 100 pixels wide by 100 pixels tall if you
marked it up that way in your HTML. These crude feats provided rudimentary
layout control, while HTML itself did not.
That was the key. HTML,
practically the only tool at our disposal, provided no typographic or layout
control. So most of us deliberately deformed the simple markup language in
hopes of forcing it do our bidding. We made a “tag soup” of the Web,
using <TT> (“typewriter text”) to force the browser to display a monospaced
font (usually Courier). To create vertical space, we deployed transparent GIFS
or typed structurally meaningless carriage returns such as:
<br><br><br> or went so far as to create
“invisible headlines” which were never intended to be read. To create
invisible headlines we used the nonstandard <FONT-COLOR> attribute to set
a headline to the same color as the web page’s
background.
By means of these stunts,
the Web began to look better on the surface, but the markup that was
supposed to hold it together was becoming less and less meaningful, more and
more fragmented. Documents made less and less structural sense and were
more and more tied to the quirks of specific browsers. “Use Netscape so
you can see this page!” we screamed at our viewers in the mid-1990s.
CSS
TO
THE RESCUE…SORT
OF
In 1996, Microsoft,
Netscape, and other members of the World Wide Web Consortium (W3C) came up
with a brilliant new standard technology—one intended to give designers
far more power over the display of web pages, without further corrupting
the structural meaning of their HTML documents.
The name of that technology
was Cascading Style Sheets (CSS). CSS is the best friend a
visually oriented web designer ever had, but supportfor this crucial standard
has been a long time coming. In the following section, we’ll gently
introduce you to CSS, showing how and why it works. Afterward, we’ll
talk about what can go wrong with CSS and present
a detailed No Fault CSS
Plan that enables you to harness the power of style sheets without
running afoul of buggy browsers.
The good news about all of this is that most
current web browsers now offer good-to-excellent CSS support. The bad news
is that older, inferior browsers are still in use, though they are fading away
over time (see the section, “The 18-Month
Pregnancy” in Chapter 2,
“Designing for the Medium,” for comments on this topic).
As a last prefatory note,
you might find yourself working at a large web agency—one where web
designers spend most of their time in Photoshop and Illustrator, while HTML
production chores are handled by a separate group of professionals.
Even at job like that, you will still need to know CSS.
Why? It’s because even when
HTML chores are assigned to web technicians, it is almost always the web
designer’s job to create the style sheet. 256 HOW:
Style Sheets for Designers: CSS to the Rescue…Sort of That may seem puzzling. If
web technicians and developers handle all other markup and coding, why
wouldn’t those professionals also be called upon
to write the site’s style
sheet? The answer is simple—style sheets control typography and layout, and
that makes them the designer’s responsibility.
(You don’t really want a
programmer deciding how your web typography should look, do you?)
0 comments:
Post a Comment