Footer?

[Cerebral Believer]

Hi all,

I would like to know how to get two rows of text links to appear at the
bottom of a page. Generally I have been using <div> tags with the id
attribute and CSS to place blocks of text, tables and images where I want
them to be, but this has got me a little stuck. My HTML code is:

<div id="footer" class="footer">
Home | About | Essays | Discussions | Member Area | Links & Resources |
Contact<p>
Text Only | Alternative Versions | Accessibility | Site Map | Help</div>

My CSS code is:

div#footer {
position : absolute;
left : 132.00pt;
bottom : 0pt;
width : 465.00pt;
align : center;
z-index : 2;
}

Problem is, that the text (lets call it the footer) I am controlling appears
over the top of some other text (actually text in a table) rather than right
at the bottom of the page vertically beneath the table. Also if I resize my
browser window, the "footer" also moves in relation to the bottom of the
browser window rather than staying in a fixed position at the bottom of my
page. The two rows of text I am trying to place at the bottom of my page
even occur as the last two lines of code in my HTML right before the </body>
and </html> tags. So what am I doing wrong here?

Regards,
C.B.

 

[Neredbojias]

With neither quill nor qualm, Cerebral Believer quothed:

Hi all,

I would like to know how to get two rows of text links to appear at the
bottom of a page. Generally I have been using <div> tags with the id
attribute and CSS to place blocks of text, tables and images where I want
them to be, but this has got me a little stuck. My HTML code is:

<div id="footer" class="footer">
Home | About | Essays | Discussions | Member Area | Links & Resources |
Contact<p>
Text Only | Alternative Versions | Accessibility | Site Map | Help</div>

My CSS code is:

div#footer {
position : absolute;
left : 132.00pt;
bottom : 0pt;
width : 465.00pt;
align : center;
z-index : 2;
}

Problem is, that the text (lets call it the footer) I am controlling appears
over the top of some other text (actually text in a table) rather than right
at the bottom of the page vertically beneath the table. Also if I resize my
browser window, the "footer" also moves in relation to the bottom of the
browser window rather than staying in a fixed position at the bottom of my
page. The two rows of text I am trying to place at the bottom of my page
even occur as the last two lines of code in my HTML right before the </body>
and </html> tags. So what am I doing wrong here?

It sounds like you want the "footer" _either_ at the bottom of the page
or at the bottom of the viewport, whichever is "lower". If you simply
want it at the bottom of the page, don't position it.

 

[Toby Inkster]

So what am I doing wrong here?

1. You're using absolute positioning. (There are only a very few
situations when absolute positioning is needed, and if you use it,
you *really* need to know what you're doing.)

2. You're specifying lengths using points as a unit. (Points are
only really appropriate for print--and probably embossed--media.)

 

[Cerebral Believer]

With neither quill nor qualm, Cerebral Believer quothed:


It sounds like you want the "footer" _either_ at the bottom of the page
or at the bottom of the viewport, whichever is "lower". If you simply
want it at the bottom of the page, don't position it.

Hi,

I tried the idea of not positioning it, and removed the <div> tags, this
made the footer shoot to the top of the page. Forgive my ignorance, I could
be way off base here, I am a learner, but if I remember what I read on the
w3org site correctly, if everything else is on a page is positioned using
<div> & stylesheets, and I have one item on the page which is not positioned
using the same methond, even though that item appears last in the HTML code,
will that item appear by default at the top of the page because the other
items are removed from the "document flow".

It really is my intention to control everything by <div> & CSS so that I can
adjust elements site-wide through simple changes in the relevant
stylesheets, rather than having to modify each page individually.

Regards,
C.B.

 

[Cerebral Believer]

1. You're using absolute positioning. (There are only a very few
situations when absolute positioning is needed, and if you use it,
you *really* need to know what you're doing.)

I noticed that my other options were, Fixed | Relative | Static, I have
tried all of those, and sometimes the item ("footer") just dissapears
completely. What would you suggest is the best method of positioning seeing

2. You're specifying lengths using points as a unit. (Points are
only really appropriate for print--and probably embossed--media.)

Do you know any point to pixel convertors?

Regards,
C.B.

 

[Steve Pugh]

Do you know any point to pixel convertors?

Depends entirely on settings on the individual's user's computers.
However, for many users 1pt = 1 1/3 pixels. But if you are defining
text sizes or anything that is impacted by text sizes (e.g. line
heights, the heights of boxes containing text, etc.) then pixels are
an equally bad idea as points.

Steve

 

[Neredbojias]

With neither quill nor qualm, Cerebral Believer quothed:

Hi,

I tried the idea of not positioning it, and removed the <div> tags, this
made the footer shoot to the top of the page. Forgive my ignorance, I could
be way off base here, I am a learner, but if I remember what I read on the
w3org site correctly, if everything else is on a page is positioned using
<div> & stylesheets, and I have one item on the page which is not positioned
using the same methond, even though that item appears last in the HTML code,
will that item appear by default at the top of the page because the other
items are removed from the "document flow".

Yes, that is true with absolute or fixed positioning. However, I've
never seen a page where _everything_ in it was so positioned.

It really is my intention to control everything by <div> & CSS so that I can
adjust elements site-wide through simple changes in the relevant
stylesheets, rather than having to modify each page individually.

You may want to rethink that strategy and, especially, make your page
more fluid or you'll probably run into more problems akin to the footer
one.

And as for the footer prob, perhaps you can put the footer container
inside the last/lowest of your other containers (which you said are all
positioned) and position it below the final other content.

 

[Carolyn Marenger]

Do you know any point to pixel convertors?

Points are a unit of measure commonly used in the print industry. If I
remember correctly, 72 points equals one inch.

Pixels have to do with screen resolution, and their size varies monitor to
monitor. I seem to remember calibrating my monitor a few years ago and
having a pixel height and width of 1/83rd and 1/87th of an inch. That was
at 1024x768 resolution resolution, with the picture stretched to the edges
of my monitor. I now view at 1280x1024 on each of my two monitors, so my
pixels have shrunk by about 20%. On the other hand, I do occasionally
change my resolution to 800x600 just so I can view a site in a much smaller
viewport. At that point, my pixel size is about 20% larger.

In other words, converting point to pixels is about as easy as going for a
fifteen kilogram drive. You may be able to figure out the measurements
specific to your monitor and create the formula for your specific
situation, but it will only be a very rough guide for the rest of us.

Carolyn

 

[Toby Inkster]

I noticed that my other options were, Fixed | Relative | Static, I have
tried all of those, and sometimes the item ("footer") just dissapears
completely.

For the vast majority of things, static is what you want. Relative can be
handy *occasionally*.

You can then use the natural flow of HTML, combined with "float" for most
positioning purposes.

 

[Jim Moe]

I noticed that my other options were, Fixed | Relative | Static, I have
tried all of those, and sometimes the item ("footer") just dissapears
completely. What would you suggest is the best method of positioning seeing
as all my other page content is positioned using <div> & CSS.

Without an URL showing your test case it is hard to give useful suggestions.

Do you know any point to pixel convertors?

ROTFL!
Use % for font sizes, and specifically 100% for the main content font size.
Use EMs for spacing around text.
This way your site adapts to the visitor's preferences, settings and
equipment.

 

[kchayka]

Yes, that is true with absolute or fixed positioning. However, I've
never seen a page where _everything_ in it was so positioned.

You should get out more.

I've seen plenty of such pages. If not viewed in the same browsing
environment as the designer, they tend to be a disaster.

 

[Alan J. Flavell]

Points are a unit of measure commonly used in the print industry.
If I remember correctly, 72 points equals one inch.

CSS size units are set out in detail in the CSS specification[1], it
isn't really necessary to have a good memory.[2]

Pixels have to do with screen resolution, and their size varies
monitor to monitor.

Indeed. However, the CSS px units as defined in the CSS specification
aren't (necessarily) physical pixels - they are *supposed* to be
adjusted to the physical resolution, and other parameters, of the
viewing situation.

The important points (no pun intended) to keep in mind are:

1) neither pt units nor px units are, in fact, calibrated on typical
user displays, so you can ask for them till you're blue in the face,
but you'll only get what the user's display was set up to show.

2) Even if pt or px units *were* calibrated, they wouldn't be what the
user wants, since they make no allowances for their viewing
preferences, eyesight etc.

And a secondary point is that MSIE makes it rather difficult for users
to scale text to their preferences, if the author has specified the
size in px or pt units. That alone would be a good reason to avoid
them, even if the other considerations didn't go against them already.

So, the bottom line is that the right choice of units for general WWW
work is em or percent, based on the user's choice of size, whatever
that might be. It meets all of the right criteria, except for those
annoying people who refuse to make their choice of font size and keep
complaining (typically) that it's too large - see
http://css.nu/articles/font-analogy.html

pt units might be useful specifically for print media; whereas
(properly-scaled) px units might be good for a collective viewing
situation (e.g projection), where individual users don't get to adjust
the display to their preferences.

Coming back to the original question, which you were aiming to answer:
the whole purpose of having different sizing systems is so that they
can behave differently when the viewing situation is varied.
Consequently, there can be no straightforward lookup table to convert
from one to another.

regards

[1] Although in theory CSS 2.1 is still a "working draft", it's the
closest thing we have to the current state of affairs, so I'll cite it
here instead of being too pedantic:
http://www.w3.org/TR/CSS21/syndata.html#length-units

The CSS px unit - like it or not - isn't simply a pixel, but is based
on an angle subtended at the typical viewing distance, as is depicted
there in the spec. One might argue it would have been better to call
it something else than a px, to avoid confusion; but what's done is
done, as far as specifying it is concerned. *Implementing* it is a
different matter, though.

[2] Historically, there have been several different "point" units, but
as you rightly say, the one used in this context is 1/72nd of an inch.

 

[dorayme]

except for those
annoying people who refuse to make their choice of font size and keep
complaining (typically) that it's too large - see
http://css.nu/articles/font-analogy.html

The analogy is good to illustrate an issue. One problem, of
course, is that these "annoying" people are not as familiar with
the text size controls on browsers as they are with volume
controls on radios. Yes, there are misguided idea about web
viewing but perhaps more education on text controls would help
steer folk towards more cluey ways of seeing things. Everyone
knows that command c or its equivalent in Windows, control c is
copy. This is taught at a basic level. Not so the controls for
browsers.

Why, I don't think there is even a completely standard keyboard
way across all browsers. On a Mac, command + or - in a few
browsers, in iCab it is not even this or it does not work well. I
think it would help greatly for there to be a consistent key
control for this, widely taught. An easy key combination. This
would be do more than educating directly about the differences of
the browser experience from the reading print one.

 

[Neredbojias]

With neither quill nor qualm, kchayka quothed:

You should get out more.

Yeah, I hear that a lot.

I've seen plenty of such pages. If not viewed in the same browsing
environment as the designer, they tend to be a disaster.

Oh, woe is me... What ever happened to the goal (and ideal) of fluid
design? Yes, I know, "everyone" wants their web page to be like a page
in a magazine. <sigh>

 

[Alan J. Flavell]

The analogy is good to illustrate an issue. One problem, of course,
is that these "annoying" people are not as familiar with the text
size controls on browsers as they are with volume controls on
radios.
Right...

Yes, there are misguided idea about web viewing but perhaps more
education on text controls would help steer folk towards more cluey
ways of seeing things.

Absolutely. Which is why I'm so strongly opposed to those web sites
which insist on implementing their own site-specific text size
adjustment feechers - which, if they work at all, work only on that
specific site and none other, so the user's time and effort is wasted
without ever getting nearer to the real answer, which would work on
every site.

Why, I don't think there is even a completely standard keyboard
way across all browsers.

Since there isn't a standard keyboard, that isn't entirely surprising.

But some users, particularly naive users, prefer menus anyway, and
most of the common web-compatible browsers have both (with the
keyboard shortcut often mentioned on the menu). So they could start
with the menus, and then migrate to keyboard shortcuts as they gained
confidence.

Some browsers also offer other ways of doing these things, such as
ctrl/mousewheel (that's Opera and Firefox, to name two).

I'm not sure where the right compromise lies, between trying to
spoonfeed users in every detail (and maybe confusing them by showing
them instructions for the wrong browser or the wrong OS), or simply
encouraging them to seek out the controls, on appropriate menus or
help information that their browser makes available anyway, and get on
and use them.

Poley offers a modest link from his main page:

http://www.xs4all.nl/~sbpoley/webmatters/index.html
to a tutorial-ish page
http://www.xs4all.nl/~sbpoley/main/adjust.html

which seems a reasonable compromise, but I'm still concerned that a
naive user of only a single browser might find themselves overwhelmed
with detail here. Whereas the menus and help information for their
own browser are surely going to contain what they need (at this
level), and not confuse them with detail about other browsers and
OSes.

Admittedly that may not go as far as showing them how (in appropriate
browsers) to protect themselved from microfonts by setting a minimum
font size. But as that's only available in a sub-set of browsers,
should it be mentioned in such a generally-applicable page?

So, as I say, I don't really know where the best compromise lies.

 

[dorayme]

Since there isn't a standard keyboard, that isn't entirely surprising.

I agree with much of what you said that is snipped... As for
keyboards, well, I was really making a point about basic computer
education. The different keyboards mostly all accommodate the
universally known copy and paste routines. I was just reflecting
on a way of getting better appreciation of the idea of "the
browser text size is yours to adjust" via a serious attempt to
get a simple universal key combination going (as with copy).

 

[kchayka]

With neither quill nor qualm, kchayka quothed:


Yes, I know, "everyone" wants their web page to be like a page
in a magazine. <sigh>

It's not just graphic designer types who are the cause of such ishy web
pages. Blame also goes to authoring tools that foolishly claim Joe
Newbie can make a pixel-perfect design without knowing any HTML. There's
a huge amount of that going on, too. :-(

 

[Neredbojias]

With neither quill nor qualm, kchayka quothed:

It's not just graphic designer types who are the cause of such ishy web
pages. Blame also goes to authoring tools that foolishly claim Joe
Newbie can make a pixel-perfect design without knowing any HTML. There's
a huge amount of that going on, too. :-(

That's why I've always been an anti-fan of Dreamweaver (-not to mention
FP.) But part of the problem is the newbie, or some newbies, anyway.
They don't want to learn; they want to cut-and-paste. Reminds me of
friggin' kindergarten.

 

[Cerebral Believer]

For the vast majority of things, static is what you want. Relative can be
handy *occasionally*.

You can then use the natural flow of HTML, combined with "float" for most
positioning purposes.

Toby,

Thanks I will look into this positioning stuff a little more closely.

Regards,
C.B.

 

[Cerebral Believer]

With neither quill nor qualm, Cerebral Believer quothed:


Yes, that is true with absolute or fixed positioning. However, I've
never seen a page where _everything_ in it was so positioned.


You may want to rethink that strategy and, especially, make your page
more fluid or you'll probably run into more problems akin to the footer
one.

And as for the footer prob, perhaps you can put the footer container
inside the last/lowest of your other containers (which you said are all
positioned) and position it below the final other content.

Thanks, I'll look into those options that you have outlined. I also am
using tables to structure my main body of text for each page. I may just
end up sticking the footer in the bottom row of the table, or is that a dumb
newbie thing to do? The couse I am studying suggests that it is not a good
idea to use tables to structure whole web pages, I wonder if that applies to
text blocks as an "element" of a web page?

Regards,
C.B.