Closed Bug 53360 Opened 23 years ago Closed 19 years ago

[quirks]Buttons don't inherit <font size=xxx>


(Core :: Layout: Form Controls, defect, P4)

Windows NT





(Reporter: buster, Assigned: john)




(Keywords: compat, testcase, Whiteboard: WONTFIX?)


(5 files)

(found during testing of Ian's CSS changes, but I don't believe these changes 
introduced the problem.  I see it in PR2 as well.)
debug bits from 9/18/00, WinNT, mozilla and viewer.
compare the page with Nav4.  The buttons and controls are larger in moz than in 
I cc'd harish and rickg in case it's a residual style problem.  Is there an easy 
way to tell (maybe just dump style and compare the style context for the 
controls with what is expected from the source?)
Attached file reduced testcase
This is a problem that just doesn't sem to want to go away (or be fixed).
Assignee: rods → pierre
Summary: form controls wrong size → Buttons don't inherit <font size=xxx>
Attached file more tests
Updating QA contact.
QA Contact: ckritzer → bsharma
Described as it is ("Buttons don't inherit <font size=xxx>") I think that this 
bug can be marked WontFix.
- HTML-3 buttons inherited font sizes only in WinNav.  MacNav, MacIE and WinIE 
don't do it.  Besides if you consider the page above (, 
the size of the buttons don't match in WinNav but they are correct in the other 
browsers (Moz included).
- HTML-4 buttons have their font and size defined through CSS3 fonts which get 
them from the OS.  To override that, you must attach a style to the buttons.

If you think that this previous behavior should be implemented as a quirk, please 
do it on Windows only (with something like "font-size: inherit") but again, I 
don't see much interest.

Reassigned back to Rod for evaluation, or just to close the bug.

Note: based on the 2nd testcase, I opened bug 58190.
Assignee: pierre → rods
Ccing ian.
If it doesn't take a lot of work, I think it is worth fixing. NavQuirks exists 
because of the Windows platform. I don't get the comment about only Windows 
doing it, seeing how that is the largest percentage of browsers used.
Severity: normal → major
Keywords: compat
Priority: P3 → P2
Setting milestone to future.
Target Milestone: --- → Future
QA Contact Update
QA Contact: bsharma → vladimire
Keywords: 4xp, testcase
Summary: Buttons don't inherit <font size=xxx> → [quirks]Buttons don't inherit <font size=xxx>
Priority: P2 → P4
Given the lack of any duplicates, I say we WONTFIX this bug.
Whiteboard: WONTFIX?
QA Contact: vladimire → tpreston
  Form button text is drawing using a font of default language instead of the
language of the page
might be a duplicate.

This bug applies also applies to other form elements.
input type text

The lack of control from html3 makes a lot of pages that look well in other
browsers look odd in mozilla. 

A WONTFIX for this bug would mean that for a proper render of form elements, CSS
is mandatory, even if the author does not intend to.

Attached file form elements testcase
This is a plain html3 page with form elements and font tags controlling text.

The behaviour described for the bug is not restricted to buttons.
Next attachements show how this page is rendered in mozilla (see build in
titlebar) and in netscape 4.75
Mozilla uses arial font for input and select and courier for textarea. 
It ignores all font specifications when rendering form elements.
Netscape renders form elements consistently with font tag specifications, also
bold tag. (not tested italic)
Suggest "Form elements (input, select, textarea, button) don't inherit font" as
short description

And bug is more general, as form elements are unaffected by other text control
tags, like bold, etc.

I strongly advice against WONTFIX.
Assignee: rods → jkeiser
we reeeeally need the font sizing, etc to be inherited by form controls. by
default i and many others use a small font size, and forms
(, many other sites) are totally illegible unless i
ctrl+plus up to a super-huge-as-to-make-the-page-unreadable size. it's enough to
make one want to use a different browser! early versions of netscape (4.x) had
this same issue. i suggest you don't make this a WONTFIX. thanks!

Comment 6 says that IE/Windows does NOT have this quirk.  Is it in error?

For the record, I too feel wontfix is right here.
QA Contact: tpreston → ian
When I open the test cases using IE 6.0 and a recent Mozilla build I don't see
any significant differences.
OK.  Here's what I'm seeing on Linux:

Opera 7.23 -- behaves like Mozilla
NS4 -- behaves as described in this bug
Konqueror 3.0.3 (old version) -- behaves like NS4

Since IE6/Win also behaves like Mozilla, NS4 is pretty irrelevant at this point,
and the current version of Konqueror is 3.2 or so (and I don't have it handy to
test with), marking wontfix.
Closed: 19 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.