input doesn't inherit font-size

RESOLVED INVALID

Status

()

Core
Layout: Form Controls
RESOLVED INVALID
6 years ago
a year ago

People

(Reporter: Waldir, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.16) Gecko/20110323 Ubuntu/10.10 (maverick) Firefox/3.6.16
Build Identifier: 

Say we have the following document:

<body style=font-size:0.8em;>
	<input style="width:10em;">
</body>

This should produce the same result as

<body>
	<input style="width:10em;font-size:0.8em;">
</body>

but it doesn't. For other elements the width is correctly inherited in the first case, but the input remains using the default font-size scale. Only when the style is set directly on the input tag, it takes that into account.

I can reproduce this only in the system mentioned above in User Agent. It doesn't happen in FF4/Chrome12/IE9 in Windows7.

Reproducible: Always
(Reporter)

Comment 1

6 years ago
Btw, the bug doesn't occur in GChrome11 in Ubuntu 10.10 either.
Version: unspecified → 1.9.2 Branch
(Reporter)

Comment 2

6 years ago
Bug also occurs in Firefox4/Ubuntu 11.04:

Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0

So this seems to be a Firefox@Linux vs. Firefox@Windows issue rather than a Firefox3 vs. Firefox4 issue, as I initially thought. Restoring version to "unspecified".
Version: 1.9.2 Branch → unspecified
I can confirm the described behavior but I have the same behavior with Opera.
Hardware: x86 → All
Version: unspecified → Trunk
Created attachment 530007 [details]
testcase
On Linux and MacOS X, the described behavior is available in all major browsers.
Boris, David, is our behavior following the specs?
forms.css (part of our UA stylesheet) has font rules setting system fonts, no?  a system font setting would set the font-size to the system default for that system font.  So the behavior is expected.  What I don't understand is why behavior is different on Windows; that shouldn't be happening.
Probably due to the horrid XP_WIN hack in nsRuleNode::SetFont?
That said, I also think the expectation in comment 0 is wrong, since:
  <body style="font-size: 0.8em">
     This is 80% of the default font size...
     <div style="font-size: 0.8em">
        ... and this is 64% of the default font size, since 'em' on font-size
        are relative to the parent's font-size.
     </div>
  </body>
Er, sorry, the expectation in comment 0 is fine; I was looking at the testcase, which is different.
That said, Mounir's testcase looks the same to me on Linux and Windows -- I see different sizes on both platforms.  What do you see?
(Reporter)

Comment 12

6 years ago
Testcase shows box 2 smaller than box 1 in both FF3.6 and GC11 (Ubuntu10.10). I'll try later on the other machines I have access to and report back.

Also, can someone please explain/point to an explanation on why is this behavior expected? If I understood correctly, you're saying that any element should scale the given width according to the parent element's font-size, but input elements shouldn't? And if so, why? Or am I getting this wrong?
It's expected because there is an explicit font style on <input> in the ua stylesheet that sets a font size.
(Reporter)

Comment 14

6 years ago
In FF4@Win7 and GC12@Win7 I also see the second box smaller... Are you sure the testcase correctly tests for this bug? Or maybe the text shouldn't read "Both input elements should have the same size"?

And Boris, I'm sorry but I still don't understand. Why should other elements inherit the font-size from the parent element, but not <input>s?
Waldir, please read http://www.w3.org/TR/CSS21/fonts.html#font-shorthand (the part about system fonts) and then note that the following rule is in the UA stylesheet:

  input { font: -moz-field; }

(this is a system font saying "the default OS textfield font").
Created attachment 530259 [details]
testcase

The previous test case seems to be wrong. Maybe this one is better.
Attachment #530007 - Attachment is obsolete: true
(Reporter)

Comment 17

6 years ago
Created attachment 530532 [details]
A more detailed testcase
(Reporter)

Updated

6 years ago
Attachment #530532 - Attachment mime type: text/plain → text/html
(Reporter)

Comment 18

6 years ago
Results for the testcase I just uploaded:

== Windows 7 ==
- Chrome 12:  first input wider, remaining 3 elements the same size
- Firefox 4:  first input wider, remaining 3 elements the same size
- IE 9:       first input wider, remaining 3 elements the same size
- Opera 11.1: all 4 elements the same size

== Ubuntu 10.04 ==
- Chrome 11:   first input wider, remaining 3 elements the same size
- Firefox 3.6: first input wider, remaining 3 elements the same size
- Opera 11.1:  first input *narrower*, remaining 3 elements the same size

Maybe this will also be useful: http://browsershots.org/https://bug650584.bugzilla.mozilla.org/attachment.cgi?id=530532
(Reporter)

Comment 19

6 years ago
BrowserShots results are consistent with what I described; furthermore, they reveal that Safari 5 @ WinXP behaves the same as Chrome 12 @ Win7.

I also tested Firefox 4 @ Ubuntu, and the results are the same as both FF 3.6 @ Ubuntu and FF 4 @ Win7 which I reported above.
(Reporter)

Comment 20

6 years ago
(In reply to comment #7)
> the behavior is expected.  What I don't understand is
> why behavior is different on Windows; that shouldn't be happening.

Turns out it isn't. I just tried the original test case (from comment 0) and indeed there's a slight difference in Windows. The fact that the difference is so small is, I suspect, due to the system font for inputs ("message-box" from the specs, if I got it right) in Windows having similar metrics to the default serif/sans-serif fonts for regular text. I see this in FF, GChrome and IE in Windows, which is consistent with the testcase results from comment 18 and comment 19. Chrome on Ubuntu uses a different system font than Firefox, which also makes the width very similar (but again not exactly the same).

In Opera they still look exactly the same in Windows, but since on Linux they look different, I'm assuming this is just a coincidence (i.e. for Opera font metrics for inputs and regular text happen to be the same in Windows).

Given the above, I would assume this bug can be marked as INVALID, because the behavior does indeed follow the specs.

That said, I'd argue that the specs are rather unintuitive, since my original assumptions seem to be shared by others, such as Mounir whose testcase states "Both input elements should have the same size", when that's not true: the spec says that font definitions get reset for elements where a system font is applicable. I know this is not the place to discuss this, but if others agree, I will take steps to make a suggestion for more intuitive behavior reach the appropriate venues.
Waldir, thanks for the thorough testing.

Agree that this is invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
(Reporter)

Updated

6 years ago
OS: Linux → All
Duplicate of this bug: 694328

Comment 23

a year ago
While not fix the bug, you can add it to reset and make it work properly.

textarea {
    // 21/02/2012 @rodrigoludgero 
    font-family: inherit; // inherit font-family
    font-size: 1em; apply font-size
}

OBS: I could not find the reason, but I gather will be assigned firefox styles using shorthand like this:

font: 13px monospace;

and declaring separately the font property values,

    font-family: inherit; // inherit font-family
    font-size: 1em; apply font-size

it can be overwritten without using keywords like !important or fixed units values.
You need to log in before you can comment on or make changes to this bug.