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?

[Nick Kew]

In article <rg***********@ sidious.isolani .co.uk>,
Isofarro <sp*******@spam detector.co.uk> writes:

simplification. Anything "static/global" that uses more than 3Kb of HTML is
a sign of a flawed design.

3Kb can be a lot - as in several minutes additional download time - if
you're on the information dirt-track (as I daresay still exists in places).

--
Nick Kew

[Brian]

Isofarro wrote:

Anything "static/global" that uses more than 3Kb of HTML is a sign of
a flawed design.

3kB seems a bit stingy. The site in sig uses 5kB for many pages, some
more. Or did you mean 3kB for the tags only, with additional kB for the
content?

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

[Neal]

On 3 Sep 2004 05:54:52 -0700, Alan Wood <al*******@cont ext.co.uk> wrote:

I am entitled to my opinion, that frames work for the indexes in the
Compendium. I have lots of happy users who agree with me. I have
received lots of compliments about the indexes, but no complaints.

This statement relies on the assumption that if there is a problem, people
will definitely complain. Perhaps the content is so good no one sees a
need to complain, but they still have usability problems.

I'm not saying you are wrong, merely that your logic is faulty.

[Isofarro]

Brian wrote:

Isofarro wrote:

Anything "static/global" that uses more than 3Kb of HTML is a sign of
a flawed design.

3kB seems a bit stingy. The site in sig uses 5kB for many pages, some
more. Or did you mean 3kB for the tags only, with additional kB for the
content?

Uggg... I meant that the size of the _menu_ (referred to as a static/global
component in a page) should not need to be greater than 3Kb.

IMO, it takes a very specialised site to earn the need for a menu bigger
than 3K. (menu being the just html markup required for the menu).

I wonder if I have this right - TCP/IP is a packet based protocol, if the
data for a menu can be send inside the current page without requiring an
extra packet - the time taken to send the packet is about the same as the
content page without the menu. I seem to recall a typical packet size being
around 4Kb.
--
Isofarro.
FAQ: http://www.html-faq.com/
Recommended Hosting: http://www.affordablehost.com/
isolani: http://www.isolani.co.uk/blog/

[Lauri Raittila]

In article <87************ @dinopsis.dur.a c.uk>, c.********@durh am.ac.uk
says...

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 have done such site - it was not very good idea, as different browser
options made it impossible to use quite easily. Frames don't have
suitable unit to measure sizes of content - px don't work, and neither
does percentage.
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.

Yes, of course If degradation of frames is done well, it is practically
always better than orginal, framed version.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Lauri Raittila]

In article <2p************ @uni-berlin.de>, eu*****@ecritte rs.biz says...

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

No, it is just indication that position:fixed was used in wrong place.
Anything that is supposed to get another scrollbar on page is bad idea.
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.

Bottom:0. It even works on some browsers that aren't IE...
Again, it will degrade nicely on IE, as position:fixed don't work in
that. IMO, position:fixed works best on IE...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>