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.
Subject:Re[2]: Front Page Fussy From:"Walker, Arlen P" <Arlen -dot- P -dot- Walker -at- JCI -dot- COM> Date:Wed, 13 Jan 1999 15:14:57 -0600
HTML is a standard. "Crappy" can only describe something that does
not conform to the standard. Ergo, because FP creates standard HTML,
it cannot be described as "crappy." Find a different argument.
Actually, "non-standard" is the term which denotes "does not conform to the
standard." It's perfectly possible for crappy tech writing to conform 100%
to the language standard (a paragraph can grammatically perfect yet not
convey the information it is required to convey, which makes it a crappy
paragraph). Likewise, it's perfectly possible for HTML to perfectly conform
to the standard and still be crappy.
FP is a usuable tool, but its usability decreases as you add other tools to
the mix. For example, ImageStyler can produce some wonderfully designed
pages, but once those pages have passed through FP, don't expect
ImageStyler to be of much use anymore. In my experience, once you use FP on
a project, you'd best be committed to using nothing else for the life of
the project, as it will be painful to switch back. If you want to use FP,
by all means do so. Who's stopping you? Just don't equate conformance to
standard with good code. They're independent variables.
One can use FP to produce some good pages; I don't think anyone's denied
that. The real question is what do you intend to do with the page? FP has a
tendency to produce code with lots of fat in it; lots of extra statements
which, while they conform to the standard, don't have to be there and do
little but slow a browser down. This excess baggage can be removed from the
pages, and the resulting pages, which still conform to the standard,
download faster, parse faster, and display faster. And isn't that the best
metric for web designs?
I'm reminded of the annual contest run in one of the programming magazines:
the Obfuscated C code contest. Prizes were awarded for the most convoluted,
contorted C code entered. To be eligible to win, however, the code had to
compile and execute properly. In other words, the code had to be crappy,
but conform to the standard.
If someone were to sponsor a similar contest for HTML, my own experience
with the tool tells me I shouldn't bet against FP winning.
Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224
Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.
