Steve said:
Yes, for some properties.
aha, yes I read about that.
Due to bugs in Win IE % are better than em for font-size, but em are still
good for margins and padding.
aha, did they found those bugs after the recommendation
of the W3C? (Anyway - it is nearly the same with %.)
Huh? So Mac users need text set at 130% of their chosen default size? Why?
[I will try to translate it:]
Because different platforms have different screen resolutions.
Win has 96 'dpi' (dots per inch) but Mac and Linux come with 72 dpi.
If the formatting is given in pt win will display the font larger than mac.
In practice this has fatal consequences: For the font-size is given
very often in pt, this leads to a 96/72 or about 1.33 (~133%) bigger
display on win than on Mac.
'Round the other way the formatting in pt on Mac will be
displayed only 72/96=0.75 (or only about 75 percent as big alike
the according windows presentation).
The solution would be only to use px because the font-size in
px will be displayed the same on any platform.
Problem: The visitor of the page can not alter the font-size on
his own (e.g. IE: View(?) -> Font-Size) if you use px.
That would be a restriction for partially sighted people.
Therefore you use relative font-size and measures in 'em' or '%' which is
much more effective and visitor friendly. Formatting by css using units
in 'em' or the specification in percent can quite be senseful whereas
the W3C recommends the use of em. This has the advantage that
the specifications are relative and the font-size is alterable
to a cerain degree. 1 em is the standard font-size of the UA.
If desired that the font will displayed bigger than the standard
font-size a designated value bigger than 1 is selected
if a smaller one shall be displayed a value smaller than 1 will be set.
The specification in percent acts similar (bigger than standard:
bigger than 100% - smaller size: smaller than 100%).
In pracitce two extern css files are created: The one optimised
for win the one optimised for Mac respectively for Linux. The formatting in
the css file for Mac has to be 33 percent bigger than in the css file for
win.
You are aware that only old Mac browsers have a factory default font size
of 12px? Modern Mac browsers use either 16px (same as most (all?) Windows
browsers) or 14px.
And what is with Linux platforms?
But it reminds me of a java example of David Flanagan:
http://html.janfaerber.com/files/HardcopyWriter.java
.... Here you have a workaround for Windows - a bug:
<quote>
pagesize = job.getPageDimension(); // query the page size
pagedpi = job.getPageResolution(); // query the page resolution
// Bug Workaround:
// On windows, getPageDimension() and getPageResolution don't work, so
// we've got to fake them.
if (System.getProperty("os.name").regionMatches(true,0,"windows",0,7))
{
// Use screen dpi, which is what the PrintJob tries to emulate
pagedpi = toolkit.getScreenResolution();
// Assume a 8.5" x 11" page size. A4 paper users must change this.
pagesize = new Dimension((int)(8.5 * pagedpi), 11*pagedpi);
// We also have to adjust the fontsize. It is specified in points,
// (1 point = 1/72 of an inch) but Windows measures it in pixels.
fontsize = fontsize * pagedpi / 72;
}
</quote>
It is a little bit OT but here the same:
Everybody says - 'Java is platform independent!' But you have to
be aware of such bugs or differences between different platforms.
If you say that we have now three different font sizes:
12, 14 and 16 px we even need a third css file!
Firstly, assuming that all browsers on a given OS are the same is stupid.
Secondly, assuming that users need text in ordinary paragraphs set larger
than 1em is stupid.
Then you have to get the default font size of the browser AND the screen
resolution of the OS together to decide on further actions.