Re: List of changes in Nov.7 draft from Sept. 17 version

On Fri, 14 Nov 1997, eva wrote:

> IE 4.0 supports the elements INS and DEL.

It does? Which version? My version, 4.0 Platform Preview (4.71.1008.3),
seems to ignore the INS and DEL tags completely.
                                                                                
> Why not use them in the next draft
> or PR so that all changes can be easily spotted?

Some people have suggested that INS and DEL don't degrade well on browsers
which don't support them. Well INS obviously degrades decently: you
just miss the information that a portion of text is new as compared
with previous version. But DEL does not: on browsers which don't
support it (majority of browsers now), you see deleted text as normal
text. A clumsy way to overcome this would be to use STRIKE within DEL,
but it would confuse things on browsers which support DEL (in their
own way, with which STRIKE may interfere) and would not help on old
browsers which do not support STRIKE either.

Naturally, the process of defining HTML 4.0 would be a good place to
show what one can do with INS and DEL to indicate changes - not
only differences between drafts, but also differences between
HTML 3.2 and proposed HTML 4.0; those differences would be much more
crucial to normal readers of the spec.

As I have remarked in http://www.hut.fi/u/jkorpela/HTML4.0/comments.html
(which is based on an old draft, but most remarks seem to apply to the DP
equally well), the INS and DEL elements themselves are too simplistic
to be useful. It is unnatural to indicate a _change_ (say, replacing
a statement by a new formulation) as a DEL and an INS. And it does
not work well in practice. And it does not downgrade.

Actually, the logical solution which would work for simple cases
would be a single element indicating change. Something like

     <CHANGE KIND=kind OLD="oldurl" REASON="explurl"
     new text
     </CHANGE>

where KIND would have one of a few enumerated values (indicating
especially whether the matter-of-fact content or just the wording
as changed), OLD would refer, typically using a fragment URL,
to the old version of the text, and REASON would optionally provide a link
to a document (or section in a document) explaining why the change was
made.

The suggested rendering would be to indicate  that there is a change,
as well as what part of the document belongs to a changed part,
using for instance a change bar on the left (better than on right, for
obvious (?) reasons) or a distinctive (yet undisturbing) background color.

Naturally, a CHANGE element with empty content (no new text) would
be used for deletions; browsers could indicate such situations e.g. by
providing a generic symbol of deletion (which you could click in order
to see the old text in a separate window, for example). And a CHANGE
element without an OLD attribute would be interpreted as an insertion.

Such a CHANGE (or perhaps CHG, for brevity) element would downgrade
gracefully: a browser which ignores CHANGE tags would just show the
content of the CHANGE element, the new text which really belongs to the
current document.

For more complicated revision histories one would need something
more elaborate. The same applies to things like changing the order
of sections in a document. We can worry about such things later; perhaps
they should not be expressed using specific HTML elements at all but
in separate documents of changes (and using LINK to link to them).
The need for simple change indications, expressible using CHANGE, seems
to be very common, so it seems natural to deal with them in HTML.

Yucca, http://www.hut.fi/u/jkorpela/

Received on Friday, 14 November 1997 04:19:12 UTC