CSS instead of frames (but how)?

[Len Philpot]

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.

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?

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.]

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.

 

[Len Philpot]

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]

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.

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 ;-)

 

[Jose]

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?

Jose

 

[Len Philpot]

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]

internet.ie...

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.

--

Curtis

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

 

[Spartanicus]

[framed nav section file]

What's one more file among 200 others?

A content fragment masquerading as a complete document.

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]

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.

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.

 

[Len Philpot]

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. <[email protected]>", 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.]

"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]

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.

 

[Jose]

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.

Jose

 

[Blinky the Shark]

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.

 

[Len Philpot]

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]

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]

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]

... 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.]

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]

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).