[l2h] Wrong TITLEs in frames' *_tf.html files, any fix available?
Uli Wortmann
Uli Wortmann <uliw@erdw.ethz.ch>
Tue, 18 May 1999 11:57:10 +0200
Hi Ros et al.
Ross> Thanks for the input Uli. I was hoping you would respond.
its always a pleasure ;-)
Ross> But putting a full URL in the <TITLE> is surely not the way
Ross> to do it.
granted
Ross> BTW, the structure of frame-documents produced by LaTeX2HTML
Ross> is currently:
Ross> <!DOCTYPE ....> <HTML> <FRAMESET ....> <FRAME....> ...
Ross> <NOFRAMES> <HEAD> ... </HEAD> <BODY> .... .... </BODY>
Ross> </NOFRAMES> </FRAMESET> </HTML>
Ross> <!DOCTYPE ....> <HTML> <HEAD> .... </HEAD> <FRAMESET ....>
Ross> <FRAME....> ... <NOFRAMES> <BODY> .... .... </BODY>
Ross> </NOFRAMES> </FRAMESET> </HTML>
ok, so you split the /head from /body and place /body in the /noframes
part. Not sure if do understand the consequences here. What does body
contain in the case of the standard frameset generated by l2h? isn't
it empty except for the content_node of the frameset? Or let me put it
the other way round: The placement of /body relative to /noframes only
matters to bots if there is any actual contents (i.e. other than
buttons) or links within.
>> There are several approaches to resolve this problem. E.g., we
>> might put the needed information in the Title attribute like
>>
>> a) Contents Frame of http://.../file_tf.html
Ross> Do you mean the ... to be replaced with the full URL ? If
Ross> so, then I say no --- too long. I'm sympathetic to leaving
Ross> the dots as is, so that a relative reference is implied; but
Ross> then why not just "Contents Frame of file_tf.html " ?
yes, a relative link named 'contents' would be ok. It would even be
sufficient to have it in a small font as last line on the page.
Ross> But even this doesn't give any indication of what the
Ross> contents are about, if you happened to link to this Frameset
Ross> page. Does this matter ? Why did an indexer find this page
Ross> and not file_tf.html itself ?
ok, back to the basic problem:
a) we have to have a scheme to deal with non-frame browsers, and b) we
need to take care of the way bots index such pages.
What I do know by now:
a) most bots simply ignore anything (including links) within the
/frame section
b) AFAIK the link provided by the bot cannot be
influenced. I.e. the bot always provides the link to the
file where he indexed the words.
To get at least basic bot-support, I used the NOFRAMES option, which
results however in every file of the frameset having the full document
in the /noframe section. Such I end up with bot entrys pointing to
file_mn.html or the like.
In my understanding it would be sufficient to have the document
content (and a /noframes section) only in file_tf.html. To keep the
bots going, the document internal links must however be changed from
pointing to file-node_mn.html to file-node_tf.html.
In such a setup, bots would be able to scan the whole document,
and non-frame browsers would work like expected.
Or is there anything I've overlooked?
>> b) Provide a link in any frame to the current tf_frame
Ross> Interesting idea. Where should it go, to not look offensive
Ross> when the view is already from the tf_frame ?
In case we need it, what about at the bottom of the page?
Ross> None taken ;-) ... but then it wouldn't be needing frame.pl
Ross> , would it ?
I was actually thinking of a tables_but_frames.pl which would do
without frames at all.
Ross> e.g. 1. <table> columns aren't resizable within the window,
Ross> the way frames are, to see more or less of a wide TOC or
Ross> Index, 2. there wouldn't be the ability to reduce the
Ross> 4-frame views to a 3-frame one.
ok, ok.
Ross> Is there a way to direct robots to indexing just the
Ross> file_tf.html ? Is this desirable ?
se above
Ross> Further comments welcome.
ditto, although I might be a bit slow in responding due to my lab
schedule.
Cheers
Uli
--
Uli Wortmann
Dept. of Geology Fax (Switzerland) (1) 632 1080
ETH-Zuerich Fon 3694
Visit the SPOC-team at http://www.spoc.ethz.ch