[Doc-SIG] Doc html Index only works with netscape

[Fetherston, Tom]

Hi,

I sent the folowing to the Pythonmac-sig, this might be a better place.:
----------------------------------------------------------------------------
-------------------------
Hi,

Not exactly an html list, but believe it or not this involves Python.  I
cam accross a program that would provide keyword look-ups into the Python
Html doc.  It came in too parts, a python program to parse the url's in the
genindex.html file (in the ref sub directory), it created a dictionary
(keyword : url), then it pickled that dictionary.

I updated it to use the 're' module and to handle the 2.0 doc's, instead of
pickling the dictionary, I have it write out a .tcl file, which when
sourced, provide a Tcl equivalent of the dictionary.  The second part of
this system was a elisp function to initiated a lookup from within emacs.

Noe, I changed this so command-double clicking a keyword in Alpha sends an
AppleEvent to a browser containg the Url.  Most of the urls contain
fragments (e.g. #12h-110) after the filename that are supposed to position
the relevant section in the browser for viewing, however, only Netscape
seems to accept this correctly.  ICab and IE just open the file at the top.
This is also what they do if you click the hyperlink in the index file.

!) Am I stuck with specifying Netscape as the only browser to use?

2) What is this fragment specifying?  My Html 4 ref book does not list this
kind of fragment, is it purely a Netscape extension?

Tom
---------------------------------
I got this as a reply:
-----------------------

hi-

I'm not convinced that I am really following you, but maybe this will 
help a little anyway. Generally, a url ending with # followed by a 
string is supposed to seek a named anchor, so #12h-110 would look for 
<a name="12h-110> in the target document. This works pretty much the 
same from one browser to another, so I don't think that's what's 
going on here. Another possibility is that this syntax is somehow 
being used to call the find() javascript function that is supported 
by Netscape but the last time I checked, was not supported by IE and 
probably isn't supported by iCab. This basically just triggers the 
find menu command, fills in the search string, and does the seek 
transparently once the entire target document is loaded.

So, that's my best guess and if it's correct, there's not much you 
can do but go in and hack together something in javascript that would 
trap for IE and maybe try to use textRange or something to emulate 
the find function.

Richard Gordon
--------------------

Is this right?  Seems more likely to be based on line numbers.  It does seem

to be specific to Netscape, why aren't the fragments consistent with more 
browsers?

Tom