When frames aren't evil

Neal <ne*****@yahoo.com> wrote:

> position:fixed is more broken than frames in a lot of cases, since
> part of the block will be hidden if the view port is too small.

Isn't this the job of overflow: auto.

Where shall the content overflow to? The taskbar?

It seems that you are confused about what overflow:auto does (or is
supposed to do).

Not really. I'm confused as to why anyone who has tried it would imagine
overflow would mean a damn to a fixed position element. Fixed positioning
does not imply scrollbars, nor would any positioning setting.

I'm afraid you've lost me. I thought you were objecting to css frame
emulation layouts that use position:fixed on an element like a navbar to
get it to stay in place whilst the main content scrolls because it can
obscure content in that fixed element if the viewport isn't large enough
to display it.

This can be solved by setting overflow:auto, it will produce a scrollbar
if (and only if) the viewport can't accommodate the content:
http://www.spartanicus.utvinternet.ie/test/neal.htm

--
Spartanicus

Jul 23 '05 #52

jake

In message <DT*****************@news-server.bigpond.net.au>, Lachlan
Hunt <la**********@lachy.id.au.invalid> writes

Neal wrote:
As you all are among the sharpest pencils in the bag, let me ask: Do
you know of a site which uses frames in an appropriate way? Where s
it, and why do you think it's acceptable?

Java documentation [1] is the best example I can think of. They
provide reasonalbe alternate content, and provide links for the user to
choose to navigate without frames. It's very useful having the
navigation panes split into packages and classes because it means that
the long list of classes and packages are always available without
having to download them each time. Of course I'm sure there are people
who hate frames no matter what, but I think this is one application of
them where it actually enhances the usability.

[1] http://java.sun.com/j2se/1.4.2/docs/api/

That's one of the classic uses for a framed site .... ease of random
access to information.

Regards.
--
Jake

Jul 23 '05 #53

On Sat, 28 Aug 2004, Neal wrote:

Either they are part of the HTML set because the W3C approved of their
inclusion - meaning there is seemingly a good reason for their existence
according to the W3C - or they are there due to everyone lookin the other way
- meaning there is a good reason for their existence according to Netscape.

Look at the stated aims of HTML3.2; even without knowing the inside
story, they pretty much speak for themself. They weren't any kind of
attempt to steer HTML into the future - but rather, to set down a
documented interworking specification which covered the common
features of what the widely-available web browsers were, de facto,
doing at the time.

As such, they codified specifications for some things which the
theorists would have preferred were not in there at all - or rather,
were delegated to presentation suggestions in a stylesheet of some
kind. That line of argument then came to actual expression later, in
the strict variant of HTML4.

So you have to interpret HTML3.2's codification of Frames in that
general, ahem, "framework" of HTML/3.2's formulation.

I'd suggest there was an awareness in the W3C that if they had
published HTML/4 Strict alongside a version of CSS - as quite a few of
their theorists might have favoured - and made that into their
then-current recommendation, instead of the mess that emerged as 3.2,
many of their *users* - no matter how well-founded the principles -
would have concluded that the W3C had lost all contact with reality.
The W3C did what they perceived to be politically acceptable at that
time - for all that many of us who were around at that time were
deeply disappointed with 3.2. But one should not by any means
interpret it as an "ex cathedra" endorsement of frames by the W3C.

best regards

Jul 23 '05 #54

On Sat, 28 Aug 2004, Andrew Fedoniouk wrote:

Lets think about web sites as about applications and
HTML as UI layout declartive language.
Let's not. Or rather, let's recognise that those situations are
quite special, and don't help to throw light on how to produce
well-engineered web pages for the WWW.
(I think such assumptions are reasonable this day)
Why? I'd say the developments of HTML as a pseudo application
development language is one of the lame branches of HTML that went
nowhere.
Lets say you would like to design UI of Mozilla browser.
Commendable aim, for a browser developer. Then you'd be on a browsers
development newsgroup - not one which deals with the design of web
pages for the WWW.
Without frames you will create one page with menu, toolbars, other stuff
and content of the page being browsed.
Imaginable?
So, on your planet, every web site will have its own - different -
user interface? No thanks - except for some specialised situations
where the web page is acting as a custom interface to some underlying
application.
There is a natural limitation on how many elements one document can
have: 2000 positioned simple DIVs will kill all modern UA (or make
them irresponsive).

"So don't do that". Concentrate on making well-structured web pages,
and leave browser interface design to browser interface designers.

Or at least recognise that your specialised application interface is
not suitable as a general paradigm for web page design.

Jul 23 '05 #55

Brian

Spartanicus wrote:

Brian wrote:
Frames were introduced in the HTML 4.0 spec,

Frames were introduced before 4.0, by a couple of years! That was
the point I made to Neal.

Actually you claimed that the specs are there to justify what is
being used in the wild.

What I wrote was that <frames> preceded their introduction into the
spec. I see no content difference in what I wrote and what you just replied.

Both <img> and <frame> have been discussed in ciwa* on numerous
occasions. I don't have time to search for the threads, but you can
always Google the group for them.

Unattributed sources recalled from memory, that puts your comments in
the right category.

Uh, yeah. I'm not really trying to win an argument. Either get off your
duff and Google, or assume my argument is crap and move on with your
life. Either way, I don't care.

if your presumption is correct and frames erroneously made it
into the 4.0 spec before anyone could comment,

No. They were implemented by Netscape before anyone could comment.

Since when is the process of implementing features by individual
manufacturers subject to public consensus?

What the hell are you arguing for? That's exactly what I wrote to Neal.
He said <frames> must be in the spec for a reason. I pointed out that
frames were put in the spec to make sense of what had already been done.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

Jul 23 '05 #56

Brian

Spartanicus wrote:

Brian wrote:
But perhaps the stories from those who were there at the time
are incorrect.

And your sources are?

Both <img> and <frame> have been discussed in ciwa* on numerous
occasions. I don't have time to search for the threads, but you can
always Google the group for them.

Unattributed sources recalled from memory, that puts your comments in
the right category.

I only have time for one, but here you go:

http://groups.google.com/groups?selm...6.ph.gla.ac.uk

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

Jul 23 '05 #57

Brian <us*****@julietremblay.com.invalid> wrote:

I only have time for one, but here you go:

http://groups.google.com/groups?selm...6.ph.gla.ac.uk
Browse up a few messages in the thread, Alan writes:
Look at the stated aims of HTML3.2; even without knowing the inside
story [...]

Wasn't "there at the time", he doesn' t know, guessing only, just like
you are. Fine by me, but there's one thing I don't tolerate: the
spreading of misinformation under the guise of fact.

--
Spartanicus

Jul 23 '05 #58

Jan Roland Eriksson

On Sat, 28 Aug 2004 23:23:49 +0100, Spartanicus <me@privacy.net> wrote:

Brian <us*****@julietremblay.com.invalid> wrote:
I only have time for one, but here you go:
http://groups.google.com/groups?selm...6.ph.gla.ac.uk
Browse up a few messages in the thread, Alan writes:
Look at the stated aims of HTML3.2; even without knowing the inside
story [...]

Wasn't "there at the time", he doesn' t know, guessing only, just like
you are. Fine by me, but there's one thing I don't tolerate: the
spreading of misinformation under the guise of fact.

The "facts of that time" are available in W3 mailing list archives for
any one who cares about it now (well, most of it that is. there are some
threads that has been removed as I recall, due to the really "hot"
personal content in them).

One of the "facts" is that HTML3.2 was an attempt to formalize into a W3
specification what browsers of that time was already capable of.

The "need" for a successor spec after HTML2 rose to a "desperate" level
after that the HTML3 attempt flopped due to browser vendors direct
refusal and/or lack of interest to implement HTML3 as suggested.

So, HTML3.2 only collected and formalized what was already implemented
in available browsers and there was no explicit intent to actually
"approve" of things that "the cat had dragged in" (e.g. frame sets, as
already implemented).

Work on what was to become HTML4 started at the same time, if not even
before HTML3.2 went to rec. status.

--
Rex [who was "there at the time"]

Jul 23 '05 #59

On Sat, 28 Aug 2004, Spartanicus wrote:

Look at the stated aims of HTML3.2; even without knowing the inside
story [...]
Wasn't "there at the time", he doesn' t know,

I wasn't in the actual room, right; I had to rely on reports by those
who were.
guessing only,
Since my posting was based on publicly available information, and said
explicitly that there was no need to rely on insider reports, I don't
really know why you decided to launch such an attack over it.
Fine by me, but there's one thing I don't tolerate: the
spreading of misinformation under the guise of fact.

You're invited to check what the W3C say about it (or do you include
that under "misinformation"?)

HTML/3.2 itself, issued early in 1997, says:

HTML 3.2 aims to capture recommended practice as of early '96

and:

developed in early `96 together with vendors including IBM,
Microsoft, Netscape Communications Corporation, Novell, SoftQuad,
Spyglass, and Sun Microsystems.

W3C's current HTML overview page says of HTML 3.2:

W3C's first Recommendation for HTML which represented the consensus
on HTML features for 1996.

Please feel entirely free to show how that is incompatible with what I
posted:

They weren't any kind of attempt to steer HTML into the future - but
rather, to set down a documented interworking specification which
covered the common features of what the widely-available web browsers
were, de facto, doing at the time.

Jul 23 '05 #60

Brian

Spartanicus wrote:

[Brian posted this link:]

http://groups.google.com/groups?selm...6.ph.gla.ac.uk

Browse up a few messages in the thread, Alan writes:

Look at the stated aims of HTML3.2; even without knowing the
inside story [...]

Wasn't "there at the time", he doesn' t know, guessing only, just
like you are. Fine by me, but there's one thing I don't tolerate:
the spreading of misinformation under the guise of fact.

Forgive me for being blunt, but Flavell and others seem to have far
more useful information on this topic than you've been willing to share.

--
Brian

Jul 23 '05 #61

Andrew Fedoniouk

"Darin McGrew":

Why not? Images, external CSS, external JavaScript, etc., can be cached by
the browser. If the remaining HTML is too bulky, then maybe your "UI" needs to be pruned a bit.
2) You need to separate somehow styles of your UI and styles of content
page. Right?
Remember that there are no way to define style namespaces now...

What's wrong with using appropriate selectors? For example:

.navbar foo bar baz { ... }
.content foo bar baz { ... }

Or perhaps:

#navbar foo bar baz { ... }
#content foo bar baz { ... }

What will happen if your UI and content both have elements with id="navbar"?

There is a natural limitation on how many elements one document can have: 2000 positioned simple DIVs will kill all modern UA (or make them
irresponsive).

And how would frames improve this situation? And again, a design with 2k
positioned DIVs should probably be pruned back.

This is nature of HTML/CSS architecture: computational complexity of HTML
measuring and rendering is function of depth of your DOM tree.
For example: to resolve "#navbar foo bar baz" selector you should traverse
full parent/child chain of #navbar element in worst case.

Andrew Fedoniouk.
http://terrainformatica.com

Jul 23 '05 #62

Andrew Fedoniouk

Alan, I gave a real example: site http://www.rsdn.ru
It is a portal for Russian Software Developers Community.
It serves typical tasks: forum and portal. Target audience uses 56k modem
(median of distribution) to access it.
So the idea was to minimize traffic as much as possible. This is why frames
are there.

Sure my "browser" example is hypothetical.

And about online applications and future directions:
I think that appearance of XForms http://www.w3.org/MarkUp/Forms/
is a proove that HTML started to be considered as UI language also.

Andrew Fedoniouk.
http://terrainformatica.com

"Alan J. Flavell":

On Sat, 28 Aug 2004, Andrew Fedoniouk wrote:
Lets think about web sites as about applications and
HTML as UI layout declartive language.

Let's not. Or rather, let's recognise that those situations are
quite special, and don't help to throw light on how to produce
well-engineered web pages for the WWW.
(I think such assumptions are reasonable this day)

Why? I'd say the developments of HTML as a pseudo application
development language is one of the lame branches of HTML that went
nowhere.
Lets say you would like to design UI of Mozilla browser.

Commendable aim, for a browser developer. Then you'd be on a browsers
development newsgroup - not one which deals with the design of web
pages for the WWW.
Without frames you will create one page with menu, toolbars, other stuff
and content of the page being browsed.
Imaginable?

So, on your planet, every web site will have its own - different -
user interface? No thanks - except for some specialised situations
where the web page is acting as a custom interface to some underlying
application.
There is a natural limitation on how many elements one document can
have: 2000 positioned simple DIVs will kill all modern UA (or make
them irresponsive).

"So don't do that". Concentrate on making well-structured web pages,
and leave browser interface design to browser interface designers.

Or at least recognise that your specialised application interface is
not suitable as a general paradigm for web page design.

Jul 23 '05 #63

Darin McGrew

Andrew Fedoniouk <ne**@terrainformatica.com> wrote:

2) You need to separate somehow styles of your UI and styles of content
page. Right?
Remember that there are no way to define style namespaces now...

I wrote: What's wrong with using appropriate selectors? For example:

.navbar foo bar baz { ... }
.content foo bar baz { ... }

Or perhaps:

#navbar foo bar baz { ... }
#content foo bar baz { ... }

Andrew Fedoniouk <ne**@terrainformatica.com> wrote: What will happen if your UI and content both have elements with id="navbar"?

Apparently, I wasn't clear enough. Let me try again.

The "UI" is inside a <div class="navbar"> or <div id="navbar">. Or if you
prefer, you can use <div class="ui"> or <div id="ui"> instead.

The "content" is inside a <div class="content"> or <div id="content">.

The CSS uses appropriate selectors "to separate somehow styles of your UI
and styles of content" as you put it.

Frames are not needed for this.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"The handwriting on the wall may mean you need a notepad by the phone."

Jul 23 '05 #64

Brian <us*****@julietremblay.com.invalid> wrote:

Wasn't "there at the time", he doesn' t know, guessing only, just
like you are. Fine by me, but there's one thing I don't tolerate:
the spreading of misinformation under the guise of fact.

Forgive me for being blunt, but Flavell and others seem to have far
more useful information on this topic than you've been willing to share.

Hold on, I never claimed to know why frames are still present up to and
including the xhtml 1.1 spec. If anything I equally question why this is
so given the problems they typically cause

Nor am I advocating usage of frames, imo there are very few situations
where a multi pane page with fixed elements makes sense, and frames do
typically cause many problems

I object to 2 things:
1) Stating that the problems frames cause cannot be solved.
2) Stating that frames were a mistake that was universally recognized
even by their creator NS a few months after they deployed them.

The latter cannot be true given that frames were carried forward into
html 4, xhtml 1.0 and xhtml 1.1. There must be more to the story, but I
make no claim to know myself.

--
Spartanicus

Jul 23 '05 #65

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

Fine by me, but there's one thing I don't tolerate: the
spreading of misinformation under the guise of fact.
You're invited to check what the W3C say about it (or do you include
that under "misinformation"?)

HTML/3.2 itself, issued early in 1997, says:

HTML 3.2 aims to capture recommended practice as of early '96

Note that it says "recommended practice", not as was claimed a
formalization of what was used in practice. "Recommended practice"
suggests that there was a vetting procedure of the methods implemented
at the time. The absence in the specs of other code that was prevalent
at the time seems to confirm that such a process took place.
W3C's current HTML overview page says of HTML 3.2:

W3C's first Recommendation for HTML which represented the consensus
on HTML features for 1996.

Right, consensus. The claim I objected to was that frames were a total
mistake that was universally recognized even by NS a few months after
they deployed them.

I that was the case, why were frames carried forward into html 4, xhtml
1.0 and xhtml 1.1?

--
Spartanicus

Jul 23 '05 #66

On Mon, 30 Aug 2004, Spartanicus wrote:

HTML 3.2 aims to capture recommended practice as of early '96
Note that it says "recommended practice", not as was claimed a
formalization of what was used in practice. "Recommended practice"
suggests that there was a vetting procedure of the methods
implemented at the time.

If you're going to put so much value into the exact form of words,
then perhaps you should read them in their context.

"to capture recommended practice" seems to me to imply that there was
some recommended practice out there, and the W3C set out to capture it
in HTML/3.2. Which indeed seems to be what they did, in spite of the
misgivings of some of the more-principled participants.
The absence in the specs of other code that was prevalent
at the time seems to confirm that such a process took place.
Feel free to be specific.

Some vendor-specific constructs were omitted because their major
competitor refused to implement them, so there was no point in
specifying them. Others fell into a sort of twilight zone where the
W3C hoped the contenders would soon implement them, even though, as it
turned out, the hope fell on deaf ears (as with <abbr> for example).
I that was the case, why were frames carried forward into html 4,
If you wanted to know the answer to that question, I guess you'd start
by reading the W3C's HTML4 materials. Quite early on in the HTML4
spec it says

2.4 Authoring documents with HTML 4

We recommend that authors and implementors observe the following
general principles when working with HTML 4.

2.4.1 Separate structure and presentation

(and you'll see the same principle espoused in XHTML/1.1).

Transitional and frameset DTDs were provided for compatibility with
what the existing agents were supporting.

I'm sure you'll find some positive spin from the frameset supporters,
though, to demonstrate to us that frames has suddenly got so much
better in HTML4 than they had ever been in 3.2.
xhtml 1.0
it's a reformulation of HTML/4.01 into XML, so it should come as no
surprise that it contains the things that were found in HTML/4.01.
and xhtml 1.1?

What about XHTML/1.1 ? It's modular. You can bolt-on all kinds of
modules. Some of them even conform to the W3C's design guidelines
(viz. of marking-up the structure of content in (X)HTML, and
delegating presentation to a stylesheet).

Perhaps you'd care to gloss the following text for us (from the
XHTML/1.1 introduction):

to provide a consistent, forward-looking document type cleanly
separated from the deprecated, legacy functionality of HTML 4 [HTML4]
that was brought forward into the XHTML 1.0 [XHTML1] document types.
This document type is essentially a reformulation of XHTML 1.0 Strict
using XHTML Modules. This means that many facilities available in
other XHTML Family document types (e.g., XHTML Frames) are not
available in this document type.

I perceive a rather clear message in that, but I'm sure you'll come up
with something.

Jul 23 '05 #67

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

The absence in the specs of other code that was prevalent
at the time seems to confirm that such a process took place.
Feel free to be specific.

<embed>, <nobr> to name two, both widely implemented, never included in
any spec.

I that was the case, why were frames carried forward into html 4,

If you wanted to know the answer to that question, I guess you'd start
by reading the W3C's HTML4 materials. Quite early on in the HTML4
spec it says

2.4 Authoring documents with HTML 4

We recommend that authors and implementors observe the following
general principles when working with HTML 4.

2.4.1 Separate structure and presentation

And a frameset DTD prevents authors from doing that how? Frames provide
structure.
(and you'll see the same principle espoused in XHTML/1.1).
A valid xhtml 1.1 site's dtd that uses frames doesn't allow deprecated
elements.

and xhtml 1.1?

What about XHTML/1.1 ? It's modular. You can bolt-on all kinds of
modules.

Sure you can create a module that renders Harry Belafonte's Banana Boat
song in braille, but don't expect it to be accepted by w3c. W3c
published modules however are as much part of the specification as the
xhtml core spec.
Perhaps you'd care to gloss the following text for us (from the
XHTML/1.1 introduction):

to provide a consistent, forward-looking document type cleanly
separated from the deprecated, legacy functionality of HTML 4 [HTML4]
that was brought forward into the XHTML 1.0 [XHTML1] document types.
This document type is essentially a reformulation of XHTML 1.0 Strict
using XHTML Modules. This means that many facilities available in
other XHTML Family document types (e.g., XHTML Frames) are not
available in this document type.

I perceive a rather clear message in that

And what do you perceive that message to be?

If it's "frames are defective, don't use them", why did w3c accept the
frames xhtml module into the specification?

--
Spartanicus

Jul 23 '05 #68

Spartanicus wrote:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
2.4.1 Separate structure and presentation

And a frameset DTD prevents authors from doing that how? Frames provide
structure.

I suppose it could be argued that frames provide a small bit of
structure, but I don't see how anyone in their right mind could claim
that a frameset provides any separation of structure and presentation. A
frameset says that foo.html's frame is on the left and bar.html's frame
is on the right; a stylesheet can't put foo.html on the right, or even
change its border color. Where's the separation?

Jul 23 '05 #69

Brian

Andrew Fedoniouk wrote:

What will happen if your UI and content both have elements with
id="navbar"?

You'll have invalid html, which you should fix. Each id must be unique
to the document in which it appears.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

Jul 23 '05 #70

Brian

Spartanicus wrote:

I object to 2 things:
1) Stating that the problems frames cause cannot be solved.
2) Stating that frames were a mistake that was universally recognized
even by their creator NS a few months after they deployed them.

The latter cannot be true given that frames were carried forward into
html 4, xhtml 1.0 and xhtml 1.1.
Why can that not be true? You mean that if the W3C puts something in a
recommendation, it must be useful on the www? By definition?
There must be more to the story, but I make no claim to know myself.

No, but you certainly slammed me, and then others, for the claims they
made -- claims which appear to have some merit, as it turns out.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

Jul 23 '05 #71

Brian <us*****@julietremblay.com.invalid> wrote:

I object to 2 things:
1) Stating that the problems frames cause cannot be solved.
2) Stating that frames were a mistake that was universally recognized
even by their creator NS a few months after they deployed them.

The latter cannot be true given that frames were carried forward into
html 4, xhtml 1.0 and xhtml 1.1.
Why can that not be true?

Universally recognized mistakes are not carried forward.

There must be more to the story, but I make no claim to know myself.

No, but you certainly slammed me, and then others, for the claims they
made

I don't know how tall a giraffe stands, but I do know that it isn't 2km,
false claims get challenged, nothing personal.
-- claims which appear to have some merit, as it turns out.

There's some merit in saying that my radio is made from transistors,
it's not true though.

--
Spartanicus

Jul 23 '05 #72

Alan Wood

Neal <ne*****@yahoo.com> wrote in message news:<op**************@news.individual.net>...

Do you know of a site which uses frames in an appropriate way?
Where s it, and why do you think it's acceptable?

I use frames for indexes on one of my sites, for example:

<http://www.alanwood.net/pesticides/index_cn_frame.html>

I have not yet seen a browseable index of this size that does not use
frames.

I don't use frames throughout the site, only for this type of index.
There is a link at the bottom of each data sheet that brings it out of
the frames to allow bookmarking. Each data sheet can also be reached
from unframed, classified lists, so search engines can easily reach
everywhere. The site uses lots of markup that is not normally seen by
sighted visitors, and is accessible to WAI-A standard.

--
Alan Wood
http://www.alanwood.net (Unicode, special characters, pesticide names)

Jul 23 '05 #73

la_haine

Leif K-Brooks <eu*****@ecritters.biz> wrote in news:2p854oFhsljmU1@uni-
berlin.de:

Dumping photos cheap and easy.
http://www.campalicious.com/2002/photos/dav/

And what if someone wants to link to a particular photo on your page?

Well, in Opera, I can right-click the image, and select 'copy image address',
and then I have the link:

http://www.campalicious.com/2002/pho...v/dcp03661.jpg

--
'When these meteors last came, we thought the sky was on fire... Naturally,
we blamed the Irish. Hanged more than a few...'
- Grandpa Simpson

Jul 23 '05 #74

jerry gitomer

Spartanicus wrote:

Brian <us*****@julietremblay.com.invalid> wrote:

I object to 2 things:
1) Stating that the problems frames cause cannot be solved.
2) Stating that frames were a mistake that was universally recognized
even by their creator NS a few months after they deployed them.

The latter cannot be true given that frames were carried forward into
html 4, xhtml 1.0 and xhtml 1.1.

Why can that not be true?

Universally recognized mistakes are not carried forward.

[ skipped ]

Unfortunately, in the computer industry, this is not so.
Anything that gets released to the public, be it good or bad,
tends to be hard to kill.

Since standards committees typically have representation from
users as well as developers and the users are totally and
completely unwilling to modify their existing systems bad
features tend to live for several iterations of a standard. (At
least long enough so that the users can convince their
management types to finance replacement systems without
jeopardizing their own careers.)

Jul 23 '05 #75

Alan Wood wrote:

I use frames for indexes on one of my sites, for example:

<http://www.alanwood.net/pesticides/index_cn_frame.html>

[...]
There is a link at the bottom of each data sheet that brings it out of
the frames to allow bookmarking. [...]

How many normal people are going to know that they need to click a link
labeled "no frames" to bookmark a web page?

Jul 23 '05 #76

Alan Wood

Leif K-Brooks <eu*****@ecritters.biz> wrote in message news:<2p************@uni-berlin.de>...

Alan Wood wrote:
I use frames for indexes on one of my sites, for example:

<http://www.alanwood.net/pesticides/index_cn_frame.html>

[...]
There is a link at the bottom of each data sheet that brings it out of
the frames to allow bookmarking. [...]

How many normal people are going to know that they need to click a link
labeled "no frames" to bookmark a web page?

I do not know the answer to that question, but:

a) I have a feedback form, but nobody has ever asked about bookmarks;

b) I have included instructions on bookmarking in the Hints and Tips:
<http://www.alanwood.net/pesticides/hints.html#bookmark>

--
Alan Wood
http://www.alanwood.net (Unicode, special characters, pesticide names)

Jul 23 '05 #77

Alan Wood wrote:

Leif K-Brooks <eu*****@ecritters.biz> wrote in message news:<2p************@uni-berlin.de>...
How many normal people are going to know that they need to click a link
labeled "no frames" to bookmark a web page?
I do not know the answer to that question, but:

a) I have a feedback form, but nobody has ever asked about bookmarks;

Most visitors will just get a confused look on their face when
bookmarking (or linking) doesn't work in the way they expect. They might
not even think it's something wrong with your site.
b) I have included instructions on bookmarking in the Hints and Tips:
<http://www.alanwood.net/pesticides/hints.html#bookmark>

Do you really expect a casual visitor to read a list of hints and tips
before trying to do something as simple as bookmarking your site?

Jul 23 '05 #78

Jean-Claude Perlberger

Leif K-Brooks <eu*****@ecritters.biz> wrote:

Alan Wood wrote:
Leif K-Brooks <eu*****@ecritters.biz> wrote in message news:<2p************@uni-berlin.de>...
How many normal people are going to know that they need to click a link
labeled "no frames" to bookmark a web page?

I do not know the answer to that question, but:

a) I have a feedback form, but nobody has ever asked about bookmarks;

Most visitors will just get a confused look on their face when
bookmarking (or linking) doesn't work in the way they expect. They might
not even think it's something wrong with your site.
b) I have included instructions on bookmarking in the Hints and Tips:
<http://www.alanwood.net/pesticides/hints.html#bookmark>

Do you really expect a casual visitor to read a list of hints and tips
before trying to do something as simple as bookmarking your site?

As chemist I find the site of Alan VERY userfriendly to navigate and I also use
this technique !

I would like that the people who are always criticizing the frames propose an
alternative which is as easy to implement !

Thank you in advance for the many replies.

Best regards, Jean-Claude Perlberger.

Jul 23 '05 #79

Alan Wood

Leif K-Brooks <eu*****@ecritters.biz> wrote in message news:<2p************@uni-berlin.de>...

Alan Wood wrote:
Leif K-Brooks <eu*****@ecritters.biz> wrote in message news:<2p************@uni-berlin.de>...
How many normal people are going to know that they need to click a link
labeled "no frames" to bookmark a web page?

I do not know the answer to that question, but:

a) I have a feedback form, but nobody has ever asked about bookmarks;

Most visitors will just get a confused look on their face when
bookmarking (or linking) doesn't work in the way they expect. They might
not even think it's something wrong with your site.
b) I have included instructions on bookmarking in the Hints and Tips:
<http://www.alanwood.net/pesticides/hints.html#bookmark>

Do you really expect a casual visitor to read a list of hints and tips
before trying to do something as simple as bookmarking your site?

Leif

What point are you trying to make?

I am not claiming that frames are perfect, but for this type of index
there does not seem to be any alternative to frames. I have done
everything I can to make the indexes user-friendly and accessible.

I am open to suggestions for a better method of presenting the
indexes.

--
Alan Wood
http://www.alanwood.net (Unicode, special characters, pesticide names)

Jul 23 '05 #80

jake

In message <93**************************@posting.google.com >, Alan Wood
<al*******@context.co.uk> writes

Neal <ne*****@yahoo.com> wrote in message
news:<op**************@news.individual.net>...
Do you know of a site which uses frames in an appropriate way?
Where s it, and why do you think it's acceptable?

I use frames for indexes on one of my sites, for example:

<http://www.alanwood.net/pesticides/index_cn_frame.html>

I have not yet seen a browseable index of this size that does not use
frames.

I don't use frames throughout the site, only for this type of index.
There is a link at the bottom of each data sheet that brings it out of
the frames to allow bookmarking. Each data sheet can also be reached
from unframed, classified lists, so search engines can easily reach
everywhere. The site uses lots of markup that is not normally seen by
sighted visitors, and is accessible to WAI-A standard.

That's certainly a good example of "when frames aren't evil". It's hard
to see how the information could be retrieved by any other means as
easily as you've demonstrated.

regards.
--
Jake

Jul 23 '05 #81

AES/newspost

> In message <93**************************@posting.google.com >, Alan Wood

<al*******@context.co.uk> writes

I use frames for indexes on one of my sites, for example:

<http://www.alanwood.net/pesticides/index_cn_frame.html>

Nice site, and massive amount of information
(I looked at it just out of curiousity).

Most of the data sheets I looked at seem to word wrap
their text to the window width -- but the one for rotenone
doesn't seem to wrap ??? (At least for my browser: Mac
OS 9.2, Netscape 7.1)

Jul 23 '05 #82