Re: HTML+ Comments

Kevin Altis ([email protected])
Mon, 19 Jul 1993 13:00:02 -0800


>> 1) The specification allows </> to be a valid end tag for all tag's. I feel
>> this is a mistake as it leades to great ambiguity when the document is bein
>> parsed automatically, or being read by a human.
>
>SGML tags act like brackets and must be properly nested. There is therefore
>no syntactic ambiguity. However, in the real world, people do make typos and
>you are right in suggesting that this abbreviation would make it harder for
>browsers (and people) to recover from errors.
>
>Before I remove this feature, does anyone else feel the same way?

I don't recall much discussion on browser recovery from errors. I thought
that the general idea was to have a server do the parsing so that browsers
aren't complicated by lots of error checking code. A server either parses
the document or it doesn't, how likely are non-parseable documents anyway,
once people stop hand entering all the codes, this is the 90s you know ;)
Even if a server just verifies the correctness of a document before a
client does its own parsing would simplify matter greatly.

In the future, most people will never see the tags, since their editors
will generate the codes automatically, but not show them on screen and
their browsers wouldn't show them unless requested. How often do you see
the formatting codes of your favorite word processor, desktop publishing
program, etc. (WordPerfect users need not answer :>)?

For now, when editing, it is much easier to make a typo when YOU have to
match up your tags than if you always end a tag as </> (you probably would
even bind this sequence to a single keystroke).

Verbosity in the form of requiring a tag end other than </> has little
value today, longer end tags increase file size (though not much),
increases the number of typos when hand entering codes, and probably has no
value as editor/browsers become more sophisticated.

ka