TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
bryan -dot- westbrook -at- amd -dot- com wrote:
>
> One thing that I think people are losing sight of in the age of WYSIWYG HTML
> programs is that HTML was never meant to allow exact layout control.
>
> .. I revised a document ... software had inserted font face, size, and color
> tags (as well as ...) for every cell of that table. ...
>From the Wold Wide Web Consortium's "Guidelines for authoring":
> 2.FONT tag considered harmful! Many filters from word-processing packages,
> and also some HTML authoring tools, generate HTML code which is completely
> contrary to the design goals of the language. What they do is to look at a
> document almost purely from the point of view of layout, and then mimic that
> layout in HTML by doing tricks with FONT, BR and (non-breaking spaces).
> HTML documents are supposed to be structured around items such as paragraphs,
> headings and lists. Yet some of these documents barely have a paragraph tag
> in sight!
>
> The problem comes when the content of pages needs to be updated, or given a
> new layout, or re-cast in XML (which is now to be the new mark-up language).
> With proper use of HTML, such operations are not difficult, but with a muddle
> of non-structural tags it's quite a different matter; maintenance tasks become
> impractical. To correct pages suffering from injudicious use of FONT, try the
> HTML Tidy program, which will do its best to put things right and generate
> better and more manageable HTML.
I think they understate the case.
There's a natural division between document structure, which the author must
handle, and display or printing options which often need to be under user
control:
user may have bad eyes, need bigger font
colourblind, needs different colours
wants prinout to fit his binders
wants display to fit his window
simple preference
I believe that it is a design deficiency if a general-purpose text-handling
system allows the author insert font settings anywhere except in a style
sheet, and an outright bug if it inserts them itself.
> By the time I was through cleaning that mess up, not only did it look better
> but it was only 10% of the original size and was compatible all the way back
> to the earliest browsers that allow tables.
>
> -----Original Message-----
> From: Dick Margulis [mailto:margulis -at- mail -dot- fiam -dot- net]
> Sent: Wednesday, January 17, 2001 1:05 PM
> To: TECHWR-L
> Subject: Re: font size equivalence
>
> The HTML font sizes are relative to the user's selected browser preferences.
> Different browsers interpret point sizes and pixel counts differently (look
> at the same page in Netscape and IE to see what I mean); so it's really not
> possible to equate the two numbering systems.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area. http://www.pdfconference.com or toll-free 877/278-2131.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.