Re: Client-side highlighting; tag proposal

>We'd like to suggest a very simple approach -- a highlight tag.  This way,
>our server could add the highlight tag in the appropriate places, but it
>would be up to the browser (under the user's control, presumably) to decide
>how to identify highlights in the text (turn them red, underline,
>whatever).  An appropriate UI enhancement would be the addition of a "next
>highlight" button or menu item and optionally a "previous highlight"
>button.

I guess I am a strong proponent of "clean" SGML, but I must admit,
that having some way to mark highlights would be very
desireable. DynaWeb has fairly sophisticated searching capabilities
(cross collection, boolean, proximity, structure-based, etc.) and
I used the <B> tag for highlighting the hits.

This has 2 major problems:

1) If DynaWeb highlights something already in <B>, you can't see it.
2) Even in plain text, it can be hard to see.

One problem with the tag approach is that we face a problem when a hit
crosses element boundaries. This is not too much of a problem in
DynaWeb *now* because most of it's tagging in the SGML to HTML
conversion process is based on containers, but as HTML becomes more
complicated, and more structured, it will become easier and easier to
generate bad SGML.

Again, like the anchor that crosses element boundaries (that Dan
mentioned) we have a problems, and I do not think start/end tag pairs
solve the problem in an elegant manner. Some parts of the HyTime
spec might be better, or concepts from it anyway.

Received on Friday, 10 March 1995 09:14:23 UTC