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.
TECHNIQUE: Browser specific HTML from a single HTML file (long)
Subject:TECHNIQUE: Browser specific HTML from a single HTML file (long) From:Chet Ensign <censign -at- INTERSERV -dot- COM> Date:Fri, 21 Feb 1997 21:43:37 -0500
I wrote the other day that I'm experimenting with a simple to create HTML
files for multiple browsers, and let the reader determine how to view it. I
promised to pass along more details, so here goes.
Actually, this is taking much longer than I'd expected. Just more to explain
that I'd planned on. And, since I'm about to signoff and go to the
Documentum conference in CA for the coming week, I'll have to do this
serially. This, then, is the first installment.
The approach I'm exploring uses 2 simple, standard SGML capabilities:
external entities and marked sections. Entities can be thought of as
variables in the file, and marked sections as conditional text. The approach
also makes use of catalogs, using the format specified in SGML Open's
Technical Resolution 9401:1995 (info at www.sgmlopen.org), to resolve the
entities and marked sections when a reader clicks on a link.
In this approach, instead of clicking hypertext links that simply call a
fixed HTML page, as is commonly done in most Web sites, the link executes a
cgi script that calls a program to process the HTML file and handle all the
entities and marked sections. The program that does the work is SGMLNORM, a
freeware SGML parser developed and given to the world by the most excellent
James Clark. You can download this program from his Web page at
www.jclark.com (or by anonymous ftp from ftp.jclark.com). Executables for
the NSGMLS parser and the SGMLNORM program are available for Windows and
UNIX and, I believe, OS/2.
SGMLNORM takes as input an SGML file (in this case, HTML), a DTD and a
catalog, and puts out a finished HTML file, where the entities have been
turned into the appropriate text or graphics and the proper marked sections
included. By using different catalogs, you can generate different HTML
files. For example:
HTML DTD Catalog for Netscape 2.0
HTML file -----------> SGMLNORM -------------> HTML for Netscape 2.0
HTML DTD Catalog for I'Net explorer
HTML file -----------> SGMLNORM -------------> HTML for Internet Explorer
HTML DTD Catalog for text only version
HTML file -----------> SGMLNORM -------------> HTML for the text-only
Again, it is the same HTML file going in. The only thing that changes is the
catalog used. That's the big picture. Let me go into some details.
Any of you who have looked HTML in the face have seen entity references.
They look like &this;. Or actually, more like this (&cpy;).
Web browsers have a fixed set of entities hard-coded into them, so you've
not had to concern yourselves with where they come from. But they are
actually objects that can be defined in an SGML DTD and then used throughout
a document that conforms to that DTD. For example, I can declare an entity
<!ENTITY email-author "Chet" >
and then use &email-author; throughout the document. "Chet" will be
substituted in the output. Change authors? Just change the entity value in
one place, and your whole document is up-to-date. Now that may not be a very
compelling example. But how about this one: &New-product-name; That worked
like magic when a product manager of my acquaintance discovered, 2 days
before we had to go to press, that the name he had been using for the new
product was already trademarked. We changed the value in the entity
declaration and put out a new manual on the spot. A bit more interesting
example, I hope.
You can think of entities as variables in your document. Now, Web browsers
are not going to resolve arbitrary entities that you define for your own
purposes, so you have to do that before you send the HTML to the browser.
You can do a number of things using external entities in your HTML file.
Let's say you want your Internet Explorer pages to have a real Fritz Lang,
retro-Metropolis look to it. The Netscape version you want kind of crusty,
Ralph Laurenish. As part of this look, the background of the Internet
Explorer version should use rocket.gif, and the Netscape should use
flannel.gif, and the text-only version should have no background at all.
You can code your HTML file like this:
<TITLE>My Spiffy Web Page</TITLE>
<p>We have customized...
Now the Microsoft catalog will call in a file that contains the entity
<!ENTITY backgnd 'BACKGROUND="rockets.gif" ' >
and the output of SGMLNORM will be:
<BODY BACKGROUND="rockets.gif" >
<p>We have customized...
The Netscape catalog of course will include flannel.gif instead, and the
text-only version will simply replace the entity with a blank space.
Entities can also provide text. For a simple version, you might have the
We have customized our Web site for your &browser-type; browser. We hope
you appreciate all
the hard work we've done.
at the beginning of your Web page. The Microsoft catalog will contain a
<!ENTITY browser-type "Microsoft Internet Explorer" >
Actually, I'm sure anyone who plays with this for half an hour or so will
come up with even more ideas than I can. The point is, by defining non-HTML
variables in your DTD and using them in your HTML files, you can customize
graphics, text, even different types of markup, dynamically rather than
having to have copies of HTML files sitting on your server.
Next time, I'll explain marked sections, then go into detail on how all
these pieces fit together. I am also looking for a place where I can
assemble all the basic pieces together (HTML DTD, sample catalogs, etc.) so
that people have a starting point for trying this out.
Until later, best regards,
Chet Ensign Office: 212-216-8466
Manager of Data Architecture Home: 201-378-3472
Matthew Bender & Company, Inc. Email: censign -at- bender -dot- com
New York, NY