Top frame gets chopped off

[Bob Richardson]

My web has a left frame (with a fixed width), and top frame(with a fixed
height) and a bottom right frame.

The top frame has three rows in a table. One user (so far) has reported that
one-half of the third row has been "chopped off" (covered up) by the
bottom-right frame. She uses IE 6.0 and 1024 screen resolution. (the same as
I do).

What could cause this situation?

 

[MD Websunlimited]

URL please?

 

[Bob Richardson]

http://www.writeonwhidbey.org/2005_Conference/2005_Conf_Home.htm

I can only guess that she reduced the width of her browser so much, that it
force the rows to display in two lines. Is there a good way to "require" a
minimum width, in order to prevent that?

 

[Stefan B Rusynko]

You have 2 out of 3 frames set to noresize, so user at less than 800x600 will have problems
<frame name="left" scrolling="auto" noresize target="rtop" src="../TOC.htm">
<frameset rows="99,*">
<frame name="rtop" target="rbottom" src="2005_Conf_Header.htm" scrolling="no" noresize>




"Bob Richardson" <bobr at whidbey dot com> wrote in message | http://www.writeonwhidbey.org/2005_Conference/2005_Conf_Home.htm
|
| I can only guess that she reduced the width of her browser so much, that it
| force the rows to display in two lines. Is there a good way to "require" a
| minimum width, in order to prevent that?
|
| | > URL please?
| >
| > --
| > Mike -- FrontPage MVP '97-'02
| > J-Bots 2004 Released Special Pricing
| > http://www.websunlimited.com
| > FrontPage Add-ins Since '97 FP 2003 / 2002 / 2000 Compatible
| >
| > "Bob Richardson" <bobr at whidbey dot com> wrote in message
| > | >> My web has a left frame (with a fixed width), and top frame(with a fixed
| >> height) and a bottom right frame.
| >>
| >> The top frame has three rows in a table. One user (so far) has reported
| >> that
| >> one-half of the third row has been "chopped off" (covered up) by the
| >> bottom-right frame. She uses IE 6.0 and 1024 screen resolution. (the same
| >> as
| >> I do).
| >>
| >> What could cause this situation?
| >>
| >>
| >>
| >
| >
|
|

 

[Murray]

Stefan:

Check your reference on NORESIZE. That's not what that attribute does at
all. It prevents you from manually resizing frames by dragging the border
between them (assuming there *is* a border). It's a very confusing
nomenclature to be sure. Noresize has nothing to do with how the frames
adapt to the browsers viewport size.

Here is the code on that frameset page -

<frameset cols="150,*" framespacing="0" border="0" frameborder="0">
<frame name="left" scrolling="auto" noresize target="rtop"
src="../TOC.htm">
<frameset rows="99,*">
<frame name="rtop" target="rbottom" src="2005_Conf_Header.htm"
scrolling="no" noresize>
<frame name="rbottom" src="2005_Conf_body.htm" target="_self"
scrolling="auto" marginwidth="20" marginheight="10">
</frameset>

You will note that you can change your browser viewport until you are blue
in the face, and there will still be 3 frames.

Bob:

I think you will have to request a screenshot from this individual. That
frameset will retain its dimensions on the top and the left frame until the
browser viewport reaches 150 pixels width, or 99 pixels height.

 

[Bob Richardson]

I will try to get a screenshot.

From my testing, the only time I would have a problem is when the width of
the browser viewport (new word for me) was shrunk down so far, that it
forced some of the table cells to use 2 lines. I thought that perhaps a
work-around would be to somehow force the cells with 2 or more words in them
to stay on one line. Is that an option?

 

[Murray]

Is that an option?

Perhaps, but I think it's an impractical one. To make that happen, the
viewport has to be <544px wide. I don't think you need to worry about this.
HOWEVER, if I resize to LARGEST text size in the browser, and make the
viewport about 690px wide (not counting the scrollbar's width), the three
left options on the top menu DO wrap below the frame border (the words
Lodging, Contest, and Volunteers all drop below). The top line words
(Registration, Program, Presenters) are still there, as are the links, so I
don't think that is such a problem either. Of course, it goes without
saying that you wouldn't be having this problem on a non-framed page (and
there are tons of reasons to consider that)....

 

[Bob Richardson]

I keep struggling with the frames vs. no-frames decision. I'll certainly
throw this problem on the increasing pile of frames hassles. Meanwhile, I'll
have to see what's going on with this user.

 

[Murray]

Bob:

It's an easy struggle, in my opinion. Read this -

http://apptools.com/rants/framesevil.php

 

[Bob Richardson]

As you suspected, I discovered that her web browser had been set to LARGEST
text size. She was happy to learn about the smaller text options. Is this
only an issue for framed pages, or are there similar problems (with users
who have selected the largest text option) in non-framed pages?

 

[Murray]

It's endemic to web pages. All developers need to be concerned about what
happens to their pages when visitors resize the text. Most pages on the web
die a horrible death when you do this, but not all. See, for example, the
pages at http://www.csszengarden.com ....

 

[Bob Richardson]

WOW. Got me excited about CSS. I see the light

 

[Murray]

Amazing stuff. Really amazing....

--
Murray

WOW. Got me excited about CSS. I see the light