html frames question

Peter plp-ysDPMY98cNQDDBjDh4tngg at public.gmane.org
Mon May 22 15:58:19 UTC 2006


On Mon, 22 May 2006, Chris F.A. Johnson wrote:

> On Mon, 22 May 2006, Peter wrote:
>
>> Speaking of which, in your site, if I hover over the line 'Brother DCP310' 
>> which is the longest, the line expands and contracts cyclically (the 
>> writing moves out from under the pointer when it expands, then it 
>> contracts, etc).
>
>   That's caused by the addition of a border in the stylesheet:
>
> a:hover {
> 	color: #00f;
> 	background: fff;
> 	border: 2px solid #fff;
> 		}
>
>> This causes the bottom of the selector to also move up and down. If this 
>> selector would be a frame pane then the frame would constrain it. This is 
>> my problem. I cannot tell the frame what size it will be without describing 
>> ALL distances (including fonts etc) in pixels. That would be a bear.
>
>    Specifiying absolute sizes is the most frequent cause of broken
>    HTML pages.

That's why I am trying to avoid it. With a dodgy combination of frame 
size given in pixels, percent and *, and a fairly strict definition of 
the elements in my pane, I get reasonable results in *either* Firefox 
*or* Opera, but not both. Maybe I will code a redirect based on browser 
id and serve different framesets by browser. The damning thing is that 
after I set it up and manage to render it it behaves normally and I can 
resize the page and it stays the way it should.

E.g. in TCL I can tell a frame contents to be sticky to the frame from 
the inside and then let the packer figure the frame size, as long as 
there is at least one 'auto' element in the frameset that can accomodate 
the stretch. In HTML I see no way of doing that.

Apparently it is possible to set the frame size using Javascript after 
loading it. So I could try to *measure* the height and width of the 
outermost element in my frame after it is loaded, and resize the frame 
to fit. Of course this sucks. Why can't the broswser do it for me ?

The way I see it, if a frameset is specified with, say, *,*,* then the 
browser should render the contents into each, measure the bounding box 
when finished, and resize the frame to suit, for each frame. Why must I 
do this ? Or, provide a magic 'size' for frames called bb (for bounding 
box). Or follow the good example set by tk and use 'sticky' attributes 
like 'nsew' to tell the browser which sides of the frame are to fit the 
bb of the contents, and 'fill' attributes like 'xy' to tell it to 
stretch the contents. I think that the current placement algorythm for 
frames in html is braindead. I can understand why people moved away from 
frames.

What I do not understand, is why the already 10 year old mechanism 
implemented in the tk managers was not implemented ?! It was free ?!!! 
In 1990 even !!!

Peter
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list