Netscape freezes

[Elisabeth Roche]

There is a fundamental reason why your browser might freeze. See the
following for explanation. Duif Calvin is an expert in HTML and more; a
moderator of one of the HTML Writers Guild lists, and a mentor to anyone
who needs help. She knows how to pay back to the Internet:))

Read this carefully and a lot of things will start to clear up. Then go
validate every page......check which DTD the source code is using!!!!

Elisabeth Roche ace at opus1.com
serendipity RULES!
			Great Questions...Thoughtful Answers
				http://www.answers.com/


----fwd first part of this is Duif Calvin replying-------

It can be very frustrating, can't it?  
As I see it, many of the problems you've encountered, though,
aren't from HTML itself, but rather from proprietary extensions to
HTML which are still in an experimental phase.

I'm not sure if you're aware of this, but HTML is an application of SGML,
which
is in fact an ISO standard.  That's a lot of acronyms in one sentence,
so let me see if I can turn it into something a bit like English:
HTML, in its official format, is actually an engineering standard.
Each version of the language is published in a DTD, and these are
available from, among other places, the W3C, or WWW Consortium,
which is the international organization currently publishing these 
standards.
(You'll find them at 
http://www.w3.org/  )

The official specifications go through months of Internet community
discussion (you'll find a number of the discussion groups and mailing
lists at the W3C site), and points such as those you've made are,
indeed, an important step in the process.  There's quite a bit of
work done on keeping things consistent and logical.

For example, the current official specification is RFC 1866, commonly
called HTML 2.0  The current official proposal is HTML 3.2,
and it's been out there for discussion in its official state since
July.

However, at the same time that the W3C (and, earlier, the IETF)
are working on the official specs, individual browser makers are
trying to get an edge in marketshare.  One way that they do this
is by offering features not available in other browsers.  Some of these
features have to do with using the browser as a reader, and may include
additional options, bulit-in mail readers, and so on.

Other features have to do with HTML mark-up tags that the browser
will recognize, thus giving Website designers the option to include
these experimental tags, or "extensions" so that readers using that
particular browser will have a different experience.  It's actually slightly
to the advantage of the browser makers, as Netscape discovered early,
to create "nice" tags that can ONLY be seen by that particular browser,
since that forces marketshare.  

However, it can be a real pain for developers designing for the open Web.

Frames are experimental, introduced by Netscape in NS 2.0  Microsoft
followed with frames support in MSIE 3.0--BUT, as you've noted, they
didn't do it quite the same way as NS.  Same thing with sounds, javascript,
etc.

However, once something gets into the actual specifications, most of
the kinks are ironed out, it's made more consistent with the existing
language,
and hopefully all the browser makers eventually start meeting the spec
rather than using their individual variants, thus making the designer's
life much simpler.

This happened most recently with tables.  Originally there were three
versions of tables commonly in use:  Netscape's (which came in in 
NS 1.*), a proposal (which was not adopted) that came along
about the same time as HTML 3.0, and a new variant which eventually
became officially part of HTML 3.2  That's one reason why tables worked
quite a bit differently in MSIE 2.0, NS 2.0, and Mosaic 2.0.  however,
presumably by the time we get to the 4's in these browsers, everyone will
be using the HTML 3.2 specification, and things will go smoothly for those
of us who design.

All of that said, it's helpful to remember that HTML is _not_ a page layout
language, but rather a logical mark-up language, although more and more
visual elements are being added with each release.  One can have 
perfectly valid HTML that does, indeed, look different on different browsers.

Perhaps the greatest advantage of HTML as a design tool is that it is
fully crossplatform.  We don't have to worry about whether the reader
has a Mac, a PC, a UNIX system, or even a nongraphical VT-100. We
don't have to design or support multiple versions.  Tim Berners-Lee,
who invented the Web, has said that the Web "is not about control--it's
about trust."  To a certain extent the designer has to trust that the browser
will come up with a reasonable visual image from the HTML given to it,
even though it won't be EXACTLY the same on each browser.  It's often
enough to go for great-looking in one browser, and pretty good in most
others.

It may help to think of the Web as a broadcast medium, like television.
Much depends on the quality and type of the audience's receiver.
As art directors for television know, there's no point in spending 5 days
to pick the "perfect red" since the individual viewer may have _their_ red
hues turned up so high that Dracula looks rosy-cheeked! <smile>  
Receivers come in different sizes, different graphics qualities--even
different
shapes (Mac terminals have traditionally been taller and narrower than
PC screens, as well as having different gamma values).

By accepting the rewards of one of the first truly crossplatform development
environments, we also accept the burden of never quite knowing how 
the page will look to each individual reader.  This creates a very different
development environment, and different design strategies, than designing
software for a single operating system.

Fortunately, HTML is, as mentioned, part of an engineering specification, and
we have one very helpful tool available to us:  validation.  Validation is
fast,
easy, and free.  It's as valuable as spell-checking; perhaps moreso.  
All validation does is check the page against the engineering spec:
the DTD at that particular language level.  This is a rigorous check.

Sure, you can get something to "look nice" on one particular browser or
one particular workstation.  But the popular Time Warner Pathfinder site
reports they get visits from over 300 different browser types every day--and
that's not even taking into account differences in modem speed, video cards,
and memory.  No one can test that many variations.

Different browsers are forgiving of different things.  Invalid HTML may work
fine on one workstation--but crash another.  Netscape, for example, tends
to "rush through" mark-up, and so is accepting of things that are OK at the
set-up, but have missing end tags or overlapping instructions.  Then when it
gets to the end, it may crash.  MSIE has in general tried to check the whole
page before rendering it; this means it crashes less often than Netscape,
but is more likely to hang-up or refuse to display a broken page.

Every time I get a troubleshooting request from someone who says their
page "locks up" or "hangs up" or crashes or "looks jumbled" or "looks
terrible" I first  start by validating the page.  Often it's something as
simple
as a missing end tag, or something like two BODY tags which are accepted
in some browsers, but are not to spec and will break others.

(You mentioned specifically having two body tags because one was inside
a <NOFRAMES> section.  Remember that browsers that don't support
the experimental FRAMES extensions just throw those tags away--so
those are exactly the browsers that will see the two BODY tags, once all the
experimental tags are removed, and consequently are likely to hang up
or "get confused."  One of the things that validation is particularly good for
is helping with backwards compatability for just this kind of reason.)

If you need more information on validation, Harold Driscoll's excellent
validation FAQ is available as a link from a number of places on the
HWG site, including
http://www.hwg.org/resources/
and take the link to FAQs or Useful URLs

So what does all this mean?  Well, the short answer is that your point
about making the defaults make more sense is well-taken, and I think
that you will find that has generally been done in the official
specifications.
When you're dealing with experimental technologies, I'm afraid you're
going to find that the browser makers are, for commercial reasons, trying
to put their own "stamp" on things BEFORE they get official, and they're
probably going to continue to create differences, sometimes just for the
sake of being different.  It's going to be a never-ending challenge for
Website designers, I think.

One of the ways that we _can_ help ourselves, though, is through
validation.  Admittedly it won't catch everything, and it won't help
on those things outside the specification--but it will give you an excellent
base to start from, and it will certainly point out anything that might cause
backwards compatability problems, or problems with other browsers.
That's a real help when you're designing for the Open Web.

I hope that answers a few questions.  I started out as a database
programmer a long time ago, and since I've also been a professional
editor and writer, I came into Web work (back before graphical browsers)
with a definite control paradigm.  It took me quite awhile to understand
the value in learning to design for crossplatform, but the advantages of
a medium that reached so many people, so easily, kept me hanging in
there through all my own frustrations with the learning curve.  To be honest,
I'm not sure I would have EVER made the perspective shift if it hadn't been
for some very brief experiences in writing for radio and television marketing,
where the differences between broadcast and print seemed much more
intuitive than the Web.  But I did learn, and I've been able to apply that
learning
to some interesting design situations for the Web.

(For example, if you'd like to see a side by side table that degrades
gracefully
into a horizontal organization, take a look at 
http://www.jaderiver.com/paperweb.html

This is an approach that took several iterations to get right, but we did it,
at a time that most designers had given up designing for nontable-supporting
browsers (like AOL's 2.5).  It IS possible, but it does take extra time.

If you don't have a strict  HTML 2.0 browser (that is, a browser that
doesn't support
tables), try viewing it through the Backward Compatability Viewer at
http://www.delorie.com/web/wpbcv.html
)

I hope that helps address a few of the issues surrounding the
confusion of HTML extensions.  I do use them, when appropriate,
but I also validate and check the work visually in a strict HTML
browser as well as a nongraphical one.  I find that this approach
helps protect me from the vagaries of browser makers who are
out to be "different for the sake of being different." <smlie>

Regards,
Duif

p.s.  
Mr. Washer wrote:
>> > The current page in question is located at
>> > http://top.monad.net/~severus/vk
> 
Mr. Driscoll commented:

>> Please, when giving URLs within messages, give complete URLs.(snip)
>>(in your case, the trailing slash is missing).

and Mr. Washer returned to the list with this question:
>
>I have never had any trouble with this, and most of the geeks
>I know feel "the less keystrokes, the better" (ever built a BBS?).  I would
>really like to hear from others regarding this! Am I wrong? Is this a
>common feeling or is Harold being picky? Anyone?
>

Mr. Driscoll's not "being picky" on this one--again, it's an
engineering issue.  It really is true that the specification says that
the closing slash is required to identify a directory as opposed to
a file.  While many browser/server combinations CAN handle the
situation where no trailing slash is given, others can't, and will return
a "not found."

In this case, adding the slash is to your advantage, because
it means that the most people will be able to reach you.  It doesn't
eliminate anyone, and it widens your audience.

This is a case of "Make things as simple as possible--but no simpler."
When you leave off the trailing slash, you've "simplified" one more
step than the specification allows.  You can get away with it on 
many browsers, but not all.  

(I work on a number of international sites, and always submit
the URL to search engines and professional directories as
/%7Efoobar   instead of /~foobar   

One of my students once asked me why I bothered with "all those
extra keystrokes" when the two things mean the same thing.

I said that many keyboards in Japan, Korea, and Thailand don't
have a tilda character.  This way, when someone copies down the
URL or sends it in e-mail or prints out the directory page, their
home office or customers in Asia can still get to the site. 

Sometimes two things that are the same still are of different value
to a designer. <smile>)


--jdc


 -----------------------------------------------------------------------------
jaderiver at jaderiver.com                Jade River Designs
                      Honesty, Quality, and Service
Professional Website design, including CGI/database
http://www.jaderiver.com/    Atlanta             770-989-7407






At 03:09 pm 1/20/97 -0800, Sara Weissman/Morris Cty Library wrote:
>There has been so much about NS freezes here and on PUBLIB-NET that I've
>done some tracking...most of the problem (especially in Mac version) is
>that as pages get more and more graphically intense, your cache is 
>getting bigger and bigger, sooner and sooner. And, at least on Mac,
>clearing cache from Network Options in fact does not clear the cache.
>You have to go into Prefs and toss the files out from there ...MacinTouch
>lately recommended simply setting cache to zero on this account. Last 
>week I found that two people doing moderate webbing over one 24 hr period
>accumated 581 files in cache ..one person, 12 hrs, 381 files. A single
>page often is 7-12 elements. As to printing problem just mentioned..
>check spooled queue (PrintMonitor, if you are on a Mac). Queue is backed
>up and/or printer does not have sufficient memory to handle the page.
>Is it a stand alone or networked printer?
>