If you're a web designer who's spent any time at all on comp.infosystems.www.authorin g.html, you must have heard some of the violent arguments that constantly go on. Some users of HTML would like to be able to design web sites with absolute control over how their readers see them (David Siegel, for example). Others would like to maintain a platform independent language while others still would like to achieve both goals, not realizing that they are mutually exclusive.
Even if you haven't spent any time on the newsgroup, you've no doubt visited MANY pages proudly displaying that they are Netscape enhanced. In fact, it's become almost a fashion statement -- you get to put a nice icon on your page, and hey, after all, your page seems to look better when you use Netscape extensions. If only it were that easy...
Why I'm focusing in on NHTML, or Netscape-HTML, or whatever you'd like to call it, is to counter the myth that Netscape has played a large role in forming: that you can have absolute control over how your document appears. From their incredibly inane implementation and proposal of the CENTER tag to their more recent FONT and even the most recent MULTICOL, NS has proposed tags that purport to give web authors more control. In actuality, they only compound the myth.
What NS doesn't seem to have realized, even from the beginning, is that HTML is for marking up the structure of a document, not its layout. HTML is good for most applications; some applications, like poetry, won't be served as well as others, simply because many poems require a particular layout in order to be effective. The typical novel, on the other hand, can be represented adequately in HTML.
Tags like CENTER only hurt the language. What does centered text say about structure? Well, in most cases, nothing at all. Same with font size and color. In fact, if you go back and look at the original documents, you find that it was explicitly stated that HTML should NOT have control of items like that! In fact, font color was even an example given!
HTML wasn't meant to make documents look great. It was meant to mark up structure. I'm not saying that there's not a place on the web for great looking documents. HTML can produce them; with the help of style sheets. What are style sheets?
Style sheets are files that would be linked to from an HTML document that would allow the author of the document to correctly mark up the structure of the HTML document and suggest a layout and a proposed rendering for several of the tags in the style sheet. One major proposal is CSS, which currently has a draft out. Unfortunately, Netscape has yet to implement it. Then again, from a company who never even produced a DTD for their extensions, this comes as no great surprise. Note that Netscape has promised their support in version 4.0 of their browser, code name Galileo. However, for version 3.0, their comments were encouraging. A quote from an article in Webweek says the following:
Actually, Netscape's company line is that style sheets will "not be fully implemented," as it is worded by Navigator 3.0 product manager Edith Gong. When pressed, she acknowledges that the only way Navigator really will support style sheets is that the company will promote a set of Netscape-created HTML tags that mimic the most popular fraction of style sheets' functionality--the management of white space.
Pretty sad, eh? Then again, coming from Netscape, this isn't exactly a first.
Besides going against the web's purpose, NHTML is often unpredictable. For example, consider the CENTER tag. Netscape's specification, taken from their HTML 2 Extensions page, says the following:
You aren't dreaming, yes you can center your text. All lines of text between the begin and end of CENTER are centered between the current left and right margins. A new tag has been introduced rather than using the proposed <P Align="center"> because using <P Align="center"> breaks many existing browsers when the <P> tag is used as a container. The <P Align="center"> tag is also less general and does not support all cases where centering may be desired.
Unfortunately, while this at first seems like a more than adequate definition, it is both misleading and underspecified. First off, misleading:
First, I object to the statement that <P Align="center"> breaks many existing browsers when P is used as a container. Excuse me, but P was always a container; it's end tag was simply optional. Secondly, even if it were not, how would this break existing browsers? Would they choke on the end tag? Certainly not! In fact, I have yet to see one browser that this breaks!!!
Secondly, their statement "A new tag has been introduced rather than using the ... " implies that one was implemented, the other not. On the contrary, both <P ALIGN=center> and CENTER have worked since Netscape's humble version 1.0!
Netscape's definition also leads one to believe that the proposed methods of centering present in the HTML 3.0 proposed specification were inadequate for the cases desired. This is wrong. While it may be very well true that <P Align="center"> will not center everything you might want (only paragraphs), the proposed HTML 3 standard was certainly adequate for centering other things. Want to center a header? Simply type <H x ALIGN=center>;. Similarly, many other block elements can be centered simply by attaching the ALIGN=center attribute.
Now on to our next fun topic: CENTER is underspecified. For example, above it says that " All lines of text between the begin and end of CENTER are centered between the current left and right margins.". What happens if the text is in a table? Is the table centered or simply the text within or both? From the above definition we might expect the lines of text, not the table to be centered -- if we were going by Netscape's implementation, we'd see it's the other way around. What about an unordered list? Should the whole list be centered or should the individual lines be (i.e., do the bullets line up)?
What happens if text is placed within the <CENTER> tag within a <P ALIGN=right>? Which takes precedence? This is a rhetorical question; it's easy enough to see what some versions of Netscape do with it, but either way, it's underspecified: if another browser implemented the tag, who's to say they'd be wrong if they let <center> take precendence over <P ALIGN=right>?
This is one of the most common complaints I get from people like my friend Barbann. I tell her repeatedly that the web isn't for layout, but rather for structural markup. She tells me "I know, but it works for what I want". I have news: it doesn't work.
This is another problem with Netscape enhancements. Many people using them forget that there are those out there still using either REALLY old versions of Netscape or text browsers, neither of which benefits from NS enhancements. In itself, this isn't a problem: you can't expect old browsers to recognize new tags. The unfortunate part is that those designing for NS often use nonstandard tags or standard tags in a nonstandard way, that can even go so far as to hurt the display on older (or recent Non-NS) browsers.
I've talked with people who've actually said that they didn't care how their page looked on earlier or non-NS browsers. Perhaps they'd be surprised to hear how many people browse with image loading off or with an earlier version of Netscape. I'll post some statistics as soon as I can get them.
I'm going to cover each of the stupid NS tricks listed above individually. First off, trick #1. People using this either don't realize that dd actually _means_ something or don't care. As I said above, HTML is to mark up structure, not presentation. When you use this tag, you show that what follows is a definition of a term in a definition list. When a term like this is taken out of context, browsers can do whatever they like with it. Netscape, probably because it was easiest to implement, simply chose to indent when it sees this term. Other browsers aren't so kind
Secondly, what happens if I design a browser that does a definition list in a different way? I can imagine simply being presented with a list of terms and having the definition pop up over a term as I move the mouse over it. This is a perfectly valid way to evaluate proper HTML. It simply happens that this isn't a current implementation.
The next trick has been covered adequately on c.i.w.a.h. Using a single-pixel GIF merely for presentational effects is dumb. Secondly, many NS users browse with image loading off, either because they're on a slow line or simply because they want to get a page more quickly. A page full of single-pixel GIFs looks horrible, because NS' icon when it doesn't load a picture isn't very pretty. I'll discuss another reason that applies to this in a second, while discussing the next "trick".
Using a row of non-breaking spaces is dumb for two reasons:
The truth of the matter is, white space is collapsible according to the proposed HTML 3 draft. While this draft has expired, I believe that many of the concepts present there still reflect current thought.
Secondly, there's nothing to prevent a browser from already indenting a paragraph. Someone on c.i.w.a.h recently kept blaming the HTML creators for the fact that paragraphs weren't indented. What he didn't understand was that there's no reason to blame the people who designed HTML! A paragraph is a paragraph. If you'd like an ident, NS could very easily have set up their browser so that any time a P was encountered, not only were spaces skipped, but the first line was indented. They chose not to. Other browsers (notably some versions of Mosaic) will give you the option. Adding extra spaces or a special GIF will only make your paragraph look even worse than it would have without an ident.
The last trick that NS designers use, and think is clever, is to put multiple BR tags in a document instead of using the P tag. This is a grave error, as those that do this have missed the fundamental point stated above: HTML is for structural markup.
Look at the above picture of the structure of a sample document, taken from a screen shot of Webber, my HTML editor of choice. Without paragraph tags separating the paragraphs (what a novel idea), how's a browser supposed to tell the structure? Secondly, who's to say that multiple BR tags should produce a larger space. It does so on Netscape, but you could argue that once you break a line once (yes, the BR tag is a line break), you can't break it again.
By now you're either convinced or you think I'm crazy. Either way, I encourage you to visit some other anti-Netscape pages for a better explanation of why people like me feel as I do. Here are some nice links:
Here are some more links on the w3's server
Here are some more style sheet links
Page maintained by Paul Pollack