Members' input on Web and e-mail

In this issue, I am sharing some of the e-mail messages I received from you -- our members. Following are contributions that address:
    * IEEE Internet services, with a thoughtful plea for keeping traditional services;
    * image maps: (a) noting a current disadvantage of using image links; and
                                (b) making the case for including ALT tags;
    * Web page links: describing correct coding when mixing tables and menus; and finally
    * e-mail attachments, noting incompatible variations of UU-encoding.

IEEE INTERNET SERVICES.   Frank Preston writes ... "Your recent column (September '97) discussed IEEE Internet use, services, etc. You stated that the objective is to do business over the Internet. This is a given, of course. You also state that 'Traditional services will be maintained ... ' This should be an absolute requirement, but I seriously doubt if it will last very long. Someone will see that they can save money by the elimination of the 'duplication' and the traditional will go down the tubes.

"Here at NASA Langley, we used to have a weekly newsletter for employees. Then, with great fanfare, an on-line duplicate service was added and both were available. After about six months, the paper copy disappeared. Finally, after about a year, the on-line version has degenerated to a listing of events, etc. It is now practically worthless.

"If I can only have one, I want the traditional services and the hard copy. With more and more on the Internet, the old stuff is being deleted as it ages and the reference data is lost forever to libraries and members.

"One nitpick: You said that more women are using the Internet. This statement is ambiguous. Are 42 percent of the users now women, or did you mean that 42 percent of the women are using the Internet?"

(To you and several other members who e-mailed me: the 42 percent is of users, not of all women.)

IMAGE MAPS.   Andy of Intel Corporation writes, "Image maps have another disadvantage, from the user's point of view, that you did not mention (July '97 column): ordinary links, whether in straight text or tables, change colors when the user has visited them. This makes it easier for a user to browse a complicated web of pages. Image map links do not change color in this manner. (They could -- it is just a 'simple matter of programming' -- but they do not on any browser I know.)

"I find this lack of history extremely annoying. I hate waiting a minute to download a page, only to learn that I have already seen it, via another link (or even the same link). I applauded when The Wall Street Journal on-line edition (I am a paid subscriber) started removing image links on some of its pages."

Andrew Plumb of the Canadian Microelectronics Centre writes, "I enjoy reading your articles, however ... :-) in this latest 'Traveling the Information Highway' (July '97) your code bits and the 'www.ieee.org/template/' examples seem to be missing some rather important 'ALT' tags. "The following example is snipped from 'templ_1.htm': <A HREF="/index.html"> <IMGSRC="http://www.ieee.org/graphics/home.gif" WIDTH="36" HEIGHT="46" rdony@uoguelph.ca BORDER="0"> </A< (end snippet).

"The index.html link and even the nav_bar could use the ALT tags, otherwise when I browse the page with images off or a text-to-speech browser (as some of my blind friends would) I wouldn't necessarily know that the index.html image was a link.

"Other text browsers (like Lynx) replace and read all non-ALT'ed images with [IMAGE] or [IMG], which doesn't tell me much.

"Just one of my little peeves. :-) Use ALT tags liberally!"

[I agree. I did not think of the reasons you quoted -- I have changed my coding where I use graphic links. In the example snipped from the IEEE template, one would add the attribute ALT="Link to IEEE Home Page" inside the IMG tag. Please note I am using the descriptors tag and attribute to differentiate between a tag and what can appear inside the tag. [Andrew refers to ALT as a tag.)]

WEB PAGE LINKS.   Layne Watson of the departments of computer science and mathematics at Virginia Polytechnic Institute and State University writes, "Bob, if someone has already pointed out that the HTML in your August '97 column in The Institute is illegal, then ignore the rest of this message. If not, I wish to point out that the nesting of menu and table is technically illegal. A good browser will refuse to process it at all, and its behavior otherwise is unpredictable. The definition of "menu" says that it may only contain list items (hence the <table> right after <menu> is technically illegal), and that those list items may be displayed several per line.

"So some browser could logically take your <li>s and arrange them in lines any way it wants, regardless of the table directives. You lucked out because your browser chose to arrange the <li>s according to the <table> directives rather than as <menu> directives.

"Also the construct <td> <li> is technically incorrect -- the <li> is an orphan list item, having no surrounding list. Again, you lucked out because your browser chose to "propagate" the <menu> in front of each <li>. Technically, you should have <td> <menu> <li> ... </menu> </td> for each table cell.

"Yes, I know, a lot of programs (Microsoft, especially) generate such HTML, but that doesn't make it right. I'm sensitive to this sort of thing because my class notes are read by students with many different browser versions, and 'illegal' HTML generally doesn't work right for somebody.

"This is no big deal, but since your column is read by lots of people, we ought to at least give technically correct examples."

[My thanks also to Klaus Johannes Rusch, who wrote me on the same points.]

E-MAIL ATTACHMENTS.   Michael French writes, "Bob, I enjoyed reading your October '97 article in The Institute on e-mail attachments.

"One item I believe worth adding is the advice to stay away from UU-encoding if at all possible.

"Over the years, several incompatible variations of UU-encoding have been put into use which has resulted in chaos. Whereas, to my knowledge only one variation of each MIME (Base64) and BinHex4 exist which makes their use reliable. Moreover, BinHex4 works fine on all platforms, not just Macs. For instance, I've experimentally found that both Eudora (1.5 and 3) and Pegasus (2.5) on a Windows-based computer decode BinHex4 flawlessly regardless of the SMTP header setup.

"Such is not the case for MIME (Base64)-encoded enclosures. The SMTP headers must be set up exactly right for Eudora or Pegasus (and I suspect all mail readers) to decode them.

"Since BinHex4 contains a CRC, and is so readily, automatically decoded by the most popular mail readers, I have come to the conclusion that BinHex4, not MIME (Base64), should be the default standard used by e-mail senders."

[My thanks to all of you who send me e-mail. I do try to respond to every one of you --sometimes I get behind in my acknowledgments but please keep those messages coming. I appreciate your compliments, corrections, advice and suggestions for future articles.]