89503 - [review]font-size:0 ignored

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Aaron Kaluszka]

font-size:0 does not work.. it does not matter if units are given or not.. it is
completely ignored.
CSS2 15.2.4 says font-size can take <length> (4.3.2 defined as any number) but
negative lengths are illegal.
Zero is not illegal but Mozilla treats it as such.

Comment 1

[Aaron Kaluszka]

also, font-size:0.1mm doesn't work either (rounded down to 0?)

Comment 2

[Aaron Kaluszka]

Also, anything below font-size:4% doesn't work either (relative to default 16px)

Comment 3

[Boris Zbarsky [:bzbarsky]]

*** Bug 89598 has been marked as a duplicate of this bug. ***

Comment 4

[Aaron Kaluszka]

From DUP bug 89590: "It's a severe limitation. IE 5 makes text invisible, and 
it's extremely useful - e.g. using this feature you can turn "annotated 
version" of your document to "not annotaed" by just setting font size to 0pt in 
CSS for "div.annotation" style (provided all annotations are enclosed as "<div 
class=annotation></div>')."

I'd also like to add that it is necessary for certain Standards mode 
compatibility issues.  In order to truly remove those bug 22274 "image 
descenders" a font-size of zero applied to the body is a workaround.

Comment 5

[Christopher Hoess (gone)]

Bug 89598 is the DUP, not 89590.

Comment 6

[Aaron Kaluszka]

yeah.. strike-through 8s and 0s look nearly identical

Comment 7

[Aaron Kaluszka]

CSS1 5.2.6 also mentions this.  Marking css1.  Can we get an update on this one?

Comment 8

[Hixie (not reading bugmail)]

rbs: This is probably an easy fix while you're in the fonts code... :-)

Comment 9

[Pierre Saslawsky]

"font-size: 0pt" doesn't make the text invisible on IE5/win98, it makes it 1px 
high.  On MacNav4, WinNav4 and MacIE5, the declaration is more or less ignored 
(the size is 'normal' but the line-height can be slightly affected).  Still, 
regardless of what the other browsers do, I don't think we have to worry about 
emulating their behavior.  We could just fix it.

Comment 10

[Aaron Kaluszka]

AFAIK IE5.5 and IE6 handle this properly, btw.

Comment 11

[Pierre Saslawsky]

The problem appears to be that native toolbox functions refuse to set the text 
size to 0 (eg. on the Mac, ::TextSize(0) is ignored).  Here is a patch that fixes 
the problem in XP code.

Marc/RBS: please r/sr

Comment 12

[Pierre Saslawsky]

Attachment: patch

Comment 13

[Pierre Saslawsky]

Attachment: testcase

Comment 14

[rbs]

> The problem appears to be that native toolbox functions refuse to set the text 
> size to 0 (eg. on the Mac, ::TextSize(0) is ignored).

Similar story on Windows. There is no special-case of font-size:0 on Windows, 
and nothing is breaking down. So I was curious to understand why, and I just 
looked at the GDI documentation, and it says that when the font-size is passed 
as 0, "the font mapper uses a default height value when it searches for a 
match." In other words, the font metrics' ascent, descent, etc, are still going
to be non-zero. That may be why other browsers gave the general impression that 
the declaration is ignored. 

Looking at the patch, I first had the impression that it will achieve the same 
effect as a textframe with an empty content, and I was wondering what will 
happen when the block code will apply its min-height rule. At first, it seemed 
that things wouldn't collapse into nothingness since the line-height is 
supposedly non-zero. But after applying and testing the patch, things worked out 
well. The case that didn't work and left a visible blank line was:
<p><span style="font-size:0pt">...invisible text...</span></p>

I am leaning towards thinking that the line-height may be coming from the 
font-size. And since the block code collapses empty lineboxes in your testcase 
and its line-height is 0, it disappears... In the other case, the min-height 
applies.

Anyway r=rbs, since authors can work-around the limitation by putting the 
declaration in the correct place.

Note: might be worth special-casing font-size:0 when setting the line-height in 
bug 95267 to avoid to regress this fix.

Comment 15

[rbs]

Comment on attachment 61969 [details] [diff] [review]
patch

r=rbs

Comment 16

[Marc Attinasi]

Comment on attachment 61969 [details] [diff] [review]
patch

sr=attinasi

Comment 17

[Pierre Saslawsky]

fixed

Comment 18

[Aaron Kaluszka]

sweet