frames are dead

[groovyd]

everyone keeps telling me that frames are dead and so i feel the need
to finally rewrite my 'dead' site (www.groovydomain.com) so that it
doesn't use them by somehow crafting some slick CSS that the same
everyones are telling me is the new 'fashionable' way.

the problem is everytime i try i get something that almost works on IE
but not firefox or vice-versa. it seems that browsers have not yet
standardized on alot of the CSS stuff. and even in the best cases i
just cannot seem to get the same behavior as the site has using the
frames. I have spent days trying all sorts of hackery to no success
and in any case it all looks hopelessly more complex and convoluted
then the code does using frames. The goal is not to change the look
or behavior of the site at all other then just replacing the <frames>
definitions with some CSS and the minimal # of DIVs. (ie. when
scrolling the main frame i dont want to scroll the menu or the logo.
also the words should wrap when someone resizes their window so you
can still read the story without having to scroll left and right.)

Words of wisdom anyone?

 

[Vince Morgan]

everyone keeps telling me that frames are dead and so i feel the need
to finally rewrite my 'dead' site (www.groovydomain.com) so that it
doesn't use them by somehow crafting some slick CSS that the same
everyones are telling me is the new 'fashionable' way.

the problem is everytime i try i get something that almost works on IE
but not firefox or vice-versa. it seems that browsers have not yet
standardized on alot of the CSS stuff. and even in the best cases i
just cannot seem to get the same behavior as the site has using the
frames. I have spent days trying all sorts of hackery to no success
and in any case it all looks hopelessly more complex and convoluted
then the code does using frames. The goal is not to change the look
or behavior of the site at all other then just replacing the <frames>
definitions with some CSS and the minimal # of DIVs. (ie. when
scrolling the main frame i dont want to scroll the menu or the logo.
also the words should wrap when someone resizes their window so you
can still read the story without having to scroll left and right.)

Words of wisdom anyone?

I am currently redesigning a site that has been using frames similar to your
own. http://www.labtek.com.au
The new site is in the process of contruction and as such not all links etc
are complete, however it is meant to emulate frames to some extent and could
be of interest to you. http://www.labtek.com.au/newsite/main.php
If you pull up the source you will notice there are some conditional links
below the </style> tag to handle a couple of IE nonconformances. This
appears to be a reasonable way to handle them, and your code will still
validate. By the way, the validation links below don't work currently as I
have changed the path since they were added. Well, not the css one anyway.
Please don't tell me some things aren't working, I already know : )
HTH
Vince

 

[rf]

http://www.labtek.com.au/newsite/main.php

Unusable at canvas width less than about 800 pixels (read mobile phones
etc). No horizontal scroll bar.

Does quite bizarre things when I increase my font size.

 

[rf]

everyone keeps telling me that frames are dead and so i feel the need
to finally rewrite my 'dead' site (www.groovydomain.com) so that it
doesn't use them by somehow crafting some slick CSS that the same
everyones are telling me is the new 'fashionable' way.

Words of wisdom anyone?

Don't try to "emulate" the existing frame site, you will create more
usability and accessibility problems than you need. Specifically, do not be
tempted to use overflow: scroll on anything. Redesign the site from scratch.

Code to the standard, testing in a modern browser like Firefox. Check
occasionally with IE to make sure that crippled browser still displays
correctly.

Where is your best effort so far?

 

[Vince Morgan]

Unusable at canvas width less than about 800 pixels (read mobile phones
etc). No horizontal scroll bar.

Does quite bizarre things when I increase my font size.

The content of that main page has been planted there from the original sight
and is not going to be in the finished page. That is where the resizing
prolbem should show up.
When discussing (considerabley) the site, the management wanted this layout,
and when the issue of mobiles, etc was raized they made the case that it's
not their market at all, and they couldn't care less what it looks like on
portable devices, other than laptops.
Ultimately, it's their site, their business, and they thought the notion
that it should work on mobiles PDA's etc as humerous.
Regards,
Vince

 

[rf]

Ultimately, it's their site, their business, and they thought the notion
that it should work on mobiles PDA's etc as humerous.

I guess you have to humour them if they want to throw away a certain
percentage of their potential business

 

[Adrienne Boswell]

Gazing into my crystal ball I observed groovyd <[email protected]>
writing in @c4g2000hsg.googlegroups.com:

everyone keeps telling me that frames are dead and so i feel the need
to finally rewrite my 'dead' site (www.groovydomain.com) so that it
doesn't use them by somehow crafting some slick CSS that the same
everyones are telling me is the new 'fashionable' way.

Words of wisdom anyone?

As others have said, don't try to recreate the frames. Use server side
includes and stick to standards.

OT - when I went to look at your site, my 4 year old was sitting on my
lap, and insisted that we look at most of your videos. His comment was
"that's all the sound?" - but he did enjoy watching them (we watched the
first 6 movies).

 

[dorayme]

Don't try to "emulate" the existing frame site, you will create more
usability and accessibility problems than you need. Specifically, do not be
tempted to use overflow: scroll on anything. Redesign the site from scratch.

Yes, grab the opportunity to do something different.

But it is not all that hard to emulate frames and avoid creating
more usability and accessibility problems than you need. OP's
site is simple enough. Float the menu left. Repeat it and the
header on each page and like that. There are not that many pages.
He can use includes or not, it does not matter here.


-----------------
(btw, what caught my eye in your remarks, rf, was you saying,
above,

"do not be tempted to use overflow: scroll on anything"

because, your words in another thread were still ringing in my
ears:

"I usually however use overflow: scroll"

I looked into these remarks of yours yesterday in another
connection and I think I learnt something. I was tinkering with
and advancing my little story telling project at
http://netweaver.com.au/floatHouse/ Sure, it was in another
context and I am not saying you are contradicting yourself, keep
your shirt on. What you and especially Ben said about overflow
was most interesting to me.)

 

[rf]

(btw, what caught my eye in your remarks, rf, was you saying,
above,

"do not be tempted to use overflow: scroll on anything"

because, your words in another thread were still ringing in my
ears:

"I usually however use overflow: scroll"

I looked into these remarks of yours yesterday in another
connection and I think I learnt something. I was tinkering with
and advancing my little story telling project at
http://netweaver.com.au/floatHouse/ Sure, it was in another
context and I am not saying you are contradicting yourself, keep
your shirt on. What you and especially Ben said about overflow
was most interesting to me.)

No contradiction.

Case 1. Use overflow:scroll to simulate the behaviour of a frame (or an
iframe) where one *knows* the height (and possibly width) of the container
is specified, usually to the dimensions of the viewport, just like frames
are and one knows there *will* be scroll bars.

Case 2. Use overflow scroll to entrap floated decendants, where one does
*not* specify the height or width of the container, thus allowing it to grow
to the size of its content and where one fervently hopes there *will not* be
any scroll bars, except in extreme circumstances.

We would not be using case 2 if there were other more direct ways of
obtaining the result.

 

[Ben C]

I looked into these remarks of yours yesterday in another
connection and I think I learnt something. I was tinkering with
and advancing my little story telling project at
http://netweaver.com.au/floatHouse/

One small inaccuracy or ambiguity there: you say 'there is a way to
force inline (and other) materials to clear the bottom of floats: via
the css instruction called "clear"'.

Since CSS 2.1, you can only actually set clear on block-level things
(although I think in CSS 2 you could set it on inlines). Maybe by "via"
you meant the inlines go in another block-level element on which you've
set clear, which is what the examples show, but perhaps it's not, er,
clear.

An exception is made for <br> which is display: inline and on which the
clear property does work in browsers. Although technically a violation
of CSS 2.1, it would be a bit strange to allow the HTML clear attribute
but not the CSS clear property so I think that's why they do it.

 

[dorayme]

....

No contradiction.

True. Words that ring in ears out of context can be mere triggers

Case 2. Use overflow scroll to entrap floated decendants, where one does
*not* specify the height or width of the container, thus allowing it to grow
to the size of its content and where one fervently hopes there *will not* be
any scroll bars, except in extreme circumstances.

We would not be using case 2 if there were other more direct ways of
obtaining the result.

There is overflow: auto and hidden and at some stage I would not
mind you expanding on why you prefer "scroll" over "auto". But I
guess this thread is not the right one.

At http://netweaver.com.au/floatHouse/page8.html I end with your
suggestion but it looks not to be as good as "auto". But my mind
is quite open on all of this. It's quite interesting. Depending
on what I learn or think in coming weeks, I might make an
appendix to page 8 to go into it a bit.

 

[dorayme]

One small inaccuracy or ambiguity there: you say 'there is a way to
force inline (and other) materials to clear the bottom of floats: via
the css instruction called "clear"'.

Since CSS 2.1, you can only actually set clear on block-level things
(although I think in CSS 2 you could set it on inlines). Maybe by "via"
you meant the inlines go in another block-level element on which you've
set clear, which is what the examples show, but perhaps it's not, er,
clear.

An exception is made for <br> which is display: inline and on which the
clear property does work in browsers. Although technically a violation
of CSS 2.1, it would be a bit strange to allow the HTML clear attribute
but not the CSS clear property so I think that's why they do it.

Thanks. I was meaning the css clear on other block level
elements. But perhaps I better make this clearer when I next take
a look.

(Till not that long ago I was consulting my offline CSS 2 for
info till you pointed out in some thread that it is better to be
consulting the CSS 2.1. I have now forgotten all about 2!)

 

[rf]

There is overflow: auto and hidden and at some stage I would not
mind you expanding on why you prefer "scroll" over "auto". But I
guess this thread is not the right one.

Hmmm. I have absolutely no idea why I am talking about overflow: scroll. I
also have absolutely no idea why in the "other thread" I mentioned overflow:
scroll.

In all cases I mean overflow: auto; and, yes, in all my code I do in fact
use overflow: auto;. Overflow: scroll; *always* produces scroll bars which,
in establishing a new block formatting context, is neither needed nor
wanted. Overflow: auto; is the one we should be using. As stated above it
would be better if there were some more formal method of establishing the
new context, rather than a side effect of a totally unrelated property.

Must have been a brain fart during all previous posts

Now, to restate my original statement in this thread: Don't be tempted to
use overflow: auto; or overflow: scroll; to emulate frames.

Yep. That's better

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Sat, 29 Dec 2007 02:02:26
GMT rf scribed:

Hmmm. I have absolutely no idea why I am talking about overflow:
scroll. I also have absolutely no idea why in the "other thread" I
mentioned overflow: scroll.

In all cases I mean overflow: auto; and, yes, in all my code I do in
fact use overflow: auto;. Overflow: scroll; *always* produces scroll
bars which, in establishing a new block formatting context, is neither
needed nor wanted. Overflow: auto; is the one we should be using. As
stated above it would be better if there were some more formal method
of establishing the new context, rather than a side effect of a
totally unrelated property.

Must have been a brain fart during all previous posts

....Or old age. I would have guessed the latter.

 

[dorayme]

One small inaccuracy or ambiguity there: you say 'there is a way to
force inline (and other) materials to clear the bottom of floats: via
the css instruction called "clear"'.

Since CSS 2.1, you can only actually set clear on block-level things
(although I think in CSS 2 you could set it on inlines). Maybe by "via"
you meant the inlines go in another block-level element on which you've
set clear, which is what the examples show, but perhaps it's not, er,
clear.

An exception is made for <br> which is display: inline and on which the
clear property does work in browsers. Although technically a violation
of CSS 2.1, it would be a bit strange to allow the HTML clear attribute
but not the CSS clear property so I think that's why they do it.

Thanks. I was meaning the css clear on other block level
elements. But perhaps I better make this clearer when I next take
a look.[/QUOTE]

I took a look this morning and added bits. Thanks for this. I
also mentioned about the <br>. I did not go into why there was an
exception but thanks for reminding me about the probable reason.

[What a strange little thing a <br> is, a specialist inline
soldier that gives a peculiar final order: to make the path ahead
instantly disappear. What a responsibility! <g>]

 

[Ben C]

http://netweaver.com.au/floatHouse/

[...]
Thanks. I was meaning the css clear on other block level
elements. But perhaps I better make this clearer when I next take
a look.

I took a look this morning and added bits. Thanks for this. I
also mentioned about the <br>. I did not go into why there was an
exception but thanks for reminding me about the probable reason.

One more thing, you say "block formatting element", which is in italics
as if it were a technical term, but it's not one I've heard. The more
common expression is "block-level element" which is defined in the spec
as various things and is what you mean here (divs and paragraphs etc.)

 

[dorayme]

http://netweaver.com.au/floatHouse/ [...]
Thanks. I was meaning the css clear on other block level
elements. But perhaps I better make this clearer when I next take
a look.

I took a look this morning and added bits. Thanks for this. I
also mentioned about the <br>. I did not go into why there was an
exception but thanks for reminding me about the probable reason.

One more thing, you say "block formatting element", which is in italics
as if it were a technical term, but it's not one I've heard. The more
common expression is "block-level element" which is defined in the spec
as various things and is what you mean here (divs and paragraphs etc.)

It should be "block-level element" and it is now. Thanks.