ah, great, no browser changes! :) i but i have a slight problem seeing
how you can communicate from the WWW browser that's ultimately displaying
the HTML to the perl scripts that generates the HTML, if they are run on
the client side -- i they do, they're the browser for media type
application/x-rcs, aren't they? e.g., when you click on a branch you
want that branch displayed, that means the URL must somehow point back
the perl scripts (they'd have to act as a server as well, then?).
well, this is an implementation detail, and a feature of putting revision
support external to the WWW browser.
] I'm considering only doing the third item with block granularity (parag=
raphs,
] lists, blockquotes, etc.) It might be possible to also go down to char=
acter
] level markup with <SPAN> or do arbitrary level markup with <DIV>, but I
] don't want to get so complex on my first attempt. I also don't anticip=
ate
] my first effort to work at all with non-valid documents as I'll be
] using the parser from sgmls to handle the dirty work of identifying HTM=
L
] blocks.
]=20
] Any comments are much appreciated.
great idea that may be acceptable to both camps: use RCS to represent
revision information, but use special HTML tags/attributes in order for
the browser to accurately render revision changes.
still, there's the problem of logically extracting moved blocks between
two revisions; that might be better supported by the HTML editor when the
user moves some HTML, and it would require some special purpose HTML to b=
e=20
generated to represent this movement. i'm not sure this is a vital featu=
re,
though.
bye,
--=20
Bj=F8rn Stabell <mailto::bjoerns@acm.org>
<http://www.cc.uit.no/~bjoerns/>
<fax:+4777644100>