Trouble structuring my site

[Ben C]

You're right, this works for me:

body { margin:0; }
div { position:absolute; width:100%; }
#top { height:100px; }
#middle { top:100px; bottom:100px; }
#middle { height:expression(document.body.clientHeight-100); }

That "expression" thing is completely non-standard.

#bottom { height:100px; bottom:0; }
#bottom { margin-top:expression(document.body.clientHeight-100); }

And that one isn't necessary anyway.

Just make middle position absolute as well and give it top: 100px,
bottom: 100px and height: auto.

Make body (or some wrapper div) position: relative, and don't bother
with width:100%. Then you will get the width you want regardless of
margin, padding and borders. Tip: width:100% is rarely necessary, if you
find yourself writing it ask why.

But latching things onto the bottom of the viewport like this doesn't
work well when the viewport is resized. What's the browser supposed to
do? Annoyingly reflow the whole page or leave the "footer" half-way up
the page at its new size?

Much better to let the bottom of the page just be at the bottom. Locate
things only at the top and left (or top and right if it's a rtl page)
and let the right and bottom do what they want.

 

[William Gill]

You have no idea what anyone's browser window look like. Setting a
height in pixels (for anything other than a fixed-size object like
an image) is doomed to failure.

I may be setting myself up here, but I have been wondering. Suppose I
have a fairly small block of text I need to insert on a page like an
insert or sidebar in print. I could a) add a floated div of specific
height (in ems of course) that would be fluid, b) have a text image of
specific dimensions (in its intrinsic pixels). but why couldn't I c)
create a div that I treat like an image using pixels dimensions, but
without the bandwidth hit of the image?

 

[Chris F.A. Johnson]

I may be setting myself up here, but I have been wondering. Suppose I
have a fairly small block of text I need to insert on a page like an
insert or sidebar in print. I could

a) add a floated div of specific height (in ems of course) that
would be fluid,

If you set a height, it might not be enough to contain the text.
If my default is large (as it is), then that text will need more
lines.

b) have a text image of specific dimensions (in its intrinsic
pixels).

You don't know how big that text will appear on my screen. There's
a good chance it will be too small for me to read.

but why couldn't I

c) create a div that I treat like an image using pixels dimensions,
but without the bandwidth hit of the image?

It will almost certainly be too small to contain the text at a
comfortable viewing size (for me, and probably many others).

 

[William Gill]

If you set a height, it might not be enough to contain the text.
If my default is large (as it is), then that text will need more
lines.

My bad. I meant specific WIDTH in order to create the "insert" look,
allowing the height to adjust itself as needed.

You don't know how big that text will appear on my screen. There's
a good chance it will be too small for me to read.

Agreed, that is the inherent risk of graphics based text of any kind,
and a solid argument against them.

It will almost certainly be too small to contain the text at a
comfortable viewing size (for me, and probably many others).

So if I treat the entire block (div) as an image, specifying text size,
div height and width all in pixels, I should be able to have the same
effect as a graphic without the overhead. Theoretically, it could work
just like a graphic, with the same limitations. Of course, those
limitations may render this as a particularly moot point.

Interestingly, there is a tangent to a thread in c.i.w.a.s (Re: Possible
to Change List Bullet Color?) that talks about using non-pixel
dimensions on images (i.e. em's), allowing the user font size controls
to work on the images. This can produce some good and bad effect.

I guess it's just the engineer in me that always wants to see "what
if...?" At eight, I "designed" my first radio by "adapting" the
instructions to the material I had available, and have been doing this
far to many years to just quit now.

Unfortunately, accommodation for my particular disability is not as
direct as controlling text size. I often get so focused on the complex,
that I can miss the (otherwise) obvious.

Thanks for your patience.

 

[Chris F.A. Johnson]

So if I treat the entire block (div) as an image, specifying text size,
div height and width all in pixels, I should be able to have the same
effect as a graphic without the overhead. Theoretically, it could work
just like a graphic, with the same limitations. Of course, those
limitations may render this as a particularly moot point.

If you specify the text size in px, it may be be too small for me
to read (just as with a graphic), or my browser may increase the
size so that it overflows the container and I may not be able to
read it (or any other text that it overwrites).

 

[dorayme]

So if I treat the entire block (div) as an image, specifying text size,
div height and width all in pixels, I should be able to have the same
effect as a graphic without the overhead. Theoretically, it could work
just like a graphic, with the same limitations.

If you have text in a box (not a picture of text), you won't get
much benefit *overhead wise*.

It is almost always best to use html text, and size the box
itself to grow with the text if it threatens to bust out of the
box. You can do this by eming the box if you are dealing with a
box that does not grow naturally to fit the text. You are an
engineer, use the well evolved built-in machines in html...

Interestingly, there is a tangent to a thread in c.i.w.a.s (Re: Possible
to Change List Bullet Color?) that talks about using non-pixel
dimensions on images (i.e. em's), allowing the user font size controls
to work on the images. This can produce some good and bad effect.

Sometimes one can do this with banners and headings to some
effect. But my experiments on this have always disappointed me
when I see the results in IE. If you prepare the images right
(and there are some rules to observe here), it can work
brilliantly in some browsers.

I guess it's just the engineer in me that always wants to see "what
if...?" At eight, I "designed" my first radio by "adapting" the
instructions to the material I had available, and have been doing this
far to many years to just quit now.

Be very careful of this tendency, William, it is a double edged
sword. Here is an example of the tendency and its swordlike
effect:

<http://dorayme.150m.com/jokes/execution.html>

 

[William Gill]

If you have text in a box (not a picture of text), you won't get
much benefit *overhead wise*.

I was looking at ways to keep Kb bloat under control. Even the smallest
text graphic takes a couple Kb. A few characters of text "treated like
a graphic" would only take a few bytes. Think "a CSS button", but not
in the traditional nav bar. Like a notice in the normal text indicating
"the next meeting has been scheduled."

It is almost always best to use html text, and size the box
itself to grow with the text if it threatens to bust out of the
box.

Absolutely no argument there.

Sometimes one can do this with banners and headings to some
effect. But my experiments on this have always disappointed me
when I see the results in IE. If you prepare the images right
(and there are some rules to observe here), it can work
brilliantly in some browsers.



Be very careful of this tendency, William, it is a double edged
sword. Here is an example of the tendency and its swordlike
effect:

Someone much greater than I (Thomas Alva Edison) once said "I have not
failed. I've just found 10,000 ways that won't work." I'm not even half
way there on this, but even the most assiduous seeker must recognize a
poor ROI when he/she sees it. Of course It's still intriguing to
poke around.

 

[dorayme]

I was looking at ways to keep Kb bloat under control. Even the smallest
text graphic takes a couple Kb. A few characters of text "treated like
a graphic" would only take a few bytes.

Sure, if you were tempted to make every heading a pic, every
caption... In many situations, the more significant reasons for
using text rather than pics of text are to do with ease of change
for the author, ease for the user of the website with different
visual or other requirements... I mean, are you making a site
that shows signs of a bloat problem?

 

[William Gill]

... I mean, are you making a site
that shows signs of a bloat problem?

Not particularly, just always watching for ways to keep things fit
and trim. This was more of a theoretical query.

Actually, the about the only time I use a text graphic is for
headings that require some fancy font work. Although one time I put up
a show schedule as a text graphic because the background picture (the
client wanted) made normal text hard to distinguish, so I did a graphic
that allowed me to differentiate text from background without looking
too bad. It was large enough, and simple enough that most could read
it. Probably would have been a good candidate for the em dimension
trick (to allow user control).

 

[julian.bash]

That "expression" thing is completely non-standard.


And that one isn't necessary anyway.

Just make middle position absolute as well and give it top: 100px,
bottom: 100px and height: auto.

Position: absolute and setting bottom- or right-values doesn't work in
ie.

--julian

 

[dorayme]

Not particularly, just always watching for ways to keep things fit
and trim. This was more of a theoretical query.

Actually, the about the only time I use a text graphic is for
headings that require some fancy font work. Although one time I put up
a show schedule as a text graphic because the background picture (the
client wanted) made normal text hard to distinguish, so I did a graphic
that allowed me to differentiate text from background without looking
too bad. It was large enough, and simple enough that most could read
it. Probably would have been a good candidate for the em dimension
trick (to allow user control).

Fair enough. If you ever do em dimming on pics, let us see the
results.