Fw: end tags...

Carl Morris (msftrncs@htcnet.com)
Sun, 22 Sep 1996 17:09:30 -0500

Message-Id: <199609222213.RAA26044@inet.htcnet.com>
From: "Carl Morris" <msftrncs@htcnet.com>
To: "WWW HTML List" <www-html@w3.org>
Subject: Fw: end tags...
Date: Sun, 22 Sep 1996 17:09:30 -0500

I forward this back to the list because the reciprient's email server
is not taking my messages...

-|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|-
-|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|-
-|- -|-

| From: Carl Morris <msftrncs@htcnet.com>
| To: Murray Altheim <murray@spyglass.com>
| Subject: Re: end tags...
| Date: Sunday, September 22, 1996 5:01 PM
| | You really need to get a handle on your anger -- there is no
| conspiracy. In
| | previous messages you've mentioned you understand programming
| languages.
| | Try leaving a semicolon off of the end of a C statement. The
| particular
| | syntax of a DTD is no more arcane than C or SmallTalk or Lisp or
| HyperTalk
| | -- it's just different. I learned DTD syntax in about a month, and
| I'm no
| | genius.
| handle on my humor...  See, one mans humor is anothers anger it
| seems...  
| | I would advise browsers to let users know when it has encountered a
| | document that is not valid/is not understood, maybe just a little
| icon that
| | has a check mark if valid and an "X" if not. Not obtrusive. The
| problem is
| | twofold: a browser is not a validator (nor should it be), and it's
| the
| | responsibility of browsers to handle bad content, not choke on it.
| But upon
| | encountering an error, it's impossible to assume "what was meant".
| The
| | general nature of parsing errors is their ambiguity.
| But, I use a browser as a validator!  I try anyway... but MSIE
| always tell ya much ...  I use a notepad like editor, typing tags
| directly, and them rely on MSIE showing me whether its any good or
| not... a browser that would show errors to me would be a major plus,
| but like you said, its got to be non obtrusive, in that what may
| to be an error for one browser maybe what makes it compatible with
| another older browser... (like my placing <P>'s infront of tables for
| older LYNX)...
| | Many can be assumed, hence the DTD's declaring them as optional.
| | others, the lack of and end tag creates an ambiguity that cannot be
| | remedied.
| Well, in trying to write a parser I am saying the parser has all the
| rules..., it knows when an end tag is fully optional versus when it
| only remotely optional...  I guess that by optional you are meaning
| that I never have to use it if I don't want...  I don't take this
| option definition that far... look at the definition for <LI>... I
| don't even think they use the word optional, I think it said "is not
| needed at all", versus that of <P> which states optional...
| (That and I have yet to run into a browser that did need the closing
| tags for <LI>, I have ran into many that needed them for <P>, MSIE
| being one of them)
| I am away from the spec at the moment, but on tables, isn't the
| tags of <TD> and <TR> optional ... so why does netscape crash a
| system when their not used?
|  :(
| oh well...