(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 Nav4.

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?)

This is a problem that just doesn't sem to want to go away (or be fixed).

Updating QA contact.

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 (http://travel.excite.com/), 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.

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.

Setting milestone to future.

QA Contact Update

Given the lack of any duplicates, I say we WONTFIX this bug.

167759 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 select textarea 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.

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.

->>

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 (www.bankofamerica.com, 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! -m-

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.

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.