Re: HTML+ Comments

• Mail folder: WWW Talk Jul-Oct 1993
• Next message: Guido.van.Rossum@cwi.nl: "Re: HTML+ Comments "
• Previous message: Peter Lister, Cranfield Computer Centre: "Re: HTML+ Comments"
• Reply: Charles Henrich: "Re: HTML+ Comments"

From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9307201041.AA11341@manuel.hpl.hp.com>
Subject: Re: HTML+ Comments
To: www-talk@nxoc01.cern.ch
Date: Tue, 20 Jul 93 11:41:57 BST
Mailer: Elm [revision: 66.36.1.1]
Status: RO

The workshop is now coming up fast, and I would like to update the HTML+ spec
to include recent comments, to give everyone a chance of printing out a copy
in advance of traveling to Cambridge.

    1)  Minimization of the end tag to </>

Allowing this causes problems with unknown tags, which may or may not
have end tags. I therefore propose to forbid all forms of minimisation.

    2)  Backwards compatibility with HTML

        Two ideas:

        a)  Include <CITE>, <MENU> and <B> etc. in the DTD as
            deprecated elements for backwards compatibility

        b)  Don't include them as part of the HTML+ standard
            but suggest that browser writers provide continued
            support for them for for backwards compatibility.

I personally favour (b) as its cleaner.

    3)  Notes to Implementors

This section will be moved to an appendix and perhaps merged with suggestions
on backwards compatibility.

    4)  <P> as a container

In HTML this acts as a separator. In HTML+ it acts as a container for the text
FOLLOWING the <P> element. This allows authors to tag the paragraph's role
and to specify rendering hints, e.g. to indent the margins. It also allows
hypertext links to be anchored on whole paragraphs.

I propose to leave this part of the spec alone.

    5) Support for Annotations

It seems a neat idea to allow annotations to be held separately from
documents and later merged together. The PANEL element can already be used
for this purpose. I have added an IDREF attribute to the FIGT tag to allow
figure overlays to be also treated in this way.

To allow users to select an arbitrary part of a document for an annotation
I have added a new tag: NOTE with similar attributes to the CHANGED tag. This
would have to inserted into the document and then acts in a similar way to
the syntactically more restricted "A" tag.

I forsee the URL syntax for anchors being extended to allow specifying
character offsets from the start of the document (or a named element), and
perhaps also to permit pattern matching as a mechanism for gracefully coping
with minor changes to documents. Such extensions would allow arbitrary
annotations to made independently of whether suitable predefined anchors are
available in the document or not.

    6)  Error detection

How about an error tag? This could be detected even inside the EMBED element
since "<" characters are required to be escaped as per PRE. In theory one
could even cope with nested errors.

I propose to include this in the spec.

How does that sound?

Dave Raggett