Re: Client-side highlighting; tag proposal

   Date: Thu, 9 Mar 1995 23:17:30 +0500
   Originator: www-talk@mail.w3.org
   From: wa@mcc.com (Wayne Allen)
   X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
   X-Comment: To sign off, send mail to listproc@mail.w3.org with body DEL WWW-TALK


   Nick says...

      A couple of times lately, I've brought up the notion that clients should
      handle highlights (the terms that match a search query) better.  It's
      rather inefficient to force the search server to proxy documents just so
      that it can add highlights.  Worse, it takes the decision about *how* to
      highlight (bold?  underline?  surround with asterisks?) out of the user's
      hands (barring some sort of ugly protocol for telling the server).

      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 agree with Nick that clients should be able to highlight search
   results, but I suggest a simpler approach - when a server sends a
   response to a search (and only the server *really* knows when this
   is), it should send a keyword attribute in the HTML header, containing
   the terms it thinks are relevant to the results (which may not be all
   the terms specified.) Then the browser can (or not) implement a simple
   way to find and highlight the terms.  Most (all?) browsers can already
   search on text, so this is a very simple extension for them. It
   relieves the server of having to muck with the actual HTML text it
   sends, and uses existing mechanisms.

   Cheers!
   --
    wa | Wayne Allen, EINet - wa@einet.net
       | MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759
       | http://galaxy.einet.net/EINet/staff/wayne/wayne.html


I'm not entirely clear on what Nick is suggesting, so I'll give my
interpretation.  Reading the first
paragraph, cited above, it looks like he's suggesting that the server
mark up the documents with a highlight tag.  But later in his original
message, he suggests that the browser gets two pieces of information:
a URL and a set of highlight tags, from which it can derive
highlights.  This implies that his suggestion really is the same as
what Wayne outlines above. 

Given what (little) I know about Verity Topics, these highlight tags,
whether in an HTML header as Wayne suggests, or in a separate "query
result" document that Nick might be suggesting (if my understanding is
correct), would contain more than just the words to be highlighted.
They would also contains hints about where to locate the words in
the HTML documents, which in the case of VTK would be a word count.
Since the search engine has already done the work of locating words,
we might as well give the browser the opportunity to leverage that
work. 

I'd like to see a proposal/discussion of some standard locator hints
that different search engines might provide.  VTK might provide word
count, for example, where Fulcrum might provide character count
perhaps?  In any case, the search engine would provide whatever info
it can in some standard way, and browsers could use that to their
advantage. 

Something like:

<hl href=URL wordloc=WORDCOUNT charloc=CHARCOUNT>
This is the phrase found
</hl>
<hl href=URL2 wordloc=WORDCOUNT2 charloc=CHARCOUNT2>
This is another phrase found
</hl>

I don't even care if this is done through an HTML tag or not, as long
as there is some convention that browsers can use.

Bill O'Donnell                Prospect  Place
Interleaf Inc                 9 Hillside Ave
billo@ileaf.com               Waltham, MA 02154

Received on Friday, 10 March 1995 09:27:51 UTC