149484 - font-size: small to xx-small are all too small in quirks mode

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Eric J. Schwarzenbach]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

It may be debatable whether this counts as a bug, and I don't know if the CSS
spec specifies just how small these are supposed to be, but I find that medium,
small, x-small, and xx-small are all significantly smaller in mozilla than in
IE6 or Opera 6.01 (which render them at roughly the same font size). This means
pages readable in other browsers are unreadable in Mozilla. I realize I can up
the text-zoom setting easily enough, but most users will not. I'd call this a
competetive disadvantage.

Reproducible: Always
Steps to Reproduce:
1. Load a page with text styled with font-size: x-small
2. Compare to appearance in other browsers.


Expected Results:  It should conform to what other browsers do. This would be a
big step toward eliminating the difficulty for web designers in designing pages
that look good in all browsers.

Comment 1

[Jonathan Gardner]

I noticed in the code that you can set Mozilla to work one of two ways: the old
NN4 way, or the IE way. It looks like it defaults to the old way.

This is the routine that calculates the font size when xx-small - xx-large is
used.
http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsStyleUtil.cpp#461

Comment 2

[Jonathan Gardner]

Attachment: Shows the various sizes of fonts

This shows the various sizes so you can test against IE and such.

Comment 3

[Kai Lahmann (is there, where MNG is)]

well, in sloppy mode (as your page is rendered) font-size:medium (not normal!)
is _not_ the default, it's font-size:small;. The same goes for MSIE6 in sloppy
mode and older MS and Netscape browsers.
For Opera as for MSIE6 and Mozilla in standards mode font-size:medium; is the
default (as the CSS2 spec says).

Comment 4

[Christopher Hoess (gone)]

->Fonts & Text

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

->style, but not confirming.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So... is the problem here that NS4 and IE size fonts differently, basically?

Comment 7

[Hixie (not reading bugmail)]

font-size:medium is not quirk-dependent in Mozilla. It is in WinIE6.

I think this is invalid. However, since one of the first things I do in all my
browsers is play with the font size settings until they all text is readable for
me, I really couldn't comment on what the defaults are like.

Comment 8

[Rick DeBay]

The code in comment #1 doesn't exist anymore.  Can anyone tell me how Mozilla
scales fonts?  Is the factor 1.5 per CSS-1 (which is why NS4 makes everything so
tiny), or 1.2 per CSS-2?
Or should Mozilla use the scale mentioned at
http://style.cleverchimp.com/font_size_intervals/altintervals.html ?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Can anyone tell me how Mozilla scales fonts?

See
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#259
(based on that comment, sounds like door #3 to me).

Comment 10

[:aceman]

Why is this bug unconfirmed?

A would say the font sizes should be the same in all browsers. <font size=X>
declarations seem to produce the same fonts. Why not this? And, would it be
wrong to define font-size: xx-small to be the same as <font size=1>, and
upwards? Maybe I missed some properties in CSS2 because I just wanted to declare
the equivalent of <font size=2> using CSS. Any ideas?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> And, would it be wrong to define font-size: xx-small to be the same as <font
> size=1>, and upwards?

Yes, it would.  That's precisely what IE does, and that ends up mapping the
default HTML font (size="3") to 'small' in CSS.  Which is pretty ridiculous,
when you think about it.

Which is why in Mozilla, 'small' is size="2", 'x-small' is size="1", and
'xx-small' is smaller than size="1". That way size="3" is the normal size in
HTML and corresponds to the normal font in CSS.

Which is what comment 3 said.

This is still unconfirmed, because it's not clear whether this is actually a bug....

Comment 12

[Rick DeBay]

The code pointed to in comment #9 contains a link to
http://style.verso.com/font_size_intervals/altintervals.html which doesn't exist
any more.  It turns out this is the document that I gave in comment #8
(confirmed courtesy of archive.org).  If this document is the goal, then
structure values in nsStyleUtil.cpp are off by a little bit.

IMNSHO, I think the quirks mode for fonts should use the strict table, as the
sites that depend on fonts emulating the behavior of NS4 is vanishingly small. 
And 1.4 is going to be a big release, it's time to wean the remaining sites off
of quirks mode.

I think we should go with Todd Fahrner's font-size document, if only for the
sheer volume of posts he's made on this issue :-)

Comment 13

[:aceman]

Comment #11:
>Yes, it would.  That's precisely what IE does, and that ends up mapping the
>default HTML font (size="3") to 'small' in CSS.  Which is pretty ridiculous,
>when you think about it.

I think about it:) But why is 3 the default? Actually, this is smaller than the
middle number from the interval 1-7, which is 4. I think 'medium' should be 4, 3
is 'small'. Anyway, currently in Mozilla, if small is 2, medium is 3, what is
the equivalent of size 7?

Comment #3:
Does it mean IE6 changed the sizes? And is not compatible with IE<6 ? That would
be strange. But it would also be ok, we just need to wait until all IE users
migrate to 6 (several years), and we will have Mozilla, which behaves the same:)

And what's this sloppy mode? Or is it 'quirks' in Mozilla?:)

Anyway, currently I have found a workaround which I will use in my pages. I
replaced the keywords (small, x-small, ...) with percentages. <font size=3> is
not font-size: 100%, size=2 becomes font-size: 84%, etc... See the attachment.
The numbers are manually tested, there is no proof or reasoning for them. They
just work in my browsers:) IE5, IE5.5 and Mozilla render the fonts identically.

Comment 14

[:aceman]

Attachment: The percentages for all font sizes (1-7) as described in the above comment.

Comment 15

[Hixie (not reading bugmail)]

> But why is 3 the default?

# If BASEFONT is not used, the default base font size is 3.
 -- 4 paragraphs below 
    http://www.w3.org/TR/html401/present/graphics.html#adef-face-FONT

> Anyway, currently in Mozilla, if small is 2, medium is 3, what is the 
> equivalent of size 7?

According to:
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#276
...there isn't one. (Nor is there an HTML equivalent to the CSS xx-small.)


> Does it mean IE6 changed the sizes?

IE6 does what we do in Strict mode, and defaults to 'small' in Quirks mode, as I
understand it.


> And what's this sloppy mode? Or is it 'quirks' in Mozilla?:)

He meant quirks mode, yes.


I think this bug is INVALID.

Comment 16

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I agree that this bug is invalid for 'small'.  I'm not sure about 'x-small' and
'xx-small' -- I'd need to investigate how close we are to Todd Fahrner's proposal.

Comment 17

[Rick DeBay]

D*mn mid-air collisions...
Ian, perhaps this bug could be used to address the minor issues in comment #8. 
The part about dropping quirks mode for fonts isn't minor, but it's only
applicable to sites that are optimized for NS4 (if they even exist any more),
and works against Mozilla for sites optimized for IE.

Comment 18

[Hixie (not reading bugmail)]

Rick: Please don't morph bugs, especially bugs as confused as this one. If there
is an issue other than the one given in the initial description, it should be
covered by a separate bug.

David: 
> I'd need to investigate how close we are to Todd Fahrner's proposal.

I'd be happy to do that for you if there is a specific thing you want me to
investigate.

Comment 19

[Mitsu Hadeishi]

I don't think this bug is INVALID, simply because, as a rule, fonts ought to be
readable, and xx-small is so small as to be nearly unreadable.  However, this
bug pales in comparison to the fact that Mozilla renders point-size-specified
fonts unreadably small as well, which I am about to enter as a new bug.

Comment 20

[Jonathan Woods]

Would just like to add my voice to support some action on this front.

The bare fact is that with default installations of IE 6 and Mozilla 1.x, many
sites are unpleasant to use in Mozilla.  Here in the UK, government sites by and
large use stylesheets with x-small (see e.g. http://www.homeoffice.gov.uk), so
this is real issue - both from the user point of view, and when you consider
that e-government developers have a huge influence across Europe about what
software standards are recommended in all sorts of contexts.

Comment 21

[Jörg Hartmann]

Sorry folks, but I have to ask who of us isn't able to read.

Where in the CSS2 spec you find that "medium" should be the default (or "base
font size" or 1em)? For the spec that is on www.w3c.org I can tell you: nowhere!!!

No, not any spec does tell us such **** that "medium" would be synonymous
for "usual" or "default" or "base size". Since it just does neither semantically
nor logically. It's just and only synonymous for "in the middle (between largest
and smallest)". Nothing else. And the CSS2 spec does tell us nothing(!) about
which size should be default.

But the discussion on W3C when CSS1 was built says: for both reasonability (who
needs 3 sizes below normal but no size above h1?) and backwards-compatibility
(to the old font size="") there should be exactly the same absolute font size
levels within the CSS spec as in the older HTML specs (which means nothing else
but this: 1=xx-small ...)

Just try your basic logic: When "base font size" or "default body font size" did
always mean being "the smallest font size that most common users (of the
corrosponding OS) can comfortably read", how can that size be named "medium"? It
simply IS NOT medium/in-the-middle, it's "the SMALLEST COMFORTABLY READABLE"
size. You get it?

So yes, this IS a bug. And even if IE6 standard mode copies that bug (which my
IE6 does not, although I didn't manually switch anything) it's still a bug. And
all those who copy it are nothing else than stupid or uninformed. Or ... bad
readers. (Sorry.)

Hope this helps.
Jörg H.

As for Todd Fahrner:
--------------------
font size intervals

This is about both
http://style.cleverchimp.com/font_size_intervals/altintervals.html and the
Mozilla practice of font-size: which seems influenced by your thoughts.

Hi Todd,

how did you come to think of that "medium" would in any way refer to "base font
size"? Of course it does not, as you can see in both the discussion on W3C when
CSS was defined and in how those people who were part of this working group
implemented font-size: in their own tools.

Well, yes, font-size: has exactly the same number of sizes as the former font
size="", and yes that's exactly for backwards-compatibility as well as because
it's just reasonable. There are h1/h2/h3/h4/h5/h6 so you need at least 6 levels
for headlines, and of course you need something below that.

And yes, most tools/browsers/whatever did use font size="3" for the "base font
size" (namely for 1em) that is used for the body text which has to be below
h1/h2/h3. This "base font size" is defined by being "the smallest font size that
most common users can comfortably read". Since common Mac users are designers,
they are used to read smaller fonts and can do that comfortably. That's why it's
o.k. that 1em on a Mac is smaller than on Windows. Most common Windows users are
not able to comfortably read a 12px font.

No, "medium" does in no way refer to "base font size". The word itself tells
you: "medium" is just in the middle between smallest and largest. If anything
different than "in the middle" was meant, it would be named otherwise, e.g.
"usual" or "base-size" or whatever. But no, it's called "medium" which in all
languages means "in the middle".

And of course, if "base font size" defines itself by being "the smallest font
size that most common users can comfortably read" it must be something other
than "in the middle". Just because anything below "base font size" is "not
comfortably to read". So if that was the "middle" alias "medium", all font sizes
smaller than "medium" were "not to read comfortably". In a font-size system of 7
sizes that would mean that 3 of those sizes are so small that "most common users
are not able to read them comfortably".

Which is exactly the case for Mozilla's implementation of the CSS font-size:
attribute.

So one does not need a system of smaller intervals between xx-small, x-small,
small, and medium than between medium and large, x-large, and xx-large, just to
make the smaller fonts readable while medium is as big as a reasonable "base
font size". One does not need such a work-around just for having all 7 sizes,
which is fully inappropriate in two ways: No one needs 3 sizes below "base font
size", but a size bigger than h1 is needed in many documents (which is
impossible with your proposal since there are only 3 sizes above "base font
size"); and no one does size intervals that are too small to make a visible
difference.

No, everything one needs is to realize that "medium" is different from "base
font size" and that IE is completely in line with CSS when it implements "small"
as the "base font size" alias the "smallest size that most common users can
comfortably read".

So please kill your proposal and tell those Mozilla guys that their
implementation is stupid.

Thanks.

Yours,
Jörg Hartmann, Potsdam

Comment 22

[Jörg Hartmann]

Sorry, I was mistyping, it should be this: "There are h1/h2/h3/h4/h5/h6 so you
need at least 6 levels for headlines, and of course you need something _above_
that." (for math-typography etc.)

Or did you ever find a document that used something smaller than h6? No, to the
contrary: many designers use <h6></h6> for marking picture discriptions and
other smallest text parts.

Just think: Do you really need 3 sizes smaller than "comfortably readable"?
Probably not.

Comment 23

[Jörg Hartmann]

Sorry,

might it be that you mixed up the "initial property value" of CSS2's font-size:
property with "base font size" alias "normal text font size" alias "smallest
comfortable readable font size"?

Oh, folks. "initial property value" is nothing more than this: the initial value
of that property. So it does _not_ refer in one way or another to "normal text
font size" or anything like this. It does only mean that elements with this
property initially have this value as long as the value isn't changed. That does
_not_ mean that this initial value is "normal" or "equivalent to 3" or anything
like this. It says _nothing_ about the actual size (in px) of that "initial
value". It just means that you have explicitely to set this value if you create
a document which uses CSS-font-size-property-dependent elements that should show
with other (absolute) font-sizes than this "initial value". It's just there
because _any initial value_ has to be set. Not because the CSS folks would like
you to think of this value as being "normal" or "smallest comfortably readable"
or "best for normal body text" or the like. No, "smallest comfortably readable"
is still smaller than "in the middle", just as it was back then when we used
font size="3" ...

Got it?

Comment 24

[Boris Zbarsky [:bzbarsky]]

Jörg Hartmann, please go read
http://www.w3.org/TR/CSS21/fonts.html#propdef-font-size (reading the CSS2 spec
itself is not useful at this point).  Pay particular attention to the nice table
that spells things out very clearly.

The default font size, "medium", should be whatever is most comfortable to read.
 Why one needs three sizes of font below that is a good question, but it is in
fact possible to go down three sizes from the most comfortable to read font
without getting unreadable fonts; if nothing else the patches here demonstrate that.

Please make sure to have read the _relevant_ specifications (CSS2 is becoming
increasingly irrelevant, as clearly explained at the top of the CSS2 errata
page) before commenting.

And it never helps to insult people.  Do not do that again.

Comment 25

[Jörg Hartmann]

1) Sorry if someone did feal insulted, (X)HTML is missing an <irony> element ...
(Sought the word sorry whould be enough ...)

2) No, Mr., CSS2 isn't getting irrelevant, and no, Mr., CSS21 is _not_ the (or
a)  relevant spec, since it is no spec at all. It's in-the-work-material ("W3C
Working Draft 28 January 2003"), and hopefully its section 15.7 will never be a
"W3C Recommendation" in its present state, which ist -- guess what?!? -- a
1/1-implementation of Todd Fahrner's (completely unnecessary) workaround-proposal.

3) Once more: I didn't want to insult anybody (at least not more as myself,
since I misread/mistype/misthink as much as anybody else, at least in the first
run ...), but I did want to use straight words for that you get an idea how
crazy it is to think of workarounds for something that is completely not a
problem, besides that the word "medium" proved to be somewhat misunderstandable ...

So please, tell Todd that he should just think over again and put his proposal
(which is in that working draft) into the next available trash bin ...

Comment 26

[Boris Zbarsky [:bzbarsky]]

> 1) Sorry if someone did feal insulted

Accusing people of not being able to read is somewhat insulting.

> 2) No, Mr., CSS2 isn't getting irrelevant

Sure it is.  It's error-ridden, filled with contradictions, and superceded by
CSS2.1.  UAs are implementing CSS2.1 at this point, working draft and all, not CSS2.

> hopefully its section 15.7 will never be a "W3C Recommendation" in its present
> state

The right place to bring that up is [e-mail], not here.

So far, it seems that everyone except for you thinks that Todd's proposal makes
a lot of sense, so I suggest sending a very polite email to that list giving
your arguments for why you think the proposal is bad.

Comment 27

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

> > 2) No, Mr., CSS2 isn't getting irrelevant
>
> Sure it is.  It's error-ridden, filled with contradictions, and superceded by
> CSS2.1.  UAs are implementing CSS2.1 at this point, working draft and all, not 
> CSS2.

Well, yes and no. CSS 2 will be irrelevant the day CSS 2.1 reaches CR. We're
still quite far from that today.
For the time being, CSS 2 is a REC, CSS 2.1 is a WD and that means it can still
be largely modified or even refused by the W3C Director. I know this is unlikely
but it is in theory possible.

The current law may be badly written but it still the law.

Comment 28

[Jörg Hartmann]

Boris wrote:
> The right place to bring that up is [e-mail], not here.

While Mozilla's font-size property implementation (especially of still-valid 
CSS2) is not a topic of interest on any W3C-list, I _did_ post there something 
about the unnecessary confusion added by the CSS21-January-Working-Draft's 
section 15.7:

http://lists.w3.org/Archives/Public/www-style/2003Aug/0008.html

Comment 29

[Rick DeBay]

David, please don't mark this invalid because of the discussion from comment #19
onward.
If the font sizes are adjusted to Todd's specs (as the code comments claim it
should be) and the NS4 quirks mode for fonts is dropped (what sites require this
any more?)  This bug could be fixed.

Comment 30

[:aceman]

(In reply to comment #27)
> > > 2) No, Mr., CSS2 isn't getting irrelevant
> >
> > Sure it is.  It's error-ridden, filled with contradictions, and superceded by
> > CSS2.1.  UAs are implementing CSS2.1 at this point, working draft and all, not 
> > CSS2.
> 
> Well, yes and no. CSS 2 will be irrelevant the day CSS 2.1 reaches CR. We're
> still quite far from that today.
> For the time being, CSS 2 is a REC, CSS 2.1 is a WD and that means it can still
> be largely modified or even refused by the W3C Director. I know this is unlikely
> but it is in theory possible.
> 
> The current law may be badly written but it still the law.
> 
> 


Well, CSS21 is a CR since 25.2.2004. Will this help this bug? The question is,
what is left here to be fixed? Firefox in standards mode renders the font sizes
according to that spec (section 15.7), +-1px apart (on Win).

The problem remains, that is renders them the same way in the quirks mode too.
And that is completelly different from IE 5.5 (don't know about 6), therefore
breaks almost all sites. I vote for leaving the standards mode intact and redo
the quirk mode rendering to match that of IE(5.5).

Comment 31

[:aceman]

Attachment: Shows that Firefox already renders the fonts according to CSS21.

Comment 32

[Felix Miata]

Attachment: screenshot of attachment 143475 on WinXP

What exactly is attachment 149484 [details] [diff] [review] supposed to show?

Comment 33

[Felix Miata]

Attachment: screenshot - Seamonkey vs. IE6 - standards mode @ 96 DPI

A better display of us @ 16px default vs. them.  CSS sizes are an exact match,
while <font> sizes 1 & 2 are not.
http://members.ij.net/mrmazda/auth/font-arial-tiny1024x768-16px.html

More testcases: http://members.ij.net/mrmazda/auth/wauth1.html

Comment 34

[Felix Miata]

Attachment: screenshot - Seamonkey vs. IE6 - quirks mode @ 96 DPI

Us @ 16px default vs. them.  CSS sizes in IE are larger.
http://members.ij.net/mrmazda/auth/font-arial-tiny1024x768-16pxq.html

Comment 35

[Felix Miata]

Attachment: screenshot - IE5 - standards mode @ 96 DPI

http://members.ij.net/mrmazda/auth/font-arial-tiny1024x768-16px.html

This bug looks like dupe of bug 187256.

Comment 36

[:aceman]

(In reply to comment #32)
> Created an attachment (id=143518)
> screenshot of attachment 149484 [details] [diff] [review] on WinXP
> 
> What exactly is attachment 149484 [details] [diff] [review] supposed to show?

Don't know, my attachment has id=143475. Could you also attach the rendering of
it in IE 6 standard and quirk mode (remove the doctype header) and IE5.5?

The point of the attachment is that we now render according to CSS2.1 in both
modes. If IE6 standard does the same, we are lucky we don't need to change
anything in standard mode. But in quirks mode and IE<6, the rendering is
different from Mozilla. I don't care what absolute pixel size e.g. xx-small is.
But we have to achieve that it is in the same relation to font size=1 as in IE,
otherwise these keywords stay unusable.


Comment #23: You are right, that the medium is ONLY and initial property of
font-size and nobody says it is the default font size for all text. But in the
latest CSS spec, medium is EQUAL to <font size=3> which IS THE DEFAULT font size
for HTML documents.

Comment 37

[Felix Miata]

(In reply to comment #36)
> > What exactly is attachment 149484 [details] [diff] [review] supposed to show?
 
> Don't know, my attachment has id=143475.

My comment was supposed to read attachment 143475 [details]. 149484, the bug number, was
an error.

Comment 38

[Felix Miata]

Attachment: comment 31 attachment 143475 except with quirks doctype

Comment 39

[Felix Miata]

Attachment: larger standards mode testcase

Updated comment 33 & 35 screenshots URL.

Comment 40

[Felix Miata]

Attachment: larger quirks mode testcase

Updated comment 34 screenshot URL.

Comment 41

[Felix Miata]

Attachment: WinXP attachment 143617 screenshot - Seamonkey vs. IE6

a flaw in the page for attachment 143519 [details] let some non-Arial text distort the
comparison

Comment 42

[Felix Miata]

Attachment: WinXP attachment 143618 screenshot - Seamonkey vs. IE6

a flaw in the page for attachment 143520 [details] let some non-Arial text distort the
comparison

Comment 43

[Felix Miata]

Attachment: IE5, Seamonkey & IE6 screenshot of attachment 143475 (standards)

Comment 44

[Felix Miata]

Attachment: IE5, Seamonkey & IE6 screenshot of attachment 143611 (quirks)

Comment 45

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attaching lots of screenshots without explaining what they mean isn't helpful. 
(Detailed explanations of what they mean also wouldn't be helpful unless they're
relevant to the bug.  I don't think it should take more than 10 lines of text to
explain the differences between our current behavior and IE/Windows's.)

Comment 46

[Felix Miata]

Didn't anyone ever tell you patience is a virtue. ;-)

(In reply to comment #36)
> The point of the attachment is that we now render according to CSS2.1 in both
> modes. If IE6 standard does the same, we are lucky we don't need to change
> anything in standard mode. But in quirks mode and IE<6, the rendering is
> different from Mozilla. I don't care what absolute pixel size e.g. xx-small is.
> But we have to achieve that it is in the same relation to font size=1 as in IE,
> otherwise these keywords stay unusable.

When IE does something dumb, Mozilla should not be copying what IE does. Right
now, Mozilla is precisely copying IE6 in standards mode, but not in quirks.
Since IE5 & IE6 don't match each other, there's no point in Mozilla trying to
match IE5.
 
http://www.w3.org/TR/2004/CR-CSS21-20040225/fonts.html#propdef-font-size is the
CSS 2.1 guideline, not requirement. The guideline is flawed in recommending
<font size=1>  be rendered at xx-small, which is recommeded to be rendered at
60% of CSS medium, while rendering <font size=2> at CSS small, which is 88.9% of
medium. That recommeded size difference is much too large, particularly since
the pairs adjacent are proportionally much less disparate.

The recommended overall increase between each pair of sizes is 120 %, but the
recommendation in the table actually works out to size=2 being 148% of size=1.
In standards mode, Mozilla is exercising slightly better judgement than the
recommendation by rendering <font size=1> at CSS x-small, which actually isn't
much better at the default default 16px being 10px (x-small) instead of 9px
(xx-small), making size=2 130% of size=1, while x-small is a much closer 111% of
xx-small, and medium 123% of small. This is part of what is shown by attachment
143630 [details]. Mozilla simply is not changing any sizes from standards mode when in
quirks mode, while IE makes CSS sizes larger in quirks. To the extent we want to
match what IE6 does, if indeed we want to, but, as attachment 143632 [details] shows
don't, this bug as currently summarized should be considered valid. Here it's
tabulated for 16px default:
		Standards---|	Quirks------|
		Mozilla	IE6	Mozilla	IE6
xx-small	9px	9px	9px	10px	
x-small		10px	10px	10px	13px
small		13px	13px	13px	16px
medium		16px	16px	16px	18px

Note that medium also is larger in IE in quirks mode, while large, x-large and
xx-large remain the same.

Note further that http://www.microsoft.com/ has no doctype, and thus renders in
quirks mode. That page serves up different html and css to IE than to Mozilla.
Of particular note is this one rule that differs between the two: 'td
{font-size: x-small;}' served to Mozilla, while 'td {font-size: xx-small;}'
served to IE6. Were this bug considered valid and then fixed, that difference
would probably be removed.

What is really needed is for both Mozilla and IE (and others) to make xx-small,
x-small & <font size=1> larger at least in standards mode. The gap between
xx-small & x-small is uniformly small at defaults at or near the default default
16px/12pt, while the gap between x-small and small is much larger. This is at
least in part due to
http://www.w3.org/TR/2004/CR-CSS21-20040225/fonts.html#propdef-font-size. I've
been formulating a proposal to change that in CSS3. You can find the current 
version of how I think that URL should read for CSS3 at
http://members.ij.net/mrmazda/auth/w3fonts.html. 

Comment 47

[:aceman]

Finally, attachment 143656 [details] shows what I wanted to say, but haven't had proofs.
IE6 and Moz are the same in standards mode. In quirks mode, IE 5 and 6 are the
same - why do you say they don't match??? (yes, in standards, because IE 5
doesn't have any standards mode.) and Moz is smaller - because it doesn't have
any quirks rendering for fonts.

The summary for this bug should be to change all sizes, because IE has them all
shifted by one size. But the summary change is right, we are not talking here
about standards mode, that one is correct. Only the quirks need to be changed.
And it is called quirks because is has to copy "dumb" things from IE.

Comment 48

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

IE/Windows making 'small' the default is just broken -- we shouldn't copy that,
even in quirks mode.

Comment 49

[Felix Miata]

What IE6 is doing with font sizes in quirks mode is pretending to be IE5, at
least at 96 DPI & 120 DPI. Click any of the links at
http://members.ij.net/mrmazda/auth/absolute-sizes-IE5.html with both IE5 & IE6
to confirm with your own eyes.

Comment 50

[:aceman]

(In reply to comment #48)
> IE/Windows making 'small' the default is just broken -- we shouldn't copy that,
> even in quirks mode.

Then, these keywords for font sizes will remain unusable...

Comment 51

[Hixie (not reading bugmail)]

> Then, these keywords for font sizes will remain unusable...

Why? Can't you just use standards mode instead of using quirks mode?


dbaron: Do I assume, then, that you want to mark this bug INVALID or WONTFIX?

Comment 52

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Is this bug purely about that issue?  I can't tell.  I guess if I can't tell,
it's invalid, since a bug should clearly describe what it's about.

Comment 53

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(If there's some other issue buried within the 53 comments above, please file a
separate bug.)

Comment 54

[:aceman]

(In reply to comment #51)
> > Then, these keywords for font sizes will remain unusable...
> 
> Why? Can't you just use standards mode instead of using quirks mode?

Yes, just that IE 5 doesn't have any standards mode:)

But no problem, percentage values work flawlessly across browsers.

Comment 55

[Felix Miata]

1-Percentages/ems do NOT work flawlessly across browsers.

2-Keywords are immune to inheritance and inheritance bugs, unlike %/em.

http://css-discuss.incutio.com/?page=UsingFontSize