ПитерСайт » Блог » What's wrong with the FONT element?

What's wrong with the FONT element?

When Netscape introduced its FONT element, with its SIZE= and COLOR= attributes, many web authors welcomed the promise of control over the presentation of their documents; the same authors felt a twinge of anticipation when Microsoft introduced an additional FACE= attribute. Many of these authors did not realize that their documents would become invisible, illegible, or inaccessible to many viewers. Yet this is exactly what has happened, due to mistaken expectations and faulty implementation in popular browsers.

Extensions to HTML are said to "degrade gracefully" if they do not interfere with basic legibility in browsers that do not support these extensions. For character-mode browsers such as Lynx, or other browsers that do not support font sizes, colors, and styles, the effects of the FONT element are relatively benign. If the author tries to emphasize specific text by its size or color, the user of the text-mode browser will see the text, but will not see the emphasis. If the author uses font settings instead of HTML headings, the same user will not see headings, and neither will the search engine or indexer looking for keywords in high-level headings to display prominently in the search results. But at least, the Lynx user will be able to see the text.

The truly insidious effects of the FONT element are reserved for users of popular graphic browsers like Netscape and Internet Explorer.

One Netscape user has a laptop with a relatively small display; she has small fonts configured in order to view a decent amount of material on screen. The author has designed a table or other page with ; this text is now so tiny that it's illegible.

Another nearsighted user has his laptop configured with extra-large fonts, and the "web page designer" decides to make a statement with ; now a single phrase occupies most of the display window, and the user gives up in frustration.

A third user has a sophisticated workstation with a large monitor, but, like ten percent of male computer users, he is colorblind, and requires a strong contrast between ordinary text and background. He has carefully configured his browser to use black text on a yellow background, and has specified that his color scheme should override document colors. Along comes a "kewl" web page with white text on a black background. Our user is overriding bodycolors, so he still sees black on yellow. But this page also contains a sentence here, a phrase there, emphasized with  -- this worked fine on the author's black background, but is completely invisible against the user's yellow background. He may wonder what all those empty spaces mean, but unless he views the HTML source, he will never know that he is missing an important part of the author's message. While Netscape allows the user to override text and body colors, it does not allow the user to override font colors.

Howard P. Marvel suggests that an author might set the  attribute to contrast with a table cell whose background color is set with the proprietary  but not <TD BGCOLOR= > may not be able to read this "highlighted" text at all.

A large corporation opens a website to serve its customers in Eastern Europe. Knowing that most of their viewers will have at least one font with an Eastern European Roman or Cyrillic character set, they are careful to set the proper "charset" in the server headers. But then, in an attempt to give the page a distinctive "look and feel," they add the tag ; the Netscape user on a Windows or Mac system may well have at least one of these fonts installed, but only in the common Western European character set. Here, the use of the FONT element means that the user must delete the specified fonts from his system in order to read the text in his native language and alphabet.

An author who "enhances" her pages for Microsoft Internet Explorer decides to play desktop publisher and inserts the  tag in her pages in the hope that others will see what she sees on her Macintosh. The viewer, using Netscape 3.0 on a Unix workstation, sees some approximation of the author's font, but here the letters appear so crowded, the kerning and leading so deranged, that the author's exquisite taste has become an ugly hash. The viewer knows he can modify the X-resources, but thinks instead: why bother, I'll just hit the Back button.

The font tag is a hindrance to communication over the World Wide Web because it makes too many assumptions about the user's system, browser, and configuration. Cascading Style Sheets, on the other hand, negotiate between author and viewer to create a carefully-designed appearance that is accessible to all. People create web documents for many reasons. If you have something to say, information to provide, a message to preach, feelings to express, a product to sell, then it's in your interest to make your work accessible. Smart web authors, who want to get their message across, stay far away from the FONT element.

Is the FONT element ever appropriate? Not the COLOR= or FACE= attributes, nor absolute values of the SIZE= attribute (e.g. ). Relative values may be useful in moderation as a gentle (and expendable) form of emphasis, or to mark legalistic disclaimers or other "fine print." In other words,  and  may be acceptable. But their appearance is precisely duplicated by the long-standing HTML tags <BIG> and . The FONT element is broken in current implementations, is prone to cause unpredictable and unavoidable data loss, and is quickly becoming obsolete with the advent of Style Sheets.

Источник: home.olemiss.edu/~mudws/font.html

Теги: FONT, HTML, Ретро

Опубликовано: 23 Января, 2023
Последнее редактирование: 3 Февраля, 2023