Re: HTML+ Comments

Guido.van.Rossum@cwi.nl
Mon, 19 Jul 1993 12:43:53 +0200


henrich@crh.cl.msu.edu:

> 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.

Dave Ragget:

> 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?

Not all tags are brackets (e.g. <BR> and <P> aren't). The HTML-0 spec
has the useful property that if you ignore unknown tags and end tags
you can still match up properly the tags that you do understand, even
if you don't know whether the unknown tags are brackets or not. I
don't know if in HTML+ specifies that unknown tags must be ignored.
If it does, </> introduces a problem: if you've ignored a tag and then
you find a subsequent </>, you don't know if the tag you ignored was
bracket or not, and hence you don't know whether to ignore the </> or
match it up with the previous bracket.

In other words, I'd like to see </> go as well.

> Physical styles are hints to the browser, and independent of the logical
> role of emphasis. I forsee browsers ascribing particular styles to certain
> roles which override the hints. It didn't seem worth keeping <b>, <i> and <u>
> given that the others had been removed.

Fine, but what happened with HTML-0 compatibility? You leave <IMG> in
for compatibility, but drop <I> <B> <U> in spite of it. Personally
I'd really favor being completely backward compatible, since it
appears that HTML-0 might have a long life of its own, especially once
canonicalized as an informative RFC.

---

Some unrelated remarks of my own after scanning through the HTML+ doc (can't find my copy now so I'm working from memory here):

1) The section where you address implementers and give various hints about the implementation doesn't really belong in a spec of this type -- maybe it can be an appendix. It is quite possible that I want to implement HTML+ in a totally different context than a web browser after all, and I prefer to have just the specs as a defining document.

2) The overview of tags mentions the <ICON> tag -- I suppose this should be <IMG> and <FIG> tags.

3) The definition of <P> allows some attributes (I believe an "ID" for a link destination) that label the paragraph. Unfortunately <P> is between two paragraphs -- which one gets the attributes? (Some styles of formatting raw HTML keep the <P> tags consistently at the end of the first paragraph, others don't.)

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>