font-size question

I have a <pelement with <ttinside:

;;; <p>A paragraph contains <tt>tt element</tt>.</p>

I would like to set the font-size of the TT to the same
as the containing <p>.

This does not seem to work:

;;; p {
;;; font-size: medium;
;;; }
;;;
;;; p tt {
;;; font-size: 100%;
;;; }

when default sizes for propertional and monospace fonts
are set to different values in a browser.

Is there a way to achieve the goal without resorting to
'px'?

TIA
T.

Scripsit Takehiko Abe:

Quote:

I have a <pelement with <ttinside:

- -

Quote:

I would like to set the font-size of the TT to the same
as the containing <p>.

That would be
p tt { font-size: 100%; }
or, equivalently by the specifications,
p tt { font-size: 1em; }

Quote:

This does not seem to work:
>
;;; p {
;;; font-size: medium;
;;; }

The font size of the p element is irrelevant for the purposes of the stated
problem, except if you used physical units like px or mm, and you shouldn't
use them.

Besides, this particular setting, which uses medium as font-size value, is
not recommendable, since its effect depends on the browser. Even on IE 7,
you get different results depending on "standards mode" vs. "quirks mode".

Quote:

;;; p tt {
;;; font-size: 100%;
;;; }

What do you mean by saying that it does not work? Note that the visual
appearance of a monospace font may give the impression of increased font
size. This may sound self-contradictory to most people, since most people do
not know what "font size" really means.

Letters are generally larger (taller) in a monospace font than in a
proportional font of the same size. This is probably the main reason why
many browsers use reduced font size for elements that are usually rendered
in a monospace font, so that the effect might correspond to something like
tt, code, samp, pre, textarea { font-size: 90% }. You can see whether this
is the case in your browser by using
tt, code, samp, pre, textarea { font-family: Times New Roman; }

Similarly, you can test test whether
p tt { font-size: 100%; }
takes effect, if you add the rule
p, p tt { font-family: Times New Roman; }
(You could use just p tt { font-family: inherit; }, but IE doesn't support
it.)

Quote:

when default sizes for propertional and monospace fonts
are set to different values in a browser.

Unless there's some bad browser bug involved, those default sizes should
have no effect when font-size is set. In theory, browser settings _might_
conceptually map to CSS rules with !important specifier, but I don't think
things are that way, and if they are, there's nothing you can do about it as
an author - !important is _meant_ to be the user's last resort and give him
the final word.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

;;; p tt {

Quote:

;;; font-size: 100%;
;;; }

>
What do you mean by saying that it does not work?

What I meant is that TT rendered with different font-size than P.
For instance, in my FireFox (2.0) sans-serif font is set to
"Helvetica 14" and monospace to "Courier 13". With these
defaults and the above CSS style, it appears that P is
rendered with Helvetica 14 and TT with Courier 13.

Quote:

Letters are generally larger (taller) in a monospace font than in a
proportional font of the same size. This is probably the main reason why
many browsers use reduced font size for elements that are usually rendered
in a monospace font, so that the effect might correspond to something like
tt, code, samp, pre, textarea { font-size: 90% }. You can see whether this
is the case in your browser by using
tt, code, samp, pre, textarea { font-family: Times New Roman; }

I tested with "tt { font-family: sans-serif}" (I assumed that this
provides the same test as your example). TT is rendered with
"Helvetica 14" (the default in my browser.)

(I am using HTML 4.01 strict.)

Thanks,
T.

Takehiko Abe wrote:

Quote:

I have a <pelement with <ttinside:
>
;;; <p>A paragraph contains <tt>tt element</tt>.</p>
>
I would like to set the font-size of the TT to the same
as the containing <p>.
>
This does not seem to work:
>
;;; p {
;;; font-size: medium;
;;; }
;;;
;;; p tt {
;;; font-size: 100%;
;;; }

Sure it does.

Quote:

when default sizes for propertional and monospace fonts
are set to different values in a browser.

No they are not: but they give different _visual_ effect because their
glyphs are build on different principles.

Quote:

Is there a way to achieve the goal without resorting to 'px'?

That is irrelevant what are you using: all relative units are
calculated into pixel values before being applied. In this aspect is
irrelevant what are you using: %, em, ex, pt, or anything else: the
actual style on the screen will be always in px.
What _is_ important that relative units are being recalculated for each
partucular hardware and current text size settings.

You can easily check that both fonts have the font-size in px:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
p {
font-size: 2em;
}
p tt {
font-size: 1em;
}
</style>
<script type="text/javascript">
function init() {
var P = document.getElementsByTagName('p')[0];
var T = document.getElementsByTagName('tt')[0];
if (document.defaultView) {
alert(
document.defaultView.getComputedStyle(P,'first-letter').fontSize );
alert(
document.defaultView.getComputedStyle(T,'first-letter').fontSize );
}
}
window.onload = init;
</script>
</head>
<body>
<p>Text<tt>Text</tt></p>
</body>
</html>

It is also easy to check that they are on the same baseline. So
whatever was required is accomplished. If you want a _visual_ equality
of serif and monospace then you have to break their physical equality
by making either one smaller or bigger: naturally the adjustment effect
may differ by hardware configurations.

"VK" wrote:

Quote:

No they are not:

You mean the two are the same?

Unless I am missing something, they are different _px_ in my
browsers on my hardware right now.

Quote:

>
You can easily check that both fonts have the font-size in px:
[...]

Since I use FireFox, I don't need Javascript to check the
computed font sizes. And they are different.

Takehiko Abe wrote:

Quote:

"VK" wrote:
>

Quote:

No they are not:

>
You mean the two are the same?

Yes. I mean physical size, not the look.

Quote:

Unless I am missing something, they are different _px_ in my
browsers on my hardware right now.

That is the optical illusion I mentioned in my previous post. This is
why I provided JavaScript code in my sample. Run it and you will see
that both <Pand <TTblocks have the same px size. Without knowing
the DPI value on your current hardware, I cannot tell for sure what
number will it be. For 96DPI with default Text Size setting it will be
32px. All I can say that both values will be the same no matter what.
If you think that the program is cheating on you :-) then make a
screenshot and paste into any image editing program. Mesure the height
of say "e" letter in both blocks.

Quote:

Since I use FireFox, I don't need Javascript to check the
computed font sizes. And they are different.

That is an allusion: they are the same. As I explained earlier, you
have a choice as with any optical illusion: leave physical equality but
live then with visual difference - or break physical equality but get
the visual one.

That is the optical illusion I mentioned in my previous post.

What I'm seeing is _certainly_ not an optical illusion.

Quote:

This is
why I provided JavaScript code in my sample. Run it and you will see
that both <Pand <TTblocks have the same px size.

Just run it and it gave me 28px and 26px respectively.

Takehiko Abe wrote:

Quote:

This is
why I provided JavaScript code in my sample. Run it and you will see
that both <Pand <TTblocks have the same px size.

>
Just run it and it gave me 28px and 26px respectively.

OK, then I can tell two things for sure:

1) Your hardware uses 72DPI instead of 96DPI, so with 99% guarantee in
is not Windows. As you name makes me think of Japan, my first bet is on
MacOS

2) In your current browser monospace fonts are preset to be shown
smaller than variable width fonts to make them visually of the same
size. As I explained earlier it cannot be done without breaking
physical equality - and it is "pre-broken" on your browser.

The latter pretty much takes the problem out of the common CSS
techniques topics. You may ask for advise at <comp.sys.mac.system>

VK schrieb:

Quote:

Takehiko Abe wrote:

Quote:

>>This is
>>why I provided JavaScript code in my sample. Run it and you will see
>>that both <Pand <TTblocks have the same px size.

>Just run it and it gave me 28px and 26px respectively.

>
OK, then I can tell two things for sure:
>
1) Your hardware uses 72DPI instead of 96DPI, so with 99% guarantee in
is not Windows. As you name makes me think of Japan, my first bet is on
MacOS

I ran your test file on Firefox 1.5.0.9 (Windows, 96dpi), sans-serif:
14px, monospace: 13px.

Result: 28px, 26px.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

2) In your current browser monospace fonts are preset to be shown

Quote:

smaller than variable width fonts

No.

Takehiko Abe schrieb:

Quote:

>2) In your current browser monospace fonts are preset to be shown
>smaller than variable width fonts

>
No.

Hmm, in your original posting you wrote:

Quote:

when default sizes for propertional and monospace fonts
are set to different values in a browser.

Do you have different default font sizes for proportional (sans-serif or
serif) and monospace fonts set in your browser?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

2) In your current browser monospace fonts are preset to be shown

Quote:

smaller than variable width fonts

No.

>
Hmm, in your original posting you wrote:

I mean not "preset". I *set* them as I stated in my original
post. I can set monospace to bigger than proportional ones--
actually much bigger beyond optical illusion.

Johannes Koch wrote:

Quote:

I ran your test file on Firefox 1.5.0.9 (Windows, 96dpi), sans-serif:
14px, monospace: 13px.
>
Result: 28px, 26px.

I'm not sure what does "sans-serif: 14px, monospace: 13px" means. Are
these some extra styles or presets from Tools>Options>Content?

We are talking about default settings and default results where font
size in Tools>Options>Content and Tools>Options>Content>Advanced are
clear. Hardcoded per-machine manual settings are out of surrent subject.

VK schrieb:

Quote:

I'm not sure what does "sans-serif: 14px, monospace: 13px" means. Are
these some extra styles or presets from Tools>Options>Content?

(german version of Firefox)
Extras -Einstellungen -Schriftart & Farben -Erweitert

Quote:

We are talking about default settings and default results

Maybe you. The OP did set the font sizes to different values.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Takehiko Abe schrieb:

Quote:

I mean not "preset". I *set* them as I stated in my original
post.

Yep, maybe this was not clear to VK.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Johannes Koch wrote:

Quote:

I'm not sure what does "sans-serif: 14px, monospace: 13px" means. Are
these some extra styles or presets from Tools>Options>Content?

>
(german version of Firefox)
Extras -Einstellungen -Schriftart & Farben -Erweitert

Here we go ;-)

Quote:

We are talking about default settings and default results

>
Maybe you. The OP did set the font sizes to different values.

So did you I guess ;-)

So how can anyone help a person to override by CSS means hardcoded
settings she did in her browser?

And why would anyone make hardcoded settings just to try to override
them later by external means?

[shudder]

Takehiko Abe wrote:

Quote:

I mean not "preset". I *set* them as I stated in my original
post. I can set monospace to bigger than proportional ones--
actually much bigger beyond optical illusion.

Briefly if you want to have <p>Text<tt>Text</tt></pand have both
"Text" _visually_ (not physically) of the same size CSS has nothing
good to propose on this matter. All you can do is to achieve such
effect on your own computer by making say p {font-size: 1em} and p tt
{font-size: 0.8em;} or whatever values combination will satisfy you.
With some luck _and_ default setings that will be satisfactory for a
big number of your visitors as well.

For really robust cross-environment development CSS in its current
state is just too weak as a tool. You need client-side scripting as
well - or server-side content adjustment.

VK schrieb:

Quote:

Johannes Koch wrote:

Quote:

>The OP did set the font sizes to different values.

>
So did you I guess ;-)

Yep

Quote:

So how can anyone help a person to override by CSS means hardcoded
settings she did in her browser?

A browser may treat browser settings as user agent CSS which may be
overridden by author CSS.

--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

VK wrote:

Quote:

Briefly if you want to have <p>Text<tt>Text</tt></pand have both
"Text" _visually_ (not physically) of the same size CSS has nothing
good to propose on this matter. All you can do is to achieve such
effect on your own computer by making say p {font-size: 1em} and p tt
{font-size: 0.8em;} or whatever values combination will satisfy you.
With some luck _and_ default setings that will be satisfactory for a
big number of your visitors as well.
>
For really robust cross-environment development CSS in its current
state is just too weak as a tool. You need client-side scripting as
well - or server-side content adjustment.

Actually I checked it on my IE6 SP1 and _here_ monospace is preset to
be smaller than variable width fonts (while on Firefox set default
equal): 16px for 1em Times New Roman and 13px for 1em Courier New. Hard
to notice with always direct styling of elements, so good I followed
this thread.

Overall if anyone is serious about font-size questions on the Web then
logical inch, DPI and em are things to learn first. As a "teaser": CSS
inch has nothing to do with the physical inch between say pan and
pancil put on your table.
pt, mm, cm are calculated from that logical inch. This is why in CSS
things are normal and obvious that otherwise would be sick crazy: like
converting px to inches or cm to pixels. I was quick looking for some
good reference on the subject but nearly got a heart attack of what I
saw :-) One thing for sure - do not read W3C about it, they seem the
worst. That one: <http://www.emdpi.com/is a bit over simplified IMO
but the key points are there.

I also posting a demo to play this. I teared it out from some of my
bigger projects and glued together quickly but it works. Basically it
bypasses Firefox and IE limitations (each one of its own kind) to get
current DPI constant so to resolve the "golden" TTF formula px =
(pt/72)*DPI

You may play with different fonts and different Text Size settings to
see CSS relative-to-absolute mechanics in action.

P.S. Oh yeh - to show my respect to everyone I placed DOCTYPE Strict
and validated it :-)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>DPI</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
#probe {
position: absolute;
top: 0;
left: 0;
visibility: hidden;
width: 1in;
margin: 0;
padding: 0;
}
</style>
<script type="text/javascript">

function init() {
var DPI = getDeviceDPI();
var p = document.getElementById('outer');
var tt = document.getElementById('inner');
if (p.currentStyle) {
alert('P font-size in pixels: ' +
parseInt(parseInt(p.currentStyle.fontSize)/72*DPI));

alert('TT font-size in pixels: ' +
parseInt(parseInt(tt.currentStyle.fontSize)/72*DPI));
}
else if (document.defaultView) {
alert('P font-size in pixels: ' +
document.defaultView.
getComputedStyle(p,null).fontSize);

alert('TT font-size in pixels: ' +
document.defaultView.
getComputedStyle(tt,null).fontSize);
}
else {
'NOP';
}
}

function getDeviceDPI() {
if ((window.screen) && (window.screen.deviceXDPI)) {
return parseInt(window.screen.deviceXDPI, 10);
}
else if (document.defaultView) {
return parseInt(document.defaultView.
getComputedStyle(document.getElementById('probe'), null).
width, 10);
}
else {
return NaN;
}
}
window.onload = init;
</script>
</head>
<body>
<h1>Demo</h1>
<p id="outer">Text <tt id="inner">Text</tt></p>
<div id="probe"></div>
</body>
</html>

VK schrieb:

Quote:

Overall if anyone is serious about font-size questions on the Web then
logical inch, DPI and em are things to learn first. As a "teaser": CSS
inch has nothing to do with the physical inch between say pan and
pancil put on your table.

What then do you think is an inch in CSS?
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

Johannes Koch wrote:

Quote:

What then do you think is an inch in CSS?

I personally think nothing particular on the matter as it doesn't
depend on my thinking. I'm using that is "given in the reality".

I gave a link for a startup reading, particularly on your last question
see <http://www.emdpi.com/screendpi.html>

To anyone showing a good application :-) I will open up the most dark
font secrets like why italic characters sometimes overlap each other,
why italic serif "i" is especially bad on that and why say "w"
sometimes looks trimmed.

As you can see the perspectives are amasing for good students :-))

VK schrieb:

Quote:

Johannes Koch wrote:

Quote:

>What then do you think is an inch in CSS?

>
I personally think nothing particular on the matter as it doesn't
depend on my thinking. I'm using that is "given in the reality".
>
I gave a link for a startup reading, particularly on your last question
see <http://www.emdpi.com/screendpi.html>

The resource does not talk about CSS, so why should it be a reference
about what an inch is in CSS?

In my browser, a box with a width of 72pt specified via CSS _is_ 1 inch
wide.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

Johannes Koch wrote:

Quote:

The resource does not talk about CSS, so why should it be a reference
about what an inch is in CSS?
>
In my browser, a box with a width of 72pt specified via CSS _is_ 1 inch
wide.

It is a hard concept to get at the first time, I know. Say W3C failed
on it miserably, because in their tabled inches , points, cm and mm are
in absolute units group while say pixel (px) in relative. So obviously
they were thinking of physical inches when making their CSS specs
instead of logical ones which are the only ones you have to deal on any
electronic display.

I invite you to read again more carefully
<http://www.emdpi.com/screendpi.htmlIt may also help to a have a real
(wooden or plastic) ruler marked in inches and mesure some distance on
a flat display after changing DPI. An onscreen ruler provided by same
applications is useless because obviously it shows logical inches as
well so adapts automatically for DPI changes.

Johannes Koch wrote:

Quote:

So how can anyone help a person to override by CSS means hardcoded
settings she did in her browser?

>
A browser may treat browser settings as user agent CSS which may be
overridden by author CSS.

That browsers allow users to set font-size for monospace
differently from proportional fonts poses an interesting *
problem.

If I set monospace to monaco 10px, then <prewill be rendered
with it. (if it did not, I would be upset.) But that means
font-size of <preelements does not inherit a computed value
of its parent -- say <body>.

That seems to be the case even if I specify the author stylesheet
in this way:

;; body {
;; font-family: serif;
;; pre {
;; font-size: 100%;
;; }

<prestill refers to monaco 10 (100% of 10px). This is
understandable because the above style is the same as not
specifying style at all.

However, once I use such absolute values as pt, px et al:

;; body {
;; font-family: serif;
;; font-size: 24pt;
;; }
;; pre {
;; font-size: 100%;
;; }

<prewill inherit from its parent and be rendered with 24pt.

*ok, interesting to me at least. For most it is too obvious or
uninteresting, I guess.

regards,
T.

Scripsit Johannes Koch:

Quote:

A browser may treat browser settings as user agent CSS which may be
overridden by author CSS.

Yes, but that's not a sufficient explanation or excuse for the Firefox
behavior.

Suppose that I have
p tt { font-size: 100%; }
in a page ("author") style sheet. How could a browser style sheet "win" it?

First, a browser style sheet could "win" it using !important. That's not the
case here, though, since then it would "win" a page style sheet in all
circumstances, but in fact if you add e.g.
tt { font-family: Courier New, monospace; }
into the page style sheet, the font-size: 100% setting "wins". (This happens
even if Courier New is in use anyway for monospace text!)

Second, a browser style sheet could "win" by using a more specific selector.
That's not the case either. Even though a browser style sheet _could_
contain arbitrarily specific selectors, it does not, in practice. And if it
"won" by doing so, the added rule above would not affect the situation, but
it does.

The conclusion is that Firefox simply misbehaves, as far as CSS compliance
is considered. It has its own weird idea of setting default fonts, making
them depend on "character set" (an undocumented and widely confusing
concept) _and_ making the settings override CSS in a trickish, undocumented,
surprising, Microsoft-like (add derogatory attributes as desired) way.

Basically, Firefox seems to treat its own defaulf font settings as
aggregates that set _both_ font face _and_ font size in a coupled way. If I
set the default monospace font to Courier New 20 (something - I guess it's
pixels, but Firefox doesn't tell me in the interface!), then Firefox will
use this font face and this size for elements like <ttunless a page sets
the font face for such an element, using an explicit font name (monospace
won't do). Setting the font size alone does not seem to take effect.

If I were paid (a lot) for defending Firefox against all unjustified and
justified criticism, I might try the explanation that in Firefox, the
default monospace font, and the specific value corresponding to the generic
font name monospace in CSS, is a virtual font that has the following
characteristics. It physically looks like the font specified in the user
interface for selecting the default monospace (or by factory settings), but
it only exists in the size specified in the same interface (or factory
settings). Thus, no matter what font size you set, the actual value is the
same.

I'm afraid the God's (or Devil's?) advocate would attack my argument using
<div>Hello <tt>Hello <span>Hello</spanHello</tt></div>
and
tt { font-size: 100%; }
span { font-family: Times New Roman }
which should, according to my argument, result in the <spanelement
displayed in normal font size, since its font size would be 100% of the
_computed_ font size of its parent. But as you may guess, it's in reduced
font size.

Thus, the verdict is that Firefox is simply wrong.

As a workaround, use something like

pre, code, samp, kbd, tt
{ font-family : "Courier New", monospace;
font-size: 100%;
font-style : normal; }

(I'm assuming that you really want 100% font size for monospace text. I
think it's generally not a good idea, since typical monospace fonts, and
especially Courier New, look bigger than normal text in the same font size.
For isolated code fragments, 100% might be OK, but inline fragments become
too big with respect to surrounding text.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Scripsit Takehiko Abe:

Quote:

That browsers allow users to set font-size for monospace
differently from proportional fonts poses an interesting *
problem.

To put it mildly, yes. But the great source of confusion is really the way
Firefox couples the font size and the font family settings in a manner that
cannot comply with CSS.

Quote:

If I set monospace to monaco 10px, then <prewill be rendered
with it. (if it did not, I would be upset.)

Other things being equal, yes.

Quote:

But that means
font-size of <preelements does not inherit a computed value
of its parent -- say <body>.

Generally, <predoes not inherit font-size anyway, because browsers usually
have a font-size setting for it in their default style sheet. Inheritance
never takes place for a particular element and property if _any_ style sheet
sets a value for that property of that element. The meaning of % values is
quite distinct from inheritance, though it may have similar net effects.

Quote:

That seems to be the case even if I specify the author stylesheet
in this way:
>
;; body {
;; font-family: serif;
;; pre {
;; font-size: 100%;
;; }
>
<prestill refers to monaco 10 (100% of 10px). This is
understandable because the above style is the same as not
specifying style at all.

No, it's not the same. When syntactically fixed by adding the missing "}",
the style sheet changes the <prefont size in IE, though not on Firefox. IE
does what you want, and, somewhat exceptionally, this time it's Firefox that
is buggy, or broken by design in this respect.

Quote:

However, once I use such absolute values as pt, px et al:
>
;; body {
;; font-family: serif;
;; font-size: 24pt;
;; }
;; pre {
;; font-size: 100%;
;; }
>
<prewill inherit from its parent and be rendered with 24pt.

No, it definitely doesn't inherit font-size - you have _declared_ a value
for it. But the 100% _means_ the computed font size of the parent.

The fact that here even Firefox gets it right is yet another oddity in
Firefox behavior. It's even more complex than I described in my previous
message. The default font settings (which are always there, even if you
never even look at them) couple font family and font size together, in a
manner that seriously conflicts with the current CSS philosophy and
specifications, but Firefox lets you break this connection in different
ways.

I'm sure the people who designed this (mis)behavior thought they were doing
something clever and user-friendly (just as Microsoft programmers did when
designing the broken box model of old IE).

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

That browsers allow users to set font-size for monospace

Quote:

differently from proportional fonts poses an interesting *
problem.

>
To put it mildly, yes. But the great source of confusion is really the way
Firefox couples the font size and the font family settings in a manner that
cannot comply with CSS.

See <https://bugzilla.mozilla.org/show_bug.cgi?id=175415and feel free
to participate. The core is that font-size on TTF fonts is *extremely*
difficult problem even if taken on one platform; it gets crazy
difficult in cross-platform aspect.
W3C's revelations on the matter is just another good illustration of
that "lesser you know about the problem - easier seems the solution".

VK wrote:

Quote:

See <https://bugzilla.mozilla.org/show_bug.cgi?id=175415>

That bug has nothing to do with this issue. It's to do with taking
fonts and sizes for fonts from different elements of the list of fonts
(and shows itself when these aren't both monospace). It's an obscure
bug concerning the parsing of CSS rule sources, not their rendering.

It has nothing to do with the core issue of how to render monospace and
what size to do it at.

Jukka K. Korpela wrote:

Quote:

The fact that here even Firefox gets it right is yet another oddity in
Firefox behavior.

FYI Safari behaves the same way.

Quote:

It's even more complex than I described in my previous
message. The default font settings (which are always there, even if you
never even look at them)

But once a user sees it, he expects the settings to take effect.

Quote:

couple font family and font size together, in a
manner that seriously conflicts with the current CSS philosophy and
specifications, but Firefox lets you break this connection in different
ways.
>
I'm sure the people who designed this (mis)behavior thought they were doing
something clever and user-friendly

You shouldn't be so sure. I think the feature (letting user set default
fonts ...) predates css.

regards,
T.

On 2007/01/16 15:40 (GMT+0900) Takehiko Abe apparently typed:

Quote:

I have a <pelement with <ttinside:

Quote:

;;; <p>A paragraph contains <tt>tt element</tt>.</p>

Quote:

I would like to set the font-size of the TT to the same
as the containing <p>.

Quote:

This does not seem to work:

Quote:

;;; p {
;;; font-size: medium;
;;; }
;;;
;;; p tt {
;;; font-size: 100%;
;;; }

Quote:

when default sizes for propertional and monospace fonts
are set to different values in a browser.

Quote:

Is there a way to achieve the goal without resorting to
'px'?

Some variation on http://mrmazda.no-ip.com/auth/monospace-sizing.html
should work if you don't mind ignoring the user's monospace font-family
and size preferences.
http://mrmazda.no-ip.com/auth/Font/f...-samplesM.html might be
instructive in understanding that page's TT CSS sizing rule.
--
"I have come that they may have life, and have it to the full."
John 10:10 NIV

Team OS/2 ** Reg. Linux User #211409

Felix Miata *** http://mrmazda.no-ip.com/

Felix Miata wrote:

Quote:

Some variation on http://mrmazda.no-ip.com/auth/monospace-sizing.html
should work if you don't mind ignoring the user's monospace font-family
and size preferences.

That works for FireFox (though not for safari). Thank you!

This seems to work too:

tt {
font-family: monospace, courier;
}

This too:

tt {
font-family: monospace, nosuchfont;
}

Quote:

http://mrmazda.no-ip.com/auth/Font/f...-samplesM.html might be
instructive in understanding that page's TT CSS sizing rule.

I'll study it.

Thanks,
T.

font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

re: font-size question

Similar HTML / CSS bytes

/bytes/development

/bytes/it

/bytes/about