font: bold query.

[Brian Tozer]

I am using IE6 and am unable to get it to obey the font: bold shorthand form
of declaration.
Following various tutorials exactly I use:-

..text1 {
font: arial 16px bold;
}

And the bold is ignored.

If I use:-

.text1 {
font-weight: bold;
}

The bold is obeyed.

Is there a known problem with the shorthand form?

Brian Tozer

 

[Steve Pugh]

I am using IE6 and am unable to get it to obey the font: bold shorthand form
of declaration.
Following various tutorials exactly I use:-

.text1 {
font: arial 16px bold;
}

And the bold is ignored.

Rightly so.

See
http://www.w3.org/TR/CSS2/fonts.html#propdef-font

Note the order in which the properties are listed.

And what are you doing defining font sizes in pixels?

Steve

 

[brucie]

I am using IE6 and am unable to get it to obey the font: bold shorthand form
of declaration.
Following various tutorials exactly I use:-

.text1 {font: arial 16px bold;}

if your tutorials say to use px for font sizes then they're crap.

And the bold is ignored.

probably because your tutorials are crap.

font:bold 2em arial;

 

[Micah Cowan]

if your tutorials say to use px for font sizes then they're crap.

I find that for the screen media type it is a useable workaround
to the fact that Mac OS, GNU/Linux and Windows seem to have very
different ideas of what a "pt" is, but they all have the same
idea for "px" is. I agree it is stupid, and likely to cause
problems, but sometimes you have to go with what works *now*, and
using a better unit such as "pt" seems to be problematic.

probably because your tutorials are crap.

font:bold 2em arial;

"em"? doesn't that require a pre-existing idea of what the
font-size is?

-Micah

 

[Steve Pugh]

I find that for the screen media type it is a useable workaround
to the fact that Mac OS, GNU/Linux and Windows seem to have very
different ideas of what a "pt" is,

1 pt = 1/72 of an inch.
So text sized in pts can not work on both a small palmtop screen or on
large wall mounted screen.

In practice the various browsers and operatrng systems map pt to
screen pixels

but they all have the same
idea for "px" is.

Well at the moment they all map 1 px to 1 screen pixel. Which only
gives consistent results when compared to things that are inherently
sized in pixels, such as images. The actual size of a pixel varies
widely from user to user and with high resolution devices coming into
use text that is readable on conventional displays may be vanishingly
small on the new displays.

And of course when one reads the CSS spec one discovers that 1px is
not supposed to be 1 screen pixel, but is instead supposed to scale
according to certain factors. But browsers don't get that right at the
moment, if they ever start getting it right who knows what problems
will crop up with old designs where px sizing was assumed to be fixed
to screen pixels.

I agree it is stupid, and likely to cause
problems, but sometimes you have to go with what works *now*, and
using a better unit such as "pt" seems to be problematic.

Who ever said that the pt was preferred over px?
They are both equally bad in that they both trigger the bug/feature in
Windows IE whereby the text is not resizable by the user.

The better units brucie was referring to were em or %.

"em"? doesn't that require a pre-existing idea of what the
font-size is?

Yes, the user's chosen default size is a good starting point.

Use Google Groups to find the millions of threads on this topic that
have already taken place.

Steve

 

[William Tasso]

"em"? doesn't that require a pre-existing idea of what the
font-size is?

that would be the idea that pre-existed in the browser before the visitor
reached the site. 2em being a suggestion to use a font size twice that of
the visitors normal size.

 

[kchayka]

I find that for the screen media type it is a useable workaround
to the fact that Mac OS, GNU/Linux and Windows seem to have very
different ideas of what a "pt" is,

That's because "pt" units are not intended for screen media, but some
other media where the dot-pitch can be more reliably predicted, like print.

but they all have the same
idea for "px" is. I agree it is stupid, and likely to cause
problems, but sometimes you have to go with what works *now*, and
using a better unit such as "pt" seems to be problematic.

It is only _perceived_ as problematic if you are making the futile
attempt to get a web page to look "the same" in all browsers. Give that
idea up now and you will save yourself a whole bunch of frustration.

"em"? doesn't that require a pre-existing idea of what the
font-size is?

Um, no. Pardon the pun, but the whole point of em is that you don't
_have_ to know what the actual font-size is. It will adjust to whatever
the user's default text settings are. That's how it should be. If your
layout does not adjust gracefully to varying text sizes, then your
design is broken.

 

[Micah Cowan]

1 pt = 1/72 of an inch.
So text sized in pts can not work on both a small palmtop screen or on
large wall mounted screen.

In practice the various browsers and operatrng systems map pt to
screen pixels

Not all, which is why there is an apparent difference in the
rendering of "pt" between, say, Mac OS, GNU/Linux
(browser-dependent) and Windows.

Well at the moment they all map 1 px to 1 screen pixel. Which only
gives consistent results when compared to things that are inherently
sized in pixels, such as images. The actual size of a pixel varies
widely from user to user and with high resolution devices coming into
use text that is readable on conventional displays may be vanishingly
small on the new displays.

And of course when one reads the CSS spec one discovers that 1px is
not supposed to be 1 screen pixel, but is instead supposed to scale
according to certain factors. But browsers don't get that right at the
moment, if they ever start getting it right who knows what problems
will crop up with old designs where px sizing was assumed to be fixed
to screen pixels.

My reading of 4.3.2 is that the rescaling generally applies to
cases where a typical computer screen is *not* the device being
used to view the results of the user agent, so mapping 1px to 1
screen pixel would seem very appropriate--though I'd agree that
given a very high (or very low) resolution screen, a browser
ought to (but doesn't) rescale. Still, they at least partially
get around this by generally providing manual rescaling
capabilities (maybe to font-sizes only, though; unsure).

Who ever said that the pt was preferred over px?

No one; my misunderstanding/misreading, apparently.

The better units brucie was referring to were em or %.

Is % really ever a good choice for font-sizes? Are there
situations where it would be ideal to have your font-size scale
automatically with every window resizing (assuming its not within
a fixed-width box of some sort)?

Yes, the user's chosen default size is a good starting point.

Use Google Groups to find the millions of threads on this topic that
have already taken place.

Mm. I've made a mistake (no nead to read the google groups; your
arguments combined with a more careful reading of the spec in
sections which I must have forgotten) have convinced me. I have
often found it convenient to approach HTML from a typographer's
point-of-view, as it seems that what is right in one is often
right for the other; though this would definitely be an
exception.

-Micah

 

[Steve Pugh]

Not all, which is why there is an apparent difference in the
rendering of "pt" between, say, Mac OS, GNU/Linux
(browser-dependent) and Windows.

Sorry, I wasn't clear. I didn't mean that browsers map 1pt to 1pixel.
I meant that browsers map pt to some value of pixels rather than to a
1/72 of an inch as measurable with a ruler up against the screen.

Is % really ever a good choice for font-sizes? Are there
situations where it would be ideal to have your font-size scale
automatically with every window resizing (assuming its not within
a fixed-width box of some sort)?

% font sizes are % of the inherited size.
100% = 1em not the width of the containing box.

So % are as good as em (browser bugs allowing).

Steve