frames are dead

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
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?

Re: frames are dead

"groovyd" wrote in message
news:3f052019-c1b4-4e2e-8861-c85dc2a54a96@c4g2000hsg.googleg roups.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.
>
> 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
> 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 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

Re: frames are dead

"Vince Morgan" wrote in message
news:4774bce1$0$26468$afc38c87@news.optusnet.com.au...

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

--
Richard.

Re: frames are dead

"groovyd" wrote in message
news:3f052019-c1b4-4e2e-8861-c85dc2a54a96@c4g2000hsg.googleg roups.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?

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?

--
Richard.

Re: frames are dead

"rf" wrote in message
news:eM3dj.28532$CN4.17564@news-server.bigpond.net.au...
>
> "Vince Morgan" wrote in message
> news:4774bce1$0$26468$afc38c87@news.optusnet.com.au...
>
> > 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.
>
> --
> Richard.
>
>
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

Re: frames are dead

"Vince Morgan" wrote in message
news:4774cb8c$0$26468$afc38c87@news.optusnet.com.au...

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

--
Richard.

Re: frames are dead

Gazing into my crystal ball I observed groovyd
writing in news:3f052019-c1b4-4e2e-8861-c85dc2a54a96
@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).


--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Re: frames are dead

In article ,
"rf" wrote:

> "groovyd" wrote in message
> news:3f052019-c1b4-4e2e-8861-c85dc2a54a96@c4g2000hsg.googleg roups.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?
>
> 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.)

--
dorayme

Re: frames are dead

"dorayme" wrote in message
news:doraymeRidThis-D41192.06511229122007@news-vip.optusnet. com.au...

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

--
Richard.

Re: frames are dead

On 2007-12-28, dorayme wrote:
[...]
> 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
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.

Re: frames are dead

In article ,
"rf" wrote:

> "dorayme" wrote in message
> news:doraymeRidThis-D41192.06511229122007@news-vip.optusnet. com.au...
>
> > (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"
> >
....
>
> No contradiction.
>

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

> 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

Re: frames are dead

In article ,
Ben C wrote:

> On 2007-12-28, dorayme wrote:
> [...]
> > 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
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!)

--
dorayme

Re: frames are dead

"dorayme" wrote in message
news:doraymeRidThis-453A91.10514729122007@news-vip.optusnet. com.au...
> In article ,
> "rf" wrote:

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

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

--
Richard.

Re: frames are dead

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

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

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

--
Neredbojias
Riches are their own reward.

Re: frames are dead

In article
,
dorayme wrote:

> In article ,
> Ben C wrote:
>
> > > 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
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.

I took a look this morning and added bits. Thanks for this. I
also mentioned about the
. 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
is, a specialist inline
soldier that gives a peculiar final order: to make the path ahead
instantly disappear. What a responsibility! ]

--
dorayme

Re: frames are dead

On 2007-12-30, dorayme wrote:
> In article
>,
> dorayme wrote:
>
>> In article ,
>> Ben C wrote:
>>
>> > > 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
. 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.)

Re: frames are dead

In article ,
Ben C wrote:

> On 2007-12-30, dorayme wrote:
> > In article
> >,
> > dorayme wrote:
> >
> >> In article ,
> >> Ben C wrote:
> >>
> >> > > 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
. 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.

--
dorayme