Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CSS instead of frames (but how)?

6 views
Skip to first unread message

Len Philpot

unread,
Dec 28, 2005, 9:21:49 PM12/28/05
to
No code written yet, but I'm trying to figure out how to replace the
functionality of a two-frame (nav/content) layout with CSS. I've heard
the objections to frames and although I've never personally had any
problems with them, I don't dismiss the validity of the arguments
against them. However, I like the idea of a unchanging, non-scrolling
nav bar to one side of the page, with the content free to do it's thing
on the other side (personal preference). I also like the idea of the nav
frame being one piece of code that's not repeated for each content file
that gets loaded.

So, how do I duplicate that with CSS?

Let's say I have two styles :

body
{
margin-left: 220px;
}

.nav
{
position: fixed;
top: 0px;
left: 0px;
width: 200px;
height: auto;
}

I've seen enough to know that in Firefox this will work. The nav-styled
content will stay static to the left while the rest of the <body> goes
on independently about its business to the right of it.

Good deal. Except it doesn't work in IE, which apparently doesn't
recognize 'fixed'. 'absolute', 'static', etc., etc., don't give the
desired results. Both parts scroll together, either side by side, or one
renders ahead of the other.

Also, even if I get this to work as desired, how do I populate 'nav' on
multiple pages from a single source, without using SSI (is it possible
with <object>)? The reason I say without SSI is that this is just a
hobby page and my ISP doesn't provide any SSI (nor Perl, JS, php, etc.)
for the defacto ("free") web hosting with standard accounts.

Can it be done?

Thanks.
--

-- Len Philpot -> l...@philpot.org <--
------ ><> -----> http://philpot.org/ <--

dorayme

unread,
Dec 28, 2005, 10:06:43 PM12/28/05
to
In article <MPG.1e1d043b6...@news.central.cox.net>,
Len Philpot <l...@philpot.org> wrote:

> No code written yet, but I'm trying to figure out how to replace the
> functionality of a two-frame (nav/content) layout with CSS.

What you want to know is how can you do without frames but keep
some of the great features of them. You can't satisfactorily as
you have discovered because of lack of browser support.

This is how I changed a framed site, I looked at what I had on
the left and put it on each of my pages and made it go to the
left! (you can use tables, or floats or whatever suits you).

There are more intelligent ways of doing this using "includes",
you will simply have to read up on this and especially follow the
posts on this group which regularly (and even right now) discuss
this. But unless your site is absolutely enormous, it won't kill
you to repeat a navigation column for each page to begin with
till you see how it all looks.

Given that a nav pane now scrolls, this might spur you to design
around it so that not too much is on each page or if there is a
lot, there are other means to get to the nav (you can
periodically include links to the top - in case the user does not
know about the home button on the keyboard).

You need to think about your content, how likely is it that
someone engrossed in something way down deep is wanting to see
the nav? Maybe - the strength of frames! But probably not as much
as you think.

Curtis

unread,
Dec 29, 2005, 3:21:12 AM12/29/05
to
Len Philpot <l...@philpot.org> wrote in message
news:MPG.1e1d043b6...@news.central.cox.net...

As I learn about HTML and CSS, including the antiframe
rhetoric one encounters, I am regularly surprised at how
many really solid, well-developed applications use frames.
Two notable recent examples are the admin section of
VBulletin, and the Horde webmail program.

I probably haven't heard all the arguments, but so far I'm
not persuaded that frames are Satan incarnate. I don't use
them, but I wouldn't be afraid to do so.

Not an answer to your question, I know, but there it is.

--

Curtis

Visit We the Thinking
www.wethethinking.com
An online magazine/forum
devoted to philosophical
thought.


Spartanicus

unread,
Dec 29, 2005, 4:23:09 AM12/29/05
to
Len Philpot <l...@philpot.org> wrote:

>No code written yet, but I'm trying to figure out how to replace the
>functionality of a two-frame (nav/content) layout with CSS. I've heard
>the objections to frames and although I've never personally had any
>problems with them, I don't dismiss the validity of the arguments
>against them. However, I like the idea of a unchanging, non-scrolling
>nav bar to one side of the page, with the content free to do it's thing
>on the other side (personal preference).

For a www site your personal preferences should be irrelevant, it should
be aimed at users.

>Except it doesn't work in IE, which apparently doesn't
>recognize 'fixed'. 'absolute', 'static', etc., etc., don't give the
>desired results. Both parts scroll together, either side by side, or one
>renders ahead of the other.

IE6 doesn't support position:fixed, JS hacks exist to emulate similar
functionality, but they are cumbersome to use (high CPU usage when
scrolling), and it's jerky.

>Also, even if I get this to work as desired, how do I populate 'nav' on
>multiple pages from a single source, without using SSI (is it possible
>with <object>)?

No. HTML embedded with an object element opens a new viewport inside an
existing document in which a complete HTML document should be loaded,
not a code fragment. Since it's an independent viewport, for example
clicking a link in that viewport will open inside that viewport, not the
parent viewport.

>The reason I say without SSI is that this is just a
>hobby page and my ISP doesn't provide any SSI (nor Perl, JS, php, etc.)
>for the defacto ("free") web hosting with standard accounts.

Then your options are:

a) Use a preprocessor
b) Use an editor with a good block S&R
c) Build your site locally from a database that generates static files

--
Spartanicus

Len Philpot

unread,
Dec 29, 2005, 8:11:06 AM12/29/05
to
In article
<3n97r1t0lsen99qpa...@news.spartanicus.utvinternet.ie>,
inv...@invalid.invalid says...

> >against them. However, I like the idea of a unchanging, non-scrolling
> >nav bar to one side of the page, with the content free to do it's thing
> >on the other side (personal preference).
>
> For a www site your personal preferences should be irrelevant, it should
> be aimed at users.

Well, that preference was stated from the viewpoint /as/ a user, not an
author. :-) I look at design decisions based on how I want it to
/operate/, not how I want the building process to go.

To me, a nav pane that out of sight is basically useless, since it
forces me to go to the browser controls anyway instead of using the
supplied page links.


> >Except it doesn't work in IE, which apparently doesn't
> >recognize 'fixed'. 'absolute', 'static', etc., etc., don't give the
> >desired results. Both parts scroll together, either side by side, or one
> >renders ahead of the other.
>
> IE6 doesn't support position:fixed, JS hacks exist to emulate similar
> functionality, but they are cumbersome to use (high CPU usage when
> scrolling), and it's jerky.

You mean "IE 7" ?


> No. HTML embedded with an object element opens a new viewport inside an
> existing document in which a complete HTML document should be loaded,
> not a code fragment. Since it's an independent viewport, for example
> clicking a link in that viewport will open inside that viewport, not the
> parent viewport.

OK. Thanks.


> >The reason I say without SSI is that this is just a
> >hobby page and my ISP doesn't provide any SSI (nor Perl, JS, php, etc.)
> >for the defacto ("free") web hosting with standard accounts.
>
> Then your options are:
>
> a) Use a preprocessor
> b) Use an editor with a good block S&R
> c) Build your site locally from a database that generates static files

...or to play devil's advocate :

d) Use frames

However, I'm still thinking about that. It's a tradeoff - If this were a
commercial site, the requirements would be a bit more stringent than for
a personal hobby site.

Len Philpot

unread,
Dec 29, 2005, 8:19:06 AM12/29/05
to
In article <dp06f...@news2.newsguy.com>, nos...@nohow.not says...

> I probably haven't heard all the arguments, but so far I'm
> not persuaded that frames are Satan incarnate. I don't use
> them, but I wouldn't be afraid to do so.

I'm kinda in the same position right now. It reminds me of the 'goto is
evil' arguments you hear. While I certainly don't advocate the careless
use of goto, it's a sharp tool and like all other tools, there is a
place to use it and a place to refrain from using it. You have to use it
without getting cut.

From what I've seen, I'd certainly avoid a site littered with numerous
frames, but there are offsetting factors such as making sure your
<noframes> tag is functional and offers access to the site, etc.

The SE issues are more difficult to avoid, but they're not as much of a
factor in what I'm going here. Still, I've not decided yet and would
like to look at the options. SSI looks like the best direction, if I
want to find a new host just for that.

From a design POV, I like sites in general that look and feel like a
piece of software rather than like a browser-oriented website (my
personal opinion is that while it's OK for web browsing, a web browser
makes for a terrible software interface). That's the direction I'd like
to head.

Thanks for the input.

Spartanicus

unread,
Dec 29, 2005, 8:58:34 AM12/29/05
to
Len Philpot <l...@philpot.org> wrote:

>> >against them. However, I like the idea of a unchanging, non-scrolling
>> >nav bar to one side of the page, with the content free to do it's thing
>> >on the other side (personal preference).
>>
>> For a www site your personal preferences should be irrelevant, it should
>> be aimed at users.
>
>Well, that preference was stated from the viewpoint /as/ a user

It's a mistake to assume that others like what you like, some may,
others will not. Establishing reliable numbers is rarely achievable,
typically you should strive for a situation where your choice causes the
least amount of difficulties for users who dislike your choice.

>To me, a nav pane that out of sight is basically useless, since it
>forces me to go to the browser controls anyway instead of using the
>supplied page links.

A choice for fixed navigation on the basis that you find it difficult to
hit the Home key or some other method to get to the top of a document is
not a good reason.

>> IE6 doesn't support position:fixed, JS hacks exist to emulate similar
>> functionality, but they are cumbersome to use (high CPU usage when
>> scrolling), and it's jerky.
>
>You mean "IE 7" ?

The Dean Edwards script "IE7" is one JS method (which also includes many
other hacks), there are other dedicated methods.

>> Then your options are:
>>
>> a) Use a preprocessor
>> b) Use an editor with a good block S&R
>> c) Build your site locally from a database that generates static files
>
>...or to play devil's advocate :
>
>d) Use frames
>
>However, I'm still thinking about that. It's a tradeoff - If this were a
>commercial site, the requirements would be a bit more stringent than for
>a personal hobby site.

As long as you are aware of the problems frames often cause, then it's
your choice. A few regulars in this group have pages on how to prevent
many of the problems that frames cause. Note that "doing frames
properly" usually causes a new problem: construction and maintenance
becomes a pig.

--
Spartanicus

dor...@optusnet.com.au

unread,
Dec 29, 2005, 6:38:12 PM12/29/05
to

Spartanicus wrote:
> Len Philpot <l...@philpot.org> wrote:
>

> >> For a www site your personal preferences should be irrelevant, it should
> >> be aimed at users.
> >
> >Well, that preference was stated from the viewpoint /as/ a user
>
> It's a mistake to assume that others like what you like, some may,
> others will not.

OP has already indicated that he meant that he has tried to look at it
from the users point of view.


>
> >To me, a nav pane that out of sight is basically useless, since it
> >forces me to go to the browser controls anyway instead of using the
> >supplied page links.
>
> A choice for fixed navigation on the basis that you find it difficult to
> hit the Home key or some other method to get to the top of a document is
> not a good reason.

This is not what the OP is saying or meaning. He is imagining it from
the point of view of the user. I don't know too many folk who know what
the home button is when it is at home. OP is perfectly right that it is
somewhat absurd that a nav pane scrolls away. This is the price one
pays for better overall "non-frames" technology. But this is a
different thing. The lack of a sense of absurdity comes from
familiarity. There is a deep sense in which a scrolling away main nav
is absurd. Face absurdity honestly and squarely. You can do it
Spartanicus! :)

dorayme

Len Philpot

unread,
Dec 29, 2005, 6:46:11 PM12/29/05
to
In article
<btp7r157oajibfa9c...@news.spartanicus.utvinternet.ie>,
inv...@invalid.invalid says...

> >> For a www site your personal preferences should be irrelevant, it should
> >> be aimed at users.
> >
> >Well, that preference was stated from the viewpoint /as/ a user
>
> It's a mistake to assume that others like what you like, some may,
> others will not. Establishing reliable numbers is rarely achievable,

That's true statistically half the time, I guess, unless there are
mitigating factors. It's equally a mistake to assume that others
/dislike/ what you like, but there's no point in debating this tit for
tat. :-)


> >To me, a nav pane that out of sight is basically useless, since it
> >forces me to go to the browser controls anyway instead of using the
> >supplied page links.
>
> A choice for fixed navigation on the basis that you find it difficult to
> hit the Home key or some other method to get to the top of a document is
> not a good reason.

Somewhere elsethread I mentioned that I like web pages that function
more "like software" than like a web page. I guess my idea with a nav
pane is to make it functionally "part of the browser" as much as
possible, instead of part of the site and keep the site contents
conceptually limited to the client area of the browser.

The other thing is the code duplication that comes into play.


> >However, I'm still thinking about that. It's a tradeoff - If this were a
> >commercial site, the requirements would be a bit more stringent than for
> >a personal hobby site.
>
> As long as you are aware of the problems frames often cause, then it's
> your choice. A few regulars in this group have pages on how to prevent
> many of the problems that frames cause. Note that "doing frames
> properly" usually causes a new problem: construction and maintenance
> becomes a pig.

Once again - If this were a commercial venture, I'd probably rule them
out entirely (and I'm not yet sure I won't), but I've yet to figure a
route to get their functionality any other way. I'm doing this as much
for the drill as for any other reason.

Thanks for the feedback.

Len Philpot

unread,
Dec 29, 2005, 6:50:31 PM12/29/05
to
In article <1135899492....@f14g2000cwb.googlegroups.com>,
dor...@optusnet.com.au says...

> the home button is when it is at home. OP is perfectly right that it is
> somewhat absurd that a nav pane scrolls away. This is the price one

I guess it's kind of like having the floor buttons in an elevator
mounted /outside/ of the door on the building's top floor only, with
only a button for the top floor inside the car ... :-)

Spartanicus

unread,
Dec 29, 2005, 7:13:14 PM12/29/05
to
Len Philpot <l...@philpot.org> wrote:

[frames]

>but I've yet to figure a route to get their functionality any other way.

You know how to fix parts to the viewport for standard compliant
browsers, you know the options for providing a fall back for the OS
component that tries to fool people into thinking that it's a web
browser, and you know how to include code.

What more do you need to figure out?

--
Spartanicus

Neredbojias

unread,
Dec 30, 2005, 7:44:26 AM12/30/05
to
With neither quill nor qualm, Len Philpot quothed:

> > As long as you are aware of the problems frames often cause, then it's
> > your choice. A few regulars in this group have pages on how to prevent
> > many of the problems that frames cause. Note that "doing frames
> > properly" usually causes a new problem: construction and maintenance
> > becomes a pig.
>
> Once again - If this were a commercial venture, I'd probably rule them
> out entirely (and I'm not yet sure I won't), but I've yet to figure a
> route to get their functionality any other way. I'm doing this as much
> for the drill as for any other reason.

I like frames for some functions but if the only thing you're looking
for is a static nav menu, you really don't need them at all. The
alternate options have already been much-discussed, if not in this
thread, in recent others.

--
Neredbojias
Contrary to popular belief, it is believable.

Len Philpot

unread,
Dec 30, 2005, 7:58:21 AM12/30/05
to
In article <ahu8r1d08268pmpvunbi05sjbhllv5e8a4
@news.spartanicus.utvinternet.ie>, inv...@invalid.invalid says...

> browsers, you know the options for providing a fall back for the OS
> component that tries to fool people into thinking that it's a web

Are you referring to IE?


> browser, and you know how to include code.

How? (see ** below, though for the conditions)


> What more do you need to figure out?

The way I see it, here's how it stands :

Frames CSS

Split view Yes Yes
Static/scrolling Yes Partially *
Single source Yes No **
Degrades OK Yes *** Yes

* IE doesn't support position: fixed, so that's an issue.
** That is, without scripting, SSI, etc.
*** Assuming sufficient info is included in <noframes>, which it is.

If I could fix * and **, then I see no reason to use frames. But,
another argument in favor of frames (which I personally don't care for,
but some users might) is that frames _can_ be made to be resizable.
Whether I'd actually do that is questionable... :-)

I don't want this to look like I'm trying to sell frames over CSS. That
would be absurd; however, given what I want to accomplish within the
restrictions I have to operate, I've not yet been able to do it purely
with CSS. I'll still /use/ CSS though, no doubt.

Spartanicus

unread,
Dec 30, 2005, 10:27:32 AM12/30/05
to
Len Philpot <l...@philpot.org> wrote:

>> browsers, you know the options for providing a fall back for the OS

>> component that tries to fool people into thinking that it's a web browser


>
>Are you referring to IE?

Obviously.

>> and you know how to include code.
>
>How? (see ** below, though for the conditions)

> ** That is, without scripting, SSI, etc.

Again: preprocessor, S&R, building static files locally using a
database.

>The way I see it, here's how it stands :
>
> Frames CSS
>
>Split view Yes Yes
>Static/scrolling Yes Partially *

You are blaming CSS for not providing fixed positioning, this is
nonsense, blame the OS component or provide a work around for IE using
another technology.

>Single source Yes No **

Frames using multiple source files.

>But,
>another argument in favor of frames (which I personally don't care for,
>but some users might) is that frames _can_ be made to be resizable.

If by that you mean that a user can resize a pane by dragging a border,
you can do that with CSS layouts to by using JS. But a CSS pane layout
that needs to be resized in that manner has been poorly constructed,
there should be no need for that. IIRC frames cannot be sized to scale
to the user's font setting which makes the option to drag frame borders
a necessity, fortunately CSS layouts can and should scale to the user's
font setting.

--
Spartanicus

Jonathan N. Little

unread,
Dec 30, 2005, 10:30:47 AM12/30/05
to
Len Philpot wrote:
> In article <ahu8r1d08268pmpvunbi05sjbhllv5e8a4
> @news.spartanicus.utvinternet.ie>, inv...@invalid.invalid says...
>
>
>>browsers, you know the options for providing a fall back for the OS
>>component that tries to fool people into thinking that it's a web
>
>
> Are you referring to IE?
>
>
>
>>browser, and you know how to include code.
>
>
> How? (see ** below, though for the conditions)
>
>
>
>>What more do you need to figure out?
>
>
> The way I see it, here's how it stands :
>
> Frames CSS
>
> Split view Yes Yes
> Static/scrolling Yes Partially *
> Single source Yes No **
> Degrades OK Yes *** Yes
<snip>

I went with JavaScript (for navbar position only) which most folk still
have enabled. If disable clicking liberally use 'up' buttons put the
menu at hand for gracefully degradation...and anyway isn't that what
JavaScript is for, control behavior for 'extra' but not 'essential'
aspects of the site?

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Curtis

unread,
Dec 30, 2005, 1:49:50 PM12/30/05
to
Len Philpot <l...@philpot.org> wrote in message
news:MPG.1e1d9e482...@news.central.cox.net...

Excellent analogy with the goto, Len.

Anotheris the notion that tables are evil, and that one
should stick to "pure" CSS to fashion pages. Admittedly I'm
on the rising side of the learning curve, but in trying to
achieve that I found 1) browser rendering consistency
insanely erratic, 2) overcoming this required patches and
kludges that made for some truly ugly code, and 3) many
really good online applications use tables for the
fundamental header/sidebar/footer structure. Finally I threw
in the towel and went with the simplest--tables--for the
structural backbone, and use CSS for the design elements
within those sections.

Agreed on the large qualitative difference between web pages
and desktop apps. That gap should have been bridged by Java
applets and Javascript, etc., , and has to some degree, but
the performance of both--or at least the usual
implementations of them--is often truly pathetic, entailing
long download times for 56K connections and sluggish or
memory-leaking performance once they're in local computer
memory. Not to mention that they too work on some browsers
and crash on others--some Javascripts fail on IE 5.0, for
example, but run OK on 5.5.

Len Philpot

unread,
Dec 30, 2005, 5:48:23 PM12/30/05
to
In article
<5ojar1tppbjd73hdh...@news.spartanicus.utvinternet.ie>,
inv...@invalid.invalid says...

> >How? (see ** below, though for the conditions)
>
> > ** That is, without scripting, SSI, etc.
>
> Again: preprocessor, S&R, building static files locally using a
> database.

Maybe I can approach it from the other end to clarify my constraints:
How to do it with _only_ (X)HTML and CSS. How's that?


> >The way I see it, here's how it stands :
> >
> > Frames CSS
> >
> >Split view Yes Yes
> >Static/scrolling Yes Partially *
>
> You are blaming CSS for not providing fixed positioning, this is
> nonsense, blame the OS component or provide a work around for IE using
> another technology.

Not at all - In fact, the part you snipped :

>> * IE doesn't support position: fixed, so that's an issue.

lays the blame, if you want to call it that, on IE and not on CSS. I've
personally stopped using IE, but I realize that most haven't, so I have
to at least consider its influence on things.


> >Single source Yes No **
>
> Frames using multiple source files.

Let's see - I can have the same nav code repeated x times for x pages
and have to manually update it each change, or I can (functionally)
"import" it once for the nav frame and that's it. Seems simpler to me,
aside from any other issues.


> >another argument in favor of frames (which I personally don't care for,
> >but some users might) is that frames _can_ be made to be resizable.
>
> If by that you mean that a user can resize a pane by dragging a border,
> you can do that with CSS layouts to by using JS. But a CSS pane layout
> that needs to be resized in that manner has been poorly constructed,
> there should be no need for that. IIRC frames cannot be sized to scale
> to the user's font setting which makes the option to drag frame borders
> a necessity, fortunately CSS layouts can and should scale to the user's
> font setting.

Doesn't giving the user the ability to resize the frame mesh with the
"what the designer wants isn't important, it what the user wants that's
important" philosophy? ;-) At any rate, I don't personally care for
resizable frames (which I stated).

It seems to me that we're getting into a "toma(y)to / toma(h)to"
discussion here that could end up generating more heat than light.

Len Philpot

unread,
Dec 30, 2005, 6:02:34 PM12/30/05
to
In article <dp3vn...@news2.newsguy.com>, nos...@nohow.not says...

> Anotheris the notion that tables are evil, and that one
> should stick to "pure" CSS to fashion pages. Admittedly I'm
> on the rising side of the learning curve, but in trying to

Same here, hence my questions. I don't see any reason to completely rule
out tables, just use them appropriately. If the data is tabular in
nature, then table it. If not and your design ends can be achieved with
styles, then style it. Typically, it might be both.

Little as I know, I've already reaped some "stylesheet rewards" when I
decided to make revisions after the fact. The biggest shift is simply
learning the interactions and techniques required to best achieve design
goals. Kind of like programming - Learning the grammar and vocabulary is
one thing, learning to program is another.


> fundamental header/sidebar/footer structure. Finally I threw
> in the towel and went with the simplest--tables--for the
> structural backbone, and use CSS for the design elements
> within those sections.

I'd surmise you've achieved 90% of what could realistically be done with
pure stylesheets with that approach, as long as you keep the "non-
skeletal" stylings in the CSS. I don't see how content and presentation
can be _completely_ and 100% divorced, anyway. One influences and
directs the other. It's an admirable goal, but I don't see it happening
100%. In my previous career (graphic design), I would have laughed at
anyone who told me to design a brochure (e.g.), but wouldn't provide any
details about what it was or whom it was for, saying rather, "Once
you're done, we'll just plug in the content." :-)

Now, creating an environment that's extensible, flexible and
accomodating to skinning, updating, etc., well that's another matter
entirely. Stylesheets and other more dynamic tools offer LOTS for that.


> Agreed on the large qualitative difference between web pages
> and desktop apps. That gap should have been bridged by Java

...and I'll admit that some of my approach is strongly influenced by my
"roots" in MS-DOS and administering Unix every day for the past six
years. I've come to appreciate the advantages of "a tool learned" as
opposed to "just click here and _everything_ will be all right...". :-)

Spartanicus

unread,
Dec 30, 2005, 6:44:21 PM12/30/05
to
Len Philpot <l...@philpot.org> wrote:

>> >How? (see ** below, though for the conditions)
>>
>> > ** That is, without scripting, SSI, etc.
>>
>> Again: preprocessor, S&R, building static files locally using a
>> database.
>
>Maybe I can approach it from the other end to clarify my constraints:
>How to do it with _only_ (X)HTML and CSS. How's that?

You say that you cannot figure out how to replicate the function of
frames and when you are told you reject it with an argument that amounts
to "but that's not how frames work". Frames are a fundamentally broken
concept, hence proper solutions should at best aim only to replace some
of the functionality of frames, *not* replicate the failures of the
frames concept.

>> >Single source Yes No **
>>
>> Frames using multiple source files.
>
>Let's see - I can have the same nav code repeated x times for x pages
>and have to manually update it each change, or I can (functionally)
>"import" it once for the nav frame and that's it.

The framed nav code is in a separate file: multiple source files.

>Seems simpler to me, aside from any other issues.

For the third time: preprocessor, S&R, building static files locally
using a database, only the last option is potentially more complicated
to use than using frames.

Btw, it's bad form to link to the active (target) page itself, so a
navbar should change from page to page by omitting the link to the
(target) page itself.

--
Spartanicus

Jose

unread,
Dec 30, 2005, 7:04:20 PM12/30/05
to
> At any rate, I don't personally care for
> resizable frames (which I stated).

Why?

What possible advantage is there in preventing the user from adapting
the display of your data to his needs (such as a narrower or wider
screen area than what you think he ought to have, or needing to keep
other windows open and visible while viewing your site?

Jose
--
You can choose whom to befriend, but you cannot choose whom to love.
for Email, make the obvious change in the address.

Len Philpot

unread,
Dec 30, 2005, 7:15:08 PM12/30/05
to
In article
<hufbr1hfl857d7ic1...@news.spartanicus.utvinternet.ie>,
inv...@invalid.invalid says...

> You say that you cannot figure out how to replicate the function of
> frames and when you are told you reject it with an argument that amounts
> to "but that's not how frames work". Frames are a fundamentally broken
> concept, hence proper solutions should at best aim only to replace some
> of the functionality of frames, *not* replicate the failures of the
> frames concept.

This is starting to remind me of some of the threads on c.l.c. from time
to time... ;-\

I don't want to replicate the _broken_ behavior of frames. I can easily
replace the broken parts of frames (SE following, etc.) with non-broken
CSS. However, one of the _non-broken_ fuctions is the ability to remain
static while other content scrolls. If that's my opinion (in your
opinion), then so be it. There's nothing inherently "broken" in that
[static/scrolling] concept just because someone arbitrarily decides it
is.


> >Let's see - I can have the same nav code repeated x times for x pages
> >and have to manually update it each change, or I can (functionally)
> >"import" it once for the nav frame and that's it.
>
> The framed nav code is in a separate file: multiple source files.

Yes, *one* separate file. Or should a C programmer maintain multiple
copies of stdio.h for each and every *.c module in which it's #included?


> >Seems simpler to me, aside from any other issues.
>
> For the third time: preprocessor, S&R, building static files locally
> using a database, only the last option is potentially more complicated
> to use than using frames.

And for the xth time, I don't have a database, preprocessor, SSI,
scripting nor anything else available to me *at my ISP* (regardless of
whatever I might install here locally). As I stated before, I'm
(voluntarily) working within the constraints of my ISP account. If this
were a (paid) commercial website, things would be different.


> Btw, it's bad form to link to the active (target) page itself, so a
> navbar should change from page to page by omitting the link to the
> (target) page itself.

Ideally, yes, but not a major infraction. Once again, this would matter
more if the nav panel changed from page to page. If it's static, then
technically /none/ of the links should be there, since they'll all be
redundant at some point in the experience. That would completely nullify
the usabilty for the nav panel at all...

Greg N.

unread,
Dec 30, 2005, 7:30:30 PM12/30/05
to
Len Philpot wrote:

> And for the xth time, I don't have a database, preprocessor, SSI,
> scripting nor anything else available to me *at my ISP* (regardless of
> whatever I might install here locally). As I stated before, I'm
> (voluntarily) working within the constraints of my ISP account.

Maybe we should explain what a preprocessor is.

It's a simple small utility on your _local_ computer. You create your
html files just as if they resided on an SSI capable server. For
example, instead of inserting the navigation section in each and every
html page, you just use an include statement where the nav section is
supposed to be inserted. You also isolate the nav section in a separate
HTML file.

Before you FTP you HTML to the server, you run your preprocessor which
interprets the include statements and inserts the _same_ nav section in
all your HTML files.

There are many such HTML preprocessors around, just google for them.

--
Gregor's Motorradreisen:
http://hothaus.de/greg-tour/

Len Philpot

unread,
Dec 30, 2005, 8:07:00 PM12/30/05
to
In article <dp4jf8$k0q$1...@online.de>, yodel...@yahoo.com says...

>
> There are many such HTML preprocessors around, just google for them.

My bad - I thought the reference was to either cpp or the unix m4 (pre)
processors. I'll check into it. From what you describe, the
functionality is like cpp, though.

Thanks.

Len Philpot

unread,
Dec 30, 2005, 8:14:30 PM12/30/05
to
In article <8Wjtf.478$xz....@newssvr17.news.prodigy.com>,
teac...@aol.nojunk.com says...

> > At any rate, I don't personally care for
> > resizable frames (which I stated).
>
> Why?
>
> What possible advantage is there in preventing the user from adapting
> the display of your data to his needs (such as a narrower or wider
> screen area than what you think he ought to have, or needing to keep
> other windows open and visible while viewing your site?

I was speaking from a /user/ standpoint (and personal preference).
Unfortunately, it's part of the design vs. usability tradeoff, just like
any other computer interface, I guess. After all, one of the most
flexible and powerful of user interfaces (the command line) is also the
least sexy and therefore, the least popular. :-)

Jake

unread,
Dec 30, 2005, 8:50:03 PM12/30/05
to
In message <dp06f...@news2.newsguy.com>, Curtis <nos...@nohow.not>
writes

Interesting. I was beginning to believe I was the only one who didn't
run and hide under the bed when I heard 'Frames' mentioned ;-)


>
>Not an answer to your question, I know, but there it is.
>
>--
>
>Curtis
>
>Visit We the Thinking
>www.wethethinking.com
>An online magazine/forum
>devoted to philosophical
>thought.
>
>
>
>

--
Jake (ja...@gododdin.demon.co.uk -- just a 'spam trap' mail address)

Jose

unread,
Dec 30, 2005, 9:44:16 PM12/30/05
to
> I was speaking from a /user/ standpoint

Ok, that's even more puzzling. What possible advantage is there for
you, /as a user/, to =not= be able to adapt a web page to your needs
(such as a narrower or wider screen area than what the webmaster thinks
you ought to have, or needing to keep other windows open and visible
while you surf the web?

Len Philpot

unread,
Dec 31, 2005, 12:02:02 AM12/31/05
to
In article <4gmtf.1241$6b3...@newssvr31.news.prodigy.com>,
teac...@aol.nojunk.com says...

> > I was speaking from a /user/ standpoint
>
> Ok, that's even more puzzling. What possible advantage is there for
> you, /as a user/, to =not= be able to adapt a web page to your needs
> (such as a narrower or wider screen area than what the webmaster thinks
> you ought to have, or needing to keep other windows open and visible
> while you surf the web?

It's partly visual and partly practical (or at least, a concession). I
like the look of two frames that meet without a border, but that's just
the visual. From a usage point of view, yes, sometime (only sometimes)
if I wanted to move a border, it might be nice. However, it will be
reset the next time I'm back, so I'll have to move it again. And again.
And again. Plus, gaining space on one frame is losing it on another, so
there's often a tradeoff. Generally, I'll just leave it alone. If I
really need the space, I'll just open the appropriate file in a full
screen window of its own. All in all, I rarely even touch those frames
that can be adjusted. If the settings could be saved, then that would be
another story, but as it is...

Plus, I use Firefox and am very accustomed now to tabbed browsing, so
there's little need to divvy up a given window - Just open it in another
tab.

Curtis

unread,
Dec 31, 2005, 12:27:40 AM12/31/05
to
Spartanicus <inv...@invalid.invalid> wrote in message
news:hufbr1hfl857d7ic1...@news.spartanicus.utv
internet.ie...

> >> >Single source Yes No **
> >>
> >> Frames using multiple source files.
> >
> >Let's see - I can have the same nav code repeated x times
for x pages
> >and have to manually update it each change, or I can
(functionally)
> >"import" it once for the nav frame and that's it.
>
> The framed nav code is in a separate file: multiple source
files.

What's one more file among 200 others?

In the CMSs I've been working with, and building templates
for, the theme/template/skin/style CSS is typically one of a
number of CSS files which may affect the look.

This may not sound ideal to someone who wishes to have a
single master CSS file that controls everything, but many
CSSs are extensible through "modules." It is not unusual to
include a small CSS file with each module to handle some
things not built into the master theme. This makes some
sense, otherwise someone might have to modify the theme CSS
every time a module is added.

The best designed themes seem to speak to elements
generically, but it is rare that we wish, for example, every
list or table in every functional block to look the same.
From the perspective of application design, that's a bad
idea--visual look-and-feel cues as to where we are--say
forum vs. whatever--are pretty helpful.


> Btw, it's bad form to link to the active (target) page
itself, so a
> navbar should change from page to page by omitting the
link to the
> (target) page itself.

I think that's a worthy goal, for the reason I just
mentioned. When the look of the nav sidebar doesn't change,
it can be confusing--particularly when the linked-to page
doesn't use the exact wording of the link as a headline.

It's actually rather surprising how many non-frame
applications fail to do this, though. But Horde webmail, for
example, uses frames and changes the links upon clicking
using Javascript.

I resist using Javascript wherever possible, of course, but
someday maybe soon it'll grow up.

Spartanicus

unread,
Dec 31, 2005, 4:17:09 AM12/31/05
to
"Curtis" <nos...@nohow.not> wrote:

[framed nav section file]

>What's one more file among 200 others?

A content fragment masquerading as a complete document.

>> Btw, it's bad form to link to the active (target) page
>itself, so a
>> navbar should change from page to page by omitting the
>link to the
>> (target) page itself.
>
>I think that's a worthy goal, for the reason I just
>mentioned. When the look of the nav sidebar doesn't change,
>it can be confusing--particularly when the linked-to page
>doesn't use the exact wording of the link as a headline.

I can't make out what you are (dis)agreeing with.

A nav bar should remain consistent and include the text of the active
page, just not linked, and preferably styled differently like in inverse
colour.

--
Spartanicus

Spartanicus

unread,
Dec 31, 2005, 4:21:53 AM12/31/05
to
Len Philpot <l...@philpot.org> wrote:

>> For the third time: preprocessor, S&R, building static files locally
>> using a database, only the last option is potentially more complicated
>> to use than using frames.
>
>And for the xth time, I don't have a database, preprocessor, SSI,
>scripting nor anything else available to me *at my ISP* (regardless of
>whatever I might install here locally).

All three mentioned solutions do not require any ISP support, they
work/run locally as per the constraint you previously stated.

>> Btw, it's bad form to link to the active (target) page itself, so a
>> navbar should change from page to page by omitting the link to the
>> (target) page itself.
>
>Ideally, yes, but not a major infraction. Once again, this would matter
>more if the nav panel changed from page to page. If it's static, then
>technically /none/ of the links should be there, since they'll all be
>redundant at some point in the experience. That would completely nullify
>the usabilty for the nav panel at all...

A Navbar should be coded for user convenience only, they should be
redundant in the sense that a site should be fully navigatable without
it. That however does not mean that it doesn't serve a function.

--
Spartanicus

Len Philpot

unread,
Dec 31, 2005, 8:57:30 AM12/31/05
to
In article
<e1jcr1t9tnfa8i7cr...@news.spartanicus.utvinternet.ie>,
inv...@invalid.invalid says...

> >And for the xth time, I don't have a database, preprocessor, SSI,
> >scripting nor anything else available to me *at my ISP* (regardless of
> >whatever I might install here locally).
>
> All three mentioned solutions do not require any ISP support, they
> work/run locally as per the constraint you previously stated.

As I stated in my reply to Greg N. <yodel...@yahoo.com>", I
misunderstood you to be referring to something else. I've Googled for
HTML preprocessors and came across a few.

"Orb" looked appropriate for what I need, but I only found C++ source
(other than a DOS binary). A quick attempt late last night was unable to
get it to build on my platform here at home (Win32, using Dev-C++, DMC
or VC++ 2003).

I downloaded "PPWizard", which looked promising until I ran it... It's
coded in REXX and is so slow as to be unusable. This is not a
perjorative, just accurate in my case unless there's another way to use
it. I work in an 'edit/save/refresh_browser' cycle, which would now need
to be 'edit/save/pre-process/refresh_browser' whenever I want to see
what I've done. As a test, PPWizard took almost 30 seconds to process
only 112 lines of HTML with no substitutions or changes at all. Having
to wait that long just to see the effect of a (minor) code change is
unrealistic.

There's one other one that's a Perl package I'll give a shot today.
Maybe it will be faster. Ideally I'd like something I can wrap in a
script or batch file to be called from my editor.

Greg N.

unread,
Dec 31, 2005, 9:10:48 AM12/31/05
to
Len Philpot wrote:

> "Orb" looked appropriate for what I need, but I only found C++ source
> (other than a DOS binary).

What's wrong with a DOS binary? Shouldn't that run just fine on the
command prompt?

Spartanicus

unread,
Dec 31, 2005, 10:08:48 AM12/31/05
to
Len Philpot <l...@philpot.org> wrote:

>I work in an 'edit/save/refresh_browser' cycle, which would now need
>to be 'edit/save/pre-process/refresh_browser' whenever I want to see
>what I've done.

Authoring packages that can use a templating system work effectively as
a database driven system without the need to install, or know how to
operate a database system. Afaik Dreamweaver and Frontpage feature such
a templating system. This should eliminate the need to insert a "run the
preprocessor" in the cycle. Afaik the authoring package keeps track of
files that are updated, any files that depend on these files are then
also automatically updated.

Although running the preprocessor should be as easy as pie.

--
Spartanicus

Jose

unread,
Dec 31, 2005, 12:07:55 PM12/31/05
to
> It's partly visual and partly practical

Ok, practical first.

> From a usage point of view, yes, sometime (only sometimes)

> if I wanted to move a border, it might be nice...

... and what advantage is there to you, if the web designer decided that
you should not be able to move that border, and therefore had to
horizontal-scroll for every line of text you read? And just because you
(one user) don't mind this, that doesn't mean that other users (of which
there could be thousands) wouldn't appreciate the ability. This is
especially true when the user needs to increase the font size, and
therefore needs more room on the pane of interest). Of course there is
a tradeoff, what is the advantage (to the user) of not letting the user
make that tradeoff?

As for tabbed browsing as a substitute for the ability to resize frames,
one still cannot see both tabs at once, nor can you see your spreadsheet
at the same time as a web page on limited screen real estate if you
can't resize gracefully, which includes resizing frames.

Now for the visual aspect - it is a flawed premise that web sites should
be designed visually. It's an attractive premise to clients, who think
that users all have (or should have) a 21 inch monitor completely
devoted to their web site, but unless the client is going to follow the
user around with an appropriate piece of hardware to play their website
on, graphic design gets in the way. (and if the client =does= follow
the user around, the client gets in the way. :)

To repeat what others must have said many times:
The designer has no control over...
1: the size of the user's screen.
2: the other work the user is doing at the time.
3: the visual acuity of the user
4: the information the user is actually seeking (which is often
different from what the client wants the user to seek)
5: the bandwidth of the user's connection
6: the speed or bugginess of the user's hardware
7: the present load on the user's machine
and many other factors that contribute to the usability of a site.
Removing the ability for the user to compensate for any of this by
resizing windows or frames (or any other way) is an act of contempt for
the user.

Blinky the Shark

unread,
Dec 31, 2005, 2:54:31 PM12/31/05
to
Len Philpot wrote:

> And for the xth time, I don't have a database, preprocessor, SSI,
> scripting nor anything else available to me *at my ISP* (regardless of
> whatever I might install here locally). As I stated before, I'm
> (voluntarily) working within the constraints of my ISP account. If this
> were a (paid) commercial website, things would be different.

Perhaps, since you're not finding the answers you are looking for, it's
time to (voluntarily) upgrade from the freebie ISP webspace.


--
Blinky
Killfiling all posts from Google Groups
Details: http://blinkynet.net/comp/uip5.html

Len Philpot

unread,
Dec 31, 2005, 6:11:58 PM12/31/05
to
In article <pan.2005.12.31....@thurston.blinkynet.net>,
no....@box.invalid says...

> Perhaps, since you're not finding the answers you are looking for, it's
> time to (voluntarily) upgrade from the freebie ISP webspace.

At the moment, what I'm doing is for my own edification. If I get
sufficient need (not to mention, some quality content), then I may well
look beyond the defaults.

Len Philpot

unread,
Dec 31, 2005, 6:15:49 PM12/31/05
to
In article <dp63h9$6qd$1...@online.de>, yodel...@yahoo.com says...

> Len Philpot wrote:
>
> > "Orb" looked appropriate for what I need, but I only found C++ source
> > (other than a DOS binary).
>
> What's wrong with a DOS binary? Shouldn't that run just fine on the
> command prompt?

True - And I may give it a try, but my file name aren't all 8.3. I guess
if I'm scripting it, I could also have it rename the files. Sounds like
a job for Perl.

Len Philpot

unread,
Dec 31, 2005, 6:17:59 PM12/31/05
to
In article
<lq6dr11dnvd7bghfo...@news.spartanicus.utvinternet.ie>,
inv...@invalid.invalid says...

> Authoring packages that can use a templating system work effectively as
> a database driven system without the need to install, or know how to
> operate a database system. Afaik Dreamweaver and Frontpage feature such

Right now, I can't justify dropping $$$ on a package like those. Plus, I
want to write the code for the educational value.


> Although running the preprocessor should be as easy as pie.

Oh, it is. It's just that waiting 30 seconds at a minimum every time I
want to see a change I've made will get old fast. I'm going to keep
looking for an alternative. I've known of REXX for years, but just
didn't realize it was that slow.

Len Philpot

unread,
Dec 31, 2005, 6:40:32 PM12/31/05
to
In article <LVytf.5302$nA2....@newssvr22.news.prodigy.net>,
teac...@aol.nojunk.com says...

> ... and what advantage is there to you, if the web designer decided that
> you should not be able to move that border, and therefore had to
> horizontal-scroll for every line of text you read? And just because you
> (one user) don't mind this, that doesn't mean that other users (of which
> there could be thousands) wouldn't appreciate the ability. This is

Or vice-versa.


> especially true when the user needs to increase the font size, and
> therefore needs more room on the pane of interest). Of course there is
> a tradeoff, what is the advantage (to the user) of not letting the user
> make that tradeoff?

Design of any kind involves /many/ tradeoffs. There are extremes - From
very pretty but useless, to functional but ugly. I shoot for somewhere
in the middle. (at least some) Assumptions must be made, so I pick
reasonable defaults.

At work, we have about 1300 users on our network. That's a reasonable
sample, ranging from teenagers to retirement age. The _vast_ majority of
them are just fine with 11pt text at 1024x768 on 17" CRT monitors. A few
use smaller fonts, others larger. More than a few use the same settings
on small laptops and even 15" CRT monitors. In the absence of compelling
evidence to the contrary, I see no reason to go (excessively) out of my
way for 3% of the market. Note that I'm not saying I won't make
resonable efforts, but making a website with all the personality of a
legal brief isn't what I'm interested in doing.

I'll choose reasonable defaults and keep from extremes.


> As for tabbed browsing as a substitute for the ability to resize frames,
> one still cannot see both tabs at once, nor can you see your spreadsheet
> at the same time as a web page on limited screen real estate if you
> can't resize gracefully, which includes resizing frames.

See my last sentence above - There's no way to anticipate and allow for
/every/ circumstance.


> Now for the visual aspect - it is a flawed premise that web sites should
> be designed visually. It's an attractive premise to clients, who think
> that users all have (or should have) a 21 inch monitor completely
> devoted to their web site, but unless the client is going to follow the
> user around with an appropriate piece of hardware to play their website

Who said anything about assuming a 21" display?

Whether or not you agree, the web *is* a visual medium (in addition to
whatever else it may be). If you choose not to design visually, you're
still making the choice to design visually, albeit just badly. Good
design doesn't have to involve lots of graphics nor whiz band effects. I
tend to go for 'less is more', but I do like something more than 12pt
Times Roman on a white background. From a functionality standpoint, IMO,
nothing is very functional about a bland website.


> To repeat what others must have said many times:
> The designer has no control over...
> 1: the size of the user's screen.
> 2: the other work the user is doing at the time.
> 3: the visual acuity of the user
> 4: the information the user is actually seeking (which is often
> different from what the client wants the user to seek)
> 5: the bandwidth of the user's connection
> 6: the speed or bugginess of the user's hardware
> 7: the present load on the user's machine

And to repeat what I said above, choose reasonable defaults and keep
from extremes.


> and many other factors that contribute to the usability of a site.
> Removing the ability for the user to compensate for any of this by
> resizing windows or frames (or any other way) is an act of contempt for
> the user.

I thought frames were evil? Sounds like you're promoting them. :-)

(my last $0.02 on this aspect of the topic, since it seems to have come
down to a matter of opinion and how trade-offs are divided up)

Greg N.

unread,
Jan 1, 2006, 7:30:40 AM1/1/06
to
Len Philpot wrote:

> At work, we have about 1300 users ... The _vast_ majority of
> them are just fine with 11pt text...

> I see no reason to go (excessively) out of my
> way for 3% of the market.

I'd think 3% is an entirely unfounded assumption. My unfounded
assumption is 20%.

But the point is, design for accessability, that is catering for the
needs of the (however slightly) handicapped , is always something the
majority can do without.

Your position is pretty much like saying, "The vast majority is just
fine without a wheelchair ramp at the city hall entrance, hence I see no
reason to put one there."

Len Philpot

unread,
Jan 1, 2006, 9:31:58 AM1/1/06
to
In article <dp8i1h$o8v$1...@online.de>, yodel...@yahoo.com says...

> > I see no reason to go (excessively) out of my
> > way for 3% of the market.
>
> I'd think 3% is an entirely unfounded assumption. My unfounded
> assumption is 20%.

3% was a guess - It may be more, but I'd be surprised at 20%, just the
same.


> Your position is pretty much like saying, "The vast majority is just
> fine without a wheelchair ramp at the city hall entrance, hence I see no
> reason to put one there."

I didn't say there wouldn't be /any/ adjustment nor allowance :

"> > I see no reason to go (excessively) out of my way"

^^^^^^^^^^^

Besides, all this is getter rather theoretical given that I'm /not/
designing a general-public type of website (in fact, it may never see
the light of day).
--

-- Len Philpot -> l...@philpot.org <--

Jonathan N. Little

unread,
Jan 1, 2006, 10:12:06 AM1/1/06
to
Len Philpot wrote:
> In article <dp8i1h$o8v$1...@online.de>, yodel...@yahoo.com says...
>
>
>>>I see no reason to go (excessively) out of my
>>>way for 3% of the market.
>>
>>I'd think 3% is an entirely unfounded assumption. My unfounded
>>assumption is 20%.
>
>
> 3% was a guess - It may be more, but I'd be surprised at 20%, just the
> same.
<snip>

Well for my website for Dec 2005 is was MSIE 68.8%
Netscape|Mozilla|Firefox 19.5% the rest bots|Opera|Old version 4
browsers and MSIE has been falling over 2 years

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Len Philpot

unread,
Jan 1, 2006, 10:26:53 AM1/1/06
to
In article <43b8b5a7$0$3266$cb0e...@news.centralva.net>,
lws...@centralva.net says...

> > 3% was a guess - It may be more, but I'd be surprised at 20%, just the
> > same.
> <snip>
>
> Well for my website for Dec 2005 is was MSIE 68.8%
> Netscape|Mozilla|Firefox 19.5% the rest bots|Opera|Old version 4
> browsers and MSIE has been falling over 2 years

That's interesting, although my percentage was a guess at the number of
users who need beyond-the-ordinary design considerations rather than
browser type. However, an interesting stat nonetheless.

Thanks.

Jonathan N. Little

unread,
Jan 1, 2006, 11:50:21 AM1/1/06
to
Len Philpot wrote:

> In article <43b8b5a7$0$3266$cb0e...@news.centralva.net>,
> lws...@centralva.net says...
>
>
>>>3% was a guess - It may be more, but I'd be surprised at 20%, just the
>>>same.
>>
>><snip>
>>
>>Well for my website for Dec 2005 is was MSIE 68.8%
>>Netscape|Mozilla|Firefox 19.5% the rest bots|Opera|Old version 4
>>browsers and MSIE has been falling over 2 years
>
>
> That's interesting, although my percentage was a guess at the number of
> users who need beyond-the-ordinary design considerations rather than
> browser type. However, an interesting stat nonetheless.

Sorry must reread this long thread...I thought your comments where in
justifying coding for a specific browser as opposed to the standard
where design/user flexibility is stressed.

For 'special needs' formatting I believe your main content should be
legible withing a reasonable about of font scaling. Decorative
non-essential bits can have fixed font sizes. Images should be optimized
to allow dial-up access and all should degrade gracefully if pluggins or
scripting is unavailable. Should be readable to text-only, but
contingent on sites purpose, example mine is navigable in Lynx, but
being an art site but without images there is not much incentive for
someone to visit! Political correctness aside, photographs are not much
use to the blind. So what you compromise in your site access and design
must depend on content. I do not believe there is a one-size-fits-all
rule concerning this.

Jose

unread,
Jan 1, 2006, 12:04:43 PM1/1/06
to
>>... and what advantage is there to you, if the web designer decided that
>> you should not be able to move that border, and therefore had to
>> horizontal-scroll for every line of text you read? And just because you
>> (one user) don't mind this, that doesn't mean that other users (of which
>> there could be thousands) wouldn't appreciate the ability. This is
>
> Or vice-versa.

No, not vice-versa. Choosing not to use a feature is not the same as
preventing other people from doing so.

Yes, there are tradeoffs, and since I don't design frames I don't know
what the effort involved at allowing them to resize is. I assumed (like
modal dialog boxes) that it's simple.
Resize? [Yes|No]
If it requires lots of coding, then I see your point.

> I thought frames were evil? Sounds like you're promoting them. :-)

I had not posted an opinion on frames per se. (As a user I find well
designed frames to be useful for what the web designer will let you do,
but very frustrating if you want to do anything else)

0 new messages