When frames aren't evil

[Neal]

Of course, every frame site I've ever seen has reduced usability and all.
We've been through this before.

But as frameset is still a part of HTML, there must be some legitimate use
for it, hmm? For most markup I know when it's useful and when it's not,
but regarding table markup I sure know when it isn't good, but can't
really come up with a way it would be good.

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?

[Neal]

On Fri, 27 Aug 2004 01:02:07 -0400, Neal <ne*****@yahoo.com> wrote:

regarding table markup

Meant "frame", of course.

[tm]

Neal wrote:

As you all are among the sharpest pencils in the bag,
Can't speak for others, but, yeah.
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?

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

[Andrew Fedoniouk]

Russian software developer forum : http://www.rsdn.ru/ (in Russian)
Frames there are doing what they are designed for.

Andrew Fedoniouk.
http://terrainformatica.com

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

Of course, every frame site I've ever seen has reduced usability and all.
We've been through this before.

But as frameset is still a part of HTML, there must be some legitimate use
for it, hmm? For most markup I know when it's useful and when it's not,
but regarding table markup I sure know when it isn't good, but can't
really come up with a way it would be good.

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?

[Leif K-Brooks]

tm wrote:

Neal wrote:

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?

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?
That's not a good use of frames. There's no such thing.

[Leif K-Brooks]

Andrew Fedoniouk wrote:

Russian software developer forum : http://www.rsdn.ru/ (in Russian)
Frames there are doing what they are designed for.

Yup, the frames on that site are doing exactly what they were designed
to do: annoy the visitor to no end.

[Spartanicus]

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

Of course, every frame site I've ever seen has reduced usability and all.
We've been through this before.

But as frameset is still a part of HTML, there must be some legitimate use
for it, hmm? For most markup I know when it's useful and when it's not,
but regarding table markup I sure know when it isn't good, but can't
really come up with a way it would be good.

Contrary to popular belief all the technical problems with frames can be
solved. The one remaining drawback is that in most situations it takes a
*lot* of extra work to create and maintain, the maintenance issue can be
solved in a small number of cases.

But you specifically mentioned "usability", this could mean something
else completely. A usability drawback could be that users are confused
by multiple independently scrolling panes within the browser window,
another issue could be that fixing things like a nav section can be
considered unnecessary and/or a waste of canvas space.

These latter problems are shared by css frame "imitations", and css
frame imitations also have an inherent drawback to frames: viewport
scrolling with the keyboard breaks when there's a top of bottom fixed
section.

--
Spartanicus

[tm]

Leif K-Brooks wrote:

tm wrote:

Neal wrote:

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?

Dumping photos cheap and easy.

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

Fuck 'em. Its a page to dump photos, not for linkin' to.

[Jukka K. Korpela]

Spartanicus <[e-mail]> wrote:

Contrary to popular belief all the technical problems with frames can
be solved.

Maybe for some values of "technical", "problem", and "solve".

For example, the fact that you cannot refer to a particular combination
of frame contents (intuitively, a "page" of a site using frames) is a
technical problem in my opinion. And what comes closest to solving it is
setting up a server-side script that accepts suitable parameters
(identifying a combination) and generates a corresponding <frameset>
document. But I would say that there are so many problems in such a
solution that it really does not solve the non-adressibility problem.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Pierre Goiffon]

"Neal" <ne*****@yahoo.com> a écrit dans le message de
news:op**************@news.individual.net

But as frameset is still a part of HTML, there must be some
legitimate use for it, hmm?

I'll respond with another question : what does exists now to replace frames
? Yes, there are CSS alternates... but they also have their disavantages.

[Leif K-Brooks]

Pierre Goiffon wrote:

I'll respond with another question : what does exists now to replace frames
? Yes, there are CSS alternates... but they also have their disavantages.

The inclusion feature? SSI, PHP, ASP, or one of a dozen other
three-letter acronyms. The scrolling? Bad idea in the first place.

[Pierre Goiffon]

"Leif K-Brooks" <eu*****@ecritters.biz> a écrit dans le message de
news:2p************@uni-berlin.de

what does exists now to replace
frames ?
The inclusion feature?

For some case, yes, for many others, no. You've got the reload problem
mainly, but also lots of presentation features.
The scrolling? Bad idea in the first place.

Are you kidding ? Just see how mutch UI uses a frame equivalent
presentation... Begining surely with your news client.

[Fred]

On Fri, 27 Aug 2004 10:16:19 +0200, "Pierre Goiffon"
<pg******@nowhere.invalid> wrote:

I'll respond with another question : what does exists now to replace frames
? Yes, there are CSS alternates... but they also have their disavantages.

Use a CMS to generate pages, so that a navigator bar is added in each
page automagically instead of using a frame?

Fred.

[Alan J. Flavell]

On Fri, 27 Aug 2004, Pierre Goiffon wrote:

Are you kidding ? Just see how mutch UI uses a frame equivalent
presentation...
To the extent that the panes of those UIs are under the control of the
user, and that there will be no need for you to communicate a
particular configuration of your UI to another user (= bookmark), a
paned interface can indeed be useful.

The problem with frames as a web design technique is that they were
designed to fulfil the requirements of the author, not of the end
user. One might even go so far as to say that they take away options
from the end user.

The analogy of a framed UI in the WWW domain would be a browser which
can, for example, offer a side menu of the links from the document
which you are viewing in a main window, and can visit those links at
the user's choice - in a separate tab or window if they so choose.

Irrespective of the desire of the document author to confine the
user's browsing experience to a specific subset of parts, as is
implied by author-based frame designs.
Begining surely with your news client.

"My" news client? Actually not, but that's not the issue here.

all the best

[Pierre Goiffon]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> a écrit dans le message de
news:Pi*******************************@ppepc56.ph. gla.ac.uk

The problem with frames as a web design technique is that they were
designed to fulfil the requirements of the author, not of the end
user. One might even go so far as to say that they take away options
from the end user.

I'm particularly upset with this recurrent argument : I mean there's no
"bad" technology, only bad uses.

Yes, very often frames were used for the author satisfaction, and the user
gets in fact lots of trouble with that choice. But when you _must_ have a
paned UI, when one of this pane must be always visible, have its own
scrolling (scrollable with the mouse wheel), can't be reload very often
because of its size (cache issues), ... There's nothing as good as frames.

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

Contrary to popular belief all the technical problems with frames can
be solved.

Maybe for some values of "technical", "problem", and "solve".

For example, the fact that you cannot refer to a particular combination
of frame contents (intuitively, a "page" of a site using frames) is a
technical problem in my opinion.

100% solvable by using a new frameset for every combination of frames.
That may not be realistic depending on how the site is structured, but
it certainly is feasible for not very complex sites.

I should expand a bit on my initial reply, the "all problems can be
solved" only applies if SE's follow robots.txt guidelines. Most relevant
SEs do, but I recently noticed that Teoma doesn't.

I also neglected to consider all keyboard navigation issues, here frames
can pose usability problems compared to normal pages. When comparing
frames to css frame imitations, most UAs have decent frame navigation
features, needless to say that the css imitations loose out here also.

--
Spartanicus

[Chris Morris]

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

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?

I can't remember where it was now (this was years ago), but it was a
heavily annotated document, with lots of footnotes. The document was
in both frames - a large one in the top 3/4 or so of the screen, a
small one in the bottom 1/4 or so. Click on a footnote link in the
main frame and it displayed the footnote in the small frame.

I didn't check the implementation in any detail then, so I don't know
what the degradation was like, but reasonably good degradation should
have been possible.

That's the only one I've seen.

--
Chris

[jake]

In message <41***********************@news.free.fr>, Pierre Goiffon
<pg******@nowhere.invalid> writes

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> a écrit dans le message de
news:Pi*******************************@ppepc56.ph .gla.ac.uk

The problem with frames as a web design technique is that they were
designed to fulfil the requirements of the author, not of the end
user. One might even go so far as to say that they take away options
from the end user.

I'm particularly upset with this recurrent argument : I mean there's no
"bad" technology, only bad uses.

Yes, very often frames were used for the author satisfaction, and the user
gets in fact lots of trouble with that choice. But when you _must_ have a
paned UI, when one of this pane must be always visible, have its own
scrolling (scrollable with the mouse wheel), can't be reload very often
because of its size (cache issues), ... There's nothing as good as frames.

Sure.

One typical 'good' use that I've experienced in the past is the
situation when you're trying to locate some information in a particular
report but you can't remember which report it is.

So you bring up a framed page.

One frame contains a scrollable list of the reports by date; another
frame contains the report (and maybe a third frame for associated
information).

It's easy to just click on a date that you think is the right one and
see the report appear in the second frame. If that's not the one you
want -- a single click gets you the next one (or the prior one) .....
and so on.

I can't think of a quicker way of doing this.

regards.

--
Jake

[Alan J. Flavell]

On Fri, 27 Aug 2004, jake wrote:

So you bring up a framed page.
....if the author bothered to provide one as an alternative. But isn't
it so much better if your browser can do this for you, on any web
site, irrespective of what the author had provided?
One frame contains a scrollable list of the reports by date; another
frame contains the report (and maybe a third frame for associated
information).

It's easy to just click on a date that you think is the right one
and see the report appear in the second frame. If that's not the one
you want -- a single click gets you the next one (or the prior one)
..... and so on.

I can't think of a quicker way of doing this.

Yup, that's what I already described - a browser which can generate a
side-menu of links and then open those links in a separate tab or
window.

I see no benefit in having to rely on the document author to implement
that for me.

Surely one of the *strengths* of the WWW is the ability for the user
to repurpose the marked-up content that's provided by authors? If you
want to confine yourself to the straightjacket of one specific UI
design provided by the document author, we might as well go back to
the gopher system (for those of us who remember what it was).

[Karl Groves]

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

Of course, every frame site I've ever seen has reduced usability and all.
We've been through this before.

This is a common misconception. Usability studies show that frames
(specifically, a frameset with a navigation frame and content frame)
actually enhances ease-of-use by keeping navigation in full view at all
times.

The problem is that all of the other negatives outweigh this benefit.

When Microsoft decides to finally support position:fixed in CSS, the world
will be an entirely different place, and you will see this on every site I
make.

-Karl

[Jukka K. Korpela]

Spartanicus <[e-mail]> wrote:

For example, the fact that you cannot refer to a particular
combination of frame contents (intuitively, a "page" of a site using
frames) is a technical problem in my opinion.
100% solvable by using a new frameset for every combination of
frames. That may not be realistic depending on how the site is
structured, but it certainly is feasible for not very complex sites.

I wouldn't call a problem 100% solvable if the solution is not realistic.
And it isn't - that's why you hardly find it used in actual authoring.
And using a new frameset for every combination normally defeats the very
reason for using frames.
I should expand a bit on my initial reply, the "all problems can be
solved" only applies if SE's follow robots.txt guidelines. Most
relevant SEs do, but I recently noticed that Teoma doesn't.

I don't see what you are referring to. Do you mean telling indexing
robots not to index individual pages? That would remove the very
essential problem that a user finds a page that is mystery since it has
been "taken out of frames". And it would create a much bigger problem:
searches would not produce useful results.

Here again, there are techniques that can be used to overcome _some_ of
the problems, but they mean more work, and rather frustrating work. It is
frustrating to use a technology (frames) to achieve something, then
realize you have created problems, and even partial solutions to the
problems*) require essentially more complex techniques and more work than
the technology that created them.

*) Apart from getting rid of slimy frames, of course.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

For example, the fact that you cannot refer to a particular
combination of frame contents (intuitively, a "page" of a site using
frames) is a technical problem in my opinion.
100% solvable by using a new frameset for every combination of
frames. That may not be realistic depending on how the site is
structured, but it certainly is feasible for not very complex sites.

I wouldn't call a problem 100% solvable if the solution is not realistic.
And it isn't - that's why you hardly find it used in actual authoring.

You hardly find it in actual authoring because most authors don't know
about the issues that frames throw up, few out of the minority that do
know care, and out of the few out of that sub sub group are willing
and/or able to solve it.
And using a new frameset for every combination normally defeats the very
reason for using frames.
You forgot to mention what it is that you perceive as "the very reason
to use frames", and where you got the evidence that supports your belief
in knowing what this is.

I should expand a bit on my initial reply, the "all problems can be
solved" only applies if SE's follow robots.txt guidelines. Most
relevant SEs do, but I recently noticed that Teoma doesn't.

I don't see what you are referring to. Do you mean telling indexing
robots not to index individual pages? That would remove the very
essential problem that a user finds a page that is mystery since it has
been "taken out of frames". And it would create a much bigger problem:
searches would not produce useful results.

My mistake (it's been years since I used frames) this should be solved
by server side redirection.
Here again, there are techniques that can be used to overcome _some_ of
the problems, but they mean more work, and rather frustrating work.

I explicitly pointed out in my initial reply that this is typically the
case, but again this can be solved. I used to generate a "proper" framed
site from a relational database, beyond drawing up the templates and a
few routines it required no extra effort to duplicate the content in the
noframes section or to generate a page with it's own frameset for every
combination of panes. Btw, the reason to use the database was not
related to using frames, it was programmed as POS system that just
happened to be handy to solve some of the generation and maintenance
issues that arise with a proper frame site.

--
Spartanicus

[Brian]

Neal wrote:

as frameset is still a part of HTML,
It's in the recommendation because it's in the www, not the other way
around.
there must be some legitimate use for it, hmm?
Not necessarily. Frames were introduced by Netscape, apparently in spite
of the misgivings of others about their problems.
As you all are among the sharpest pencils in the bag,
Not me. The tip broke some time ago I'm afraid.
let me ask: Do you know of a site which uses frames in an appropriate
way?

How about Google Groups threaded view?

http://groups.google.com/groups?thre...individual.net

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

[Brian]

Pierre Goiffon wrote:

when you _must_ have a paned UI, when one of this pane must be always
visible, have its own scrolling (scrollable with the mouse wheel),
.... then perhaps the www is not the ideal place for you to author.
can't be reload very often because of its size (cache issues), ...

How do frames improve cacheability? What's wrong with cache-control
headers? That way, you can cache the whole document, not just one part.

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

[Andrew Fedoniouk]

> Yup, the frames on that site are doing exactly what they were designed

to do: annoy the visitor to no end.
:)

You did not get the idea of frames then.
Actually this site is not for just visitors like you. This site is for
professionals.

Andrew Fedoniouk.
http://terrainformatica.com

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

Russian software developer forum : http://www.rsdn.ru/ (in Russian)
Frames there are doing what they are designed for.

Yup, the frames on that site are doing exactly what they were designed
to do: annoy the visitor to no end.

[Spartanicus]

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

as frameset is still a part of HTML,

It's in the recommendation because it's in the www, not the other way
around.

So you claim that recommendations serve to justify what is being used on
the web???

There are loads of things "in the www" that are not in the spec. Note
that there's a xhtml 1.0 frame doctype, and a xhtml 1.1 frames module,
now why do you think these were created?

--
Spartanicus

[Karl Groves]

"Spartanicus" <[e-mail]> wrote in message
news:19********************************@news.spart anicus.utvinternet.ie...

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

as frameset is still a part of HTML,

It's in the recommendation because it's in the www, not the other way
around.

So you claim that recommendations serve to justify what is being used on
the web???

Oh come on now. I've seen plenty of your posts to know that you're far
smarter than this post makes you seem.
A vast majority of the elements and attributes of the HTML spec were once
proprietary in nature and were included because their use was so widespread.

-Karl

[Jukka K. Korpela]

Spartanicus <[e-mail]> wrote:

And using a new frameset for every combination normally defeats the
very reason for using frames.
You forgot to mention what it is that you perceive as "the very
reason to use frames", and where you got the evidence that supports
your belief in knowing what this is.

Sorry, I thought it was evident enough. The common reason for using
frames is that they are a simple technique for generating what so many
people regard as an obligatory paradigm: navigation links or buttons on
the left, on each page. No need to get involved in fancy technologies
like PHP or SSI. :-) But generating new framesets makes things much more
complex.

I should expand a bit on my initial reply, the "all problems can be
solved" only applies if SE's follow robots.txt guidelines. Most
relevant SEs do, but I recently noticed that Teoma doesn't.

I don't see what you are referring to. Do you mean telling indexing
robots not to index individual pages? That would remove the very
essential problem that a user finds a page that is mystery since it
has been "taken out of frames". And it would create a much bigger
problem: searches would not produce useful results.

My mistake (it's been years since I used frames) this should be
solved by server side redirection.

Pardon? It gets even more mystic now.
I used to generate a "proper"
framed site from a relational database, beyond drawing up the
templates and a few routines it required no extra effort to duplicate
the content in the noframes section or to generate a page with it's
own frameset for every combination of panes.

This proves the part that the methods of solving some of the problems
that frames cause are complicated and require extra work, as opposite to
what HTML authoring usually is. Surely _you_ can do it, but most people
can't, and don't bother. Moreover, the methods solve _some_ of the
problems that frames cause. For example, using a frames-based site with a
speech browser is inherently inconvenient, since you need to switch
between frames anyway (and this is at least inconvenient, often really
tough, especially when there are many frames and they have names like
"frame1", "frame2" for example). Using a page that simulates frames using
tables is often even more inconvenient, of course.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Neal]

On Fri, 27 Aug 2004 06:07:19 GMT, Andrew Fedoniouk
<ne**@terrainformatica.com> wrote:

Russian software developer forum : http://www.rsdn.ru/ (in Russian)
Frames there are doing what they are designed for.

Andrew Fedoniouk.
http://terrainformatica.com

Perhaps you could explain why you think this application of frameset is a
good one? Not knowing a lick of Russian, I can't readily discern the
purpose of your example.

[Leif K-Brooks]

Andrew Fedoniouk wrote:

Yup, the frames on that site are doing exactly what they were designed
to do: annoy the visitor to no end.

:)

You did not get the idea of frames then.
Actually this site is not for just visitors like you. This site is for
professionals.

Ah, so it's all right to annoy professionals to no end? I understand now.

[Leif K-Brooks]

Karl Groves wrote:

When Microsoft decides to finally support position:fixed in CSS, the world
will be an entirely different place, and you will see this on every site I
make.

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.

[Neal]

On Fri, 27 Aug 2004 07:30:33 -0400, Karl Groves <ka**@NOSPAMkarlcore.com>
wrote:

When Microsoft decides to finally support position:fixed in CSS, the
world
will be an entirely different place, and you will see this on every site
I
make.

I attempted a fixed navigation on a site, which I had IE interpret as
absolute. On IE the bit scrolled with the page, but on other conforming
browsers with support for fixed, if the viewport was not as tall as the
fixed div the last items were inaccessible.

I've seen a tutorial posted to one of the HTML groups (the one which
references a not-yet-completed CSS tutorial, if it helps anyone else
recall the URL) with just such a left navbar.

Unless the fixed div is rather short, it's destined to fail in some UAs.

[Keith Bowes]

Pierre Goiffon wrote:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> a écrit dans le message de
news:Pi*******************************@ppepc56.ph. gla.ac.uk

The problem with frames as a web design technique is that they were
designed to fulfil the requirements of the author, not of the end
user. One might even go so far as to say that they take away options
from the end user.

I'm particularly upset with this recurrent argument : I mean there's no
"bad" technology, only bad uses.

Or in the case of frames, bad implementation. Actually, I don't mind
framed sites that much, but there is room for improvement of the
implementation. The text in the URL field not changing is just annoying.

[Keith Bowes]

Leif K-Brooks 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.

[jake]

In message <Xn*****************************@193.229.0.31>, Jukka K.
Korpela <jk******@cs.tut.fi> writes
[snip]

For example, using a frames-based site with a
speech browser is inherently inconvenient,
'inherently' inconvenient? I think not..

If you think of a 'typical' frame-based site:
(a) header frame at the top (fixed content)
(b) footer frame at the bottom (fixed content)
(c) navigation frame (fixed content)
(d) main content frame
it can be quicker to toggle between the navigation bar and main content
then it would be on a non-frames site where you often need to play 'hunt
the navigation menu'.

From anywhere in the main content you can get to the navigation menu in
an average of 2 keystrokes.

since you need to switch
between frames anyway (and this is at least inconvenient, often really
tough, especially when there are many frames and they have names like
"frame1", "frame2" for example). Using a page that simulates frames using
tables is often even more inconvenient, of course.

Where it does get inconvenient is where a site uses frames to simulate a
table-based layout and you've got more than a dozen (often) un-named
frames to toggle between:

Try navigating this in a screen-reader/talking browser:
http://www.vindolanda.com/

regards.

--
Jake

[Neal]

On Fri, 27 Aug 2004 16:28:26 -0400, Keith Bowes <do****@spam.me> wrote:

Leif K-Brooks 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?

[Leif K-Brooks]

Keith Bowes wrote:

Leif K-Brooks 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.

AFAIK, that will only work if you set a height. Unless the div you're
positioning starts at the top-left of the view port, you can't do that.

[Brian]

Spartanicus wrote:

Brian wrote:

[attribute missing, reinserted here] Neal wrote:

as frameset is still a part of HTML,

It's in the recommendation because it's in the www, not the other
way around.

So you claim that recommendations serve to justify what is being used
on the web???

If the stories I've heard are true, then the answer is: sometimes.

AIUI, <img> was developed by Mosaic/Netscape, and was already
implemented before anyone could comment. Same for <frames>. But perhaps
the stories from those who were there at the time are incorrect.

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

[Keith Bowes]

Neal wrote:

On Fri, 27 Aug 2004 16:28:26 -0400, Keith Bowes <do****@spam.me> wrote:

Leif K-Brooks 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 it should give the container scrollbars, but the problem
with CSS is that it's all theory.

[Spartanicus]

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

It's in the recommendation because it's in the www, not the other
way around.
So you claim that recommendations serve to justify what is being used
on the web???

If the stories I've heard are true, then the answer is: sometimes.

AIUI, <img> was developed by Mosaic/Netscape, and was already
implemented before anyone could comment. Same for <frames>.

Very different points in time you are referring to here, <img> preceded
frames by some margin. Frames were introduced in the HTML 4.0 spec, by
then considerable improvements had been made in the process of drawing
specs up.
But perhaps
the stories from those who were there at the time are incorrect.

And your sources are?

You've not answered a question from my previous post, if your
presumption is correct and frames erroneously made it into the 4.0 spec
before anyone could comment, how then did it come to be that frames were
carried forward into xhtml 1.0 and 1.1?

--
Spartanicus

[Spartanicus]

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

--
Spartanicus

[Darin McGrew]

Spartanicus <[e-mail]> wrote:

Very different points in time you are referring to here, <img> preceded
frames by some margin. Frames were introduced in the HTML 4.0 spec, by
then considerable improvements had been made in the process of drawing
specs up.

Frames were introduced in NN 2, back in 1996. Later, Cougar (which
eventually became HTML 4) tried to make sense of it. The result is what we
have now: a Frameset DTD for frameset documents, a Transitional DTD that
includes formally deprecated markup and frames-related markup, and a Strict
DTD that does not include either formally deprecated markup or
frames-related markup.

The fundamental problems with the design of frames haven't changed in
almost a decade. And they haven't changed with the introduction of DTDs
that try to rationalize the design.

Actually, they offered a "proposal" in 1995, and when the shortcomings of
the design were pointed out, they ignored the criticism and released their
implementation (NN 2) unchanged in 1996.

See also http://www.nyct.net/~aray/htmlwg/frameprop.html
From what I've heard, pretty much the same thing happened with <img>, when
it was introduced in Mosaic. When the <img src="...">Alternate Markup</img>
syntax was suggested, it was too late. The implementation was already set.

But that was before I was really involved with the web, back when my
employer's IT department was trying to figure out who to charge for the
"excessive bandwidth" used by the cool Mosaic program that everyone was
using...
--
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."

[Brian]

Spartanicus wrote:

Brian wrote:

AIUI, <img> was developed by Mosaic/Netscape, and was already
implemented before anyone could comment. Same for <frames>.

Very different points in time you are referring to here, <img>
preceded frames by some margin.

I didn't write that those two elements were introduced at the same time,
only that they were introduced in a similar fashion, and by (sort of)
the same company.
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.

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.
You've not answered a question from my previous post, 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. Or
more precisely, a few people (at least) pointed out the problems with
frames, Netscape said screw it and put it out anyways, and "upgraded"
their site to it. A few months later, they had a change of heart and
ditched frames on their site, but it was too late on the www at large.

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

[Andrew Fedoniouk]

Lets think about web sites as about applications and
HTML as UI layout declartive language. (I think such assumptions are
reasonable this day)
I mean not just about "tape of paper".

Lets say you would like to design UI of Mozilla browser.
Without frames you will create one page with menu, toolbars, other stuff
and content of the page being browsed.
Imaginable?

1) Each time when you need to reload page you need to recreate your UI in
full. Not a good idea.
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...

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 finally about http:://www.rsdn.ru - it is an application with the
classic multi-view UI.
Each frame there is pretty complex dynamic structure. Frames are definitely
plus for such online apps.

Andrew Fedoniouk.
http://terrainformatica.com

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

On Fri, 27 Aug 2004 06:07:19 GMT, Andrew Fedoniouk
<ne**@terrainformatica.com> wrote:

Russian software developer forum : http://www.rsdn.ru/ (in Russian)
Frames there are doing what they are designed for.

Andrew Fedoniouk.
http://terrainformatica.com

Perhaps you could explain why you think this application of frameset is a
good one? Not knowing a lick of Russian, I can't readily discern the
purpose of your example.

[Lachlan Hunt]

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/

--
Lachlan Hunt
http://www.lachy.id.au/

Please direct all spam to ab***@127.0.0.1
Thank you.

[Leif K-Brooks]

Andrew Fedoniouk wrote:

Lets think about web sites as about applications and
HTML as UI layout declartive language. (I think such assumptions are
reasonable this day)

That's not what HTML is for. Anything which tries to use it that way is
broken.

[Spartanicus]

Brian <us*****@julietremblay.com.invalid> 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.

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.

You've not answered a question from my previous post, 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? Of course I took your comment
as pertaining to the spec.

Your refusal to answer my last question is telling.

--
Spartanicus

[Darin McGrew]

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

1) Each time when you need to reload page you need to recreate your UI in
full. Not a good idea.
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 { ... }
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.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Shin: a device for finding furniture in the dark." - Steven Wright

[Neal]

On Sat, 28 Aug 2004 06:46:59 GMT, Lachlan Hunt
<la**********@lachy.id.au.invalid> wrote:

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

You know, I think you caught one!

Obviously, if it's something we want to boiokmark, frames are a bad
choice. But in this case, you're looking for a simple piece of
information. Much like referring to a big unabridged dictionary, if you're
unlikely to need to read the same entry more than once, and you might want
toaccess several separate pieces of information at one sitting, this type
of frameset setup might be ideal. It's specialized enough that the
"general public" is not going to use it, and if properly done you can make
it work fine for no-frames environments.

Ok, for me, one appropriate use of frameset - organizing a set of data for
rapid reference.

(BTW, the photo example is a close contender. But for that, I see no real
benefit. The only difference between it and a gallery with linked
full-size images is that the latter requires use of the Back button. Since
the original gallery is cached, there's no added internet traffic, and one
could easily open the pics in a new window (as I normally do). So I can't
consider that appropriate - for me of course.)

[Neal]

On Sat, 28 Aug 2004 08:25:37 +0100, Spartanicus <[e-mail]> wrote:

Brian <us*****@julietremblay.com.invalid> 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.

Rather, I think the real truth lies between.

Frames were a proprietery element set originally. They became part of an
HTML "specification" for reasons I don't exactly know. Other elements have
become standard HTML similarly.

I really don't think Brian was seriously suggesting that the W3C is simply
a toady to the big two browsers. Certainly there's plenty of evidence
available to prove that to be an absurd thought.

You've not answered a question from my previous post, 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? Of course I took your comment
as pertaining to the spec.

Your refusal to answer my last question is telling.

Boys, to your corners!

I'd assume frames made it in with at least no dissent. What the actual
tenor of that discussion was, I have no clue.

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.

The purpose of my question was essentially this - regardless of what the
inventors or supporters of this markup think, what applications of
frameset actually check out to be kosher?

Certainly debate other points, but that's the information we need to be
able to understand this bastard markup.