Closed Bug 53360 Opened 24 years ago Closed 21 years ago

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

Categories

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

x86
Windows NT
defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: buster, Assigned: john)

References

()

Details

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

Attachments

(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 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?)
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 (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.
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
Status: NEW → ASSIGNED
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
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.
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
Status: ASSIGNED → NEW
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.
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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: