Font Size fails in Opera 7.23

In Opera 7.23 I am unable to control the font sizes in sideBar and topBar divs.
No problem in MSIE 6 or Mozilla
The pertinent css is: (I've tried many variations)

A { FONT: 90% Arial, helvetica, sans-serif; }
A:LINK { BACKGROUND: #ffffff; COLOR: #0000cc; FONT: 80% Arial,helvetica,sans-serif;}
A:VISITED { BACKGROUND: #fcfcf0; COLOR: #6666cc; FONT: 80% Arial,helvetica,sans-serif;}
A:HOVER { BACKGROUND: #666633; COLOR: #ffffff; FONT: 80% Arial,helvetica,sans-serif;}
A:ACTIVE { BACKGROUND: #000099; COLOR: #ff0000; FONT: 80% Arial,helvetica,sans-serif;}

#sideBar A { FONT: 70% ; }
#topBar A: { FONT-SIZE: 50% ; }

The page is http://masonc.home.netcom.com/1index.html

"4.01 Transistional" (Quirks: necessary for fixed positions in MSIE)

Mason C

MasonC <masonc (AT) ix (DOT) netcom.XYZcom> wrote:

In Opera 7.23 I am unable to control the font sizes in sideBar and topBar
divs.[...]
The page is http://masonc.home.netcom.com/1index.html

Check the minimum font size specified in your copy of Opera. Your specified
font sizes invoked my minimum font size.

You're using relative font sizes, but the whole page seems much smaller
when I drop the minimum font size. Start with 100% for normal text, and
only go smaller for legalese and similar fine print that the average reader
can safely ignore.
--
Darin McGrew, mcgrew (AT) stanfordalumni (DOT) org, http://www.rahul.net/mcgrew/
Web Design Group, darin (AT) htmlhelp (DOT) com, http://www.HTMLHelp.com/

"What is the use of running when you are not on the right road?"

On Mon, 12 Apr 2004 05:59:50 GMT, MasonC <masonc (AT) ix (DOT) netcom.xyz.com>
wrote:

In Opera 7.23 I am unable to control the font sizes in sideBar and topBar divs.
No problem in MSIE 6 or Mozilla
The pertinent css is: (I've tried many variations)

A { FONT: 90% Arial, helvetica, sans-serif; }
A:LINK { BACKGROUND: #ffffff; COLOR: #0000cc; FONT: 80% Arial,helvetica,sans-serif;}
A:VISITED { BACKGROUND: #fcfcf0; COLOR: #6666cc; FONT: 80% Arial,helvetica,sans-serif;}
A:HOVER { BACKGROUND: #666633; COLOR: #ffffff; FONT: 80% Arial,helvetica,sans-serif;}
A:ACTIVE { BACKGROUND: #000099; COLOR: #ff0000; FONT: 80% Arial,helvetica,sans-serif;}

#sideBar A { FONT: 70% ; }
#topBar A: { FONT-SIZE: 50% ; }

The CSS spec (5.11.3) permits user agents to ignore size changes in
pseudo-classes. (They aren't a good idea anyway.) Better to put the size
only in your DIV or A rules, and not A:LINK etc.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

On Mon, 12 Apr 2004, Stephen Poley wrote:

On Mon, 12 Apr 2004 05:59:50 GMT, MasonC <masonc (AT) ix (DOT) netcom.xyz.com
wrote:

The CSS spec (5.11.3) permits user agents to ignore size changes in
pseudo-classes.

Well, indeed: re-flowing links in response to size changes can (in the
most extreme cases) make them literally unusable, since hovering over
them causes them to leap out of reach.

(They aren't a good idea anyway.) Better to put the size
only in your DIV or A rules, and not A:LINK etc.

Links to be 80% of my chosen normal font size? Would not be my
choice.

But I can't help worrying that this is a mere detail, amongst a whole
minefield of self-imposed problems created by the author.

http://jigsaw.w3.org/css-validator/v...ermedium=al l

I don't think I'd want to put my page at the whim of each and every
browser's CSS error fixup routines. On the whole, this page seems to
me to work better on Lynx (with some reservations [1]) than it does on
the CSS-enabled browsers that I tried (e.g it's close to provoking the
cry of "aaaaargh microfonts" on my office machine, unless I rescue it
with the browser's min font size setting).

[1] OK, the next point is not a stylesheet issue; but it's not nice to
present all users with what appear to be navigation selections that
don't in fact work without Javascript (if one's determined to use
some - optional - javascript navigation, then one could inject the
optional navigation into the document with Javascript, so that it
isn't seen by security-conscious users).

On Mon, 12 Apr 2004 07:35:50 +0000 (UTC), Darin McGrew <mcgrew (AT) stanfordalumni (DOT) org> wrote:

MasonC <masonc (AT) ix (DOT) netcom.XYZcom> wrote:
In Opera 7.23 I am unable to control the font sizes in sideBar and topBar
divs.[...]
The page is http://masonc.home.netcom.com/1index.html

Check the minimum font size specified in your copy of Opera. Your specified
font sizes invoked my minimum font size.

ARGHHHHHHHHHHH ! I knew that I knew that I knew that
I forgot that I forgot that I forgot that damn

You're using relative font sizes, but the whole page seems much smaller
when I drop the minimum font size. Start with 100% for normal text, and
only go smaller for legalese and similar fine print that the average reader
can safely ignore.

My intention. Thanks for reminding me of Opera's minimimum font

Mason C

On Mon, 12 Apr 2004 12:48:29 +0100, "Alan J. Flavell" <flavell (AT) ph (DOT) gla.ac.uk> wrote:

On Mon, 12 Apr 2004, Stephen Poley wrote:

On Mon, 12 Apr 2004 05:59:50 GMT, MasonC <masonc (AT) ix (DOT) netcom.xyz.com
wrote:

The CSS spec (5.11.3) permits user agents to ignore size changes in
pseudo-classes.

Well, indeed: re-flowing links in response to size changes can (in the
most extreme cases) make them literally unusable, since hovering over
them causes them to leap out of reach.

(They aren't a good idea anyway.) Better to put the size
only in your DIV or A rules, and not A:LINK etc.

Links to be 80% of my chosen normal font size? Would not be my
choice.

Arial is larger than Times, hence the size reduction. Not a great
idea. I think I'll stick with one font for text and links.

But I can't help worrying that this is a mere detail, amongst a whole
minefield of self-imposed problems created by the author.

Self-imposed because I really want the fixed sideBar and topBar and

MSIE (world's browser) won't do them without this javascript trick..

http://jigsaw.w3.org/css-validator/v...ermedium=al l

I don't think I'd want to put my page at the whim of each and every
browser's CSS error fixup routines. On the whole, this page seems to
me to work better on Lynx (with some reservations [1]) than it does on
the CSS-enabled browsers that I tried (e.g it's close to provoking the
cry of "aaaaargh microfonts" on my office machine, unless I rescue it
with the browser's min font size setting).

[1] OK, the next point is not a stylesheet issue; but it's not nice to
present all users with what appear to be navigation selections that
don't in fact work without Javascript (if one's determined to use
some - optional - javascript navigation, then one could inject the
optional navigation into the document with Javascript, so that it
isn't seen by security-conscious users).

The menus of links are a convenience, not a necessity. They duplicate
the links in the Table of Contents. For those viewers without
javascript they are passive reminders of the contents.

I'm workin' on it workin' workin'

Thanks for the help -- really!

Mason C

On Tue, 13 Apr 2004, MasonC wrote:

Arial is larger than Times, hence the size reduction.

Arial also looks *smaller* than Verdana, which is -so- popular that
some readers will surely have chosen it as their default. This one
can't be won, not with the available features of current CSS.

But I can't help worrying that this is a mere detail, amongst a whole
minefield of self-imposed problems created by the author.

Self-imposed because I really want the fixed sideBar and topBar and
MSIE (world's browser) won't do them without this javascript trick..

Does that explain a shedload of invalid CSS?

http://jigsaw.w3.org/css-validator/v...ermedium=al l

I don't think I'd want to put my page at the whim of each and every
browser's CSS error fixup routines.

I still don't think I'd want to do that.

Good luck.

On Tue, 13 Apr 2004 08:35:37 +0100, "Alan J. Flavell" <flavell (AT) ph (DOT) gla.ac.uk> wrote:

On Tue, 13 Apr 2004, MasonC wrote:

Arial is larger than Times, hence the size reduction.

Arial also looks *smaller* than Verdana, which is -so- popular that
some readers will surely have chosen it as their default. This one
can't be won, not with the available features of current CSS.

But I can't help worrying that this is a mere detail, amongst a whole
minefield of self-imposed problems created by the author.

Self-imposed because I really want the fixed sideBar and topBar and
MSIE (world's browser) won't do them without this javascript trick..

Does that explain a shedload of invalid CSS?

In fact, yes. Only two minor errors -- 97 less than a "shedload."

Scrollbar colors and the javascript expression work well but are not
recognized by jigsaw. This accounts for the other "errors."

Thanks for the comments -- all are valuable. I'm learning.

Mason C

http://jigsaw.w3.org/css-validator/v...ermedium=al l

I don't think I'd want to put my page at the whim of each and every
browser's CSS error fixup routines.

I still don't think I'd want to do that.

Good luck.

On Tue, 13 Apr 2004, MasonC wrote:

Does that explain a shedload of invalid CSS?

In fact, yes. Only two minor errors

As far as client agents are concerned, your deliberate errors are
liable to be treated just as much as errors as your inadvertent ones
are.

Scrollbar colors and the javascript expression work well

....for some values of "work"...

but are not recognized by jigsaw.

That's not the point. Jigsaw is only informing you and us that
they are not part of official CSS.

This accounts for the other "errors."

Sure, I wasn't unaware of that; my point was, does it justify the risk
- not only to browser/versions that you know, but to those that will
be released during the life of your pages? That's primarily a
technical question - put aside from any personal animosity about web
pages trying to take-over one's scrollbars and any other aspects of
the browser, rather than staying within the confines of the user's
canvas.

have fun