- From: Carl Morris <msftrncs@htcnet.com>
- Date: Sun, 22 Sep 1996 17:09:30 -0500
- To: "WWW HTML List" <www-html@w3.org>
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 -|- -|- http://199.120.83.179/~moreese/ -|- ---------- | 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 doesn't | 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 appear | 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. For | | 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 is | 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 closing | tags of <TD> and <TR> optional ... so why does netscape crash a windows | system when their not used? | :( | | oh well... |
Received on Sunday, 22 September 1996 18:09:45 UTC