Closed Bug 2357 Opened 26 years ago Closed 25 years ago

<INPUT TYPE=TEXT> does not use specified font [M12]

Categories

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

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 17303

People

(Reporter: jlarivi-retired, Assigned: buster)

References

Details

(Whiteboard: [TESTCASE])

Attachments

(1 file)

Test case
(deleted), text/html
Details
If the <input type=text> inherits a verdana font from the BODY, it doubles the field size. I want to be able to control the field size through CSS (like IE4 & 5 does) and NGLayout does not follow the "width" property for the input field.
CSS size controls only apply to form elements when not in "Quirk" mode.
Setting all current Open/Normal to M4.
Assignee: peterl → karnaze
Component: Style System → Widget Set
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
Can you please give me a test case.
Status: RESOLVED → REOPENED
I put in an example: I also just noticed that the select element and text inputs should all be the same length but are different in size (in both standard and quirk modes). I took out the style body font-family classification to see if the doubling in size also applies to <font face> (it does). Hope this helps. james ------------------------------- <HTML> <STYLE TYPE="text/css"> BODY { font-family: verdana, arial, helvetica, sans-serif; } .quickfield { width: 150px; } </STYLE> <BODY> <FORM ACTION="../search/quick.cgi" METHOD="POST" ENCTYPE="application/x-www- form-urlencoded"> <P><B>Quick Search</B><BR> <INPUT TYPE="text" NAME="query" SIZE="14" CLASS="quickfield"><BR> <SELECT NAME="type" CLASS="quickfield"> <OPTION VALUE="name" SELECTED>Name</OPTION> <OPTION VALUE="category">Category</OPTION> <OPTION VALUE="address">Address</OPTION></SELECT> </P> <font face="verdana, arial, helvetica, sans-serif"><P><B>Quick Search</B><BR> <INPUT TYPE="text" NAME="query" SIZE="14" CLASS="quickfield"><BR> <SELECT NAME="type" CLASS="quickfield"> <OPTION VALUE="name" SELECTED>Name</OPTION> <OPTION VALUE="category">Category</OPTION> <OPTION VALUE="address">Address</OPTION></SELECT> </P> </font> </FORM> </BODY> </HTML>
Resolution: INVALID → ---
QA Contact: 4110 → 4078
move to m5
Assignee: karnaze → pollmann
Status: REOPENED → NEW
Target Milestone: M5 → M6
Reassigning to Eric, moving to M6.
Status: NEW → ASSIGNED
Redistributing to M8...
Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.
OS: Windows 98 → All
Hardware: Other → All
Whiteboard: [TESTCASE]
Target Milestone: M8 → M9
I just attached this testcase. Both problems still exist: 1) The CSS specified width of a text field does not override the SIZE attribute for either Native or GFX widgets on Linux or Windows. 2) The specified font is not set for the text input widget (Windows native tested), even though it's width is used for calculating widget size. This causes the box to appear nearly double the width specified by the size attribute in this example.
Attached file Test case (deleted) —
Summary: <input> doubles in size and can NOT control width of field through CSS. → [GFX][NATIVE]<INPUT TYPE=TEXT> does not use specified font or CSS width
Summary: [GFX][NATIVE]<INPUT TYPE=TEXT> does not use specified font or CSS width → [GFX][NATIVE]<INPUT TYPE=TEXT> does not use specified font or CSS width [M10]
Moving non-critical bugs out.
After careful consideration, I've decided that I probably won't get this bug in for M12. Currently I have nearly 50 bugs scheduled for M13, so there is a possibility that this bug may need to be moved out farther still.
Assignee: ckritzer → pollmann
QA Contact: phillip → ckritzer
GFX text widgets have been totally rewritten by Steve. Bug #1 is no longer present. I did a screen grab of the text field and measured it's width to be exactly 75px, which over-rode the 14 character width specified in the width attribute. Cool! Testing bug #2...
Summary: [GFX][NATIVE]<INPUT TYPE=TEXT> does not use specified font or CSS width [M10] → <INPUT TYPE=TEXT> does not use specified font [M12]
Looking at the original test case, the font still is not inherited into the text field or the select. In fact, even if you specify the font directly on the .quickfield class, or as an inline style (style= attribute) it has no effect. This is also the case with Nav and IE 5.0, so we're not hurting backwards-compatability here, only standards compliance. Steve, do you know about being able to specify the font of a text input element? Is that something that we are going to support?
yes, we should support setting the font. Probably in quirks mode, we'll ignore it, and in standard mode we'll respect it. Rod wrote some great code in nsGfxTextControlFrame that does different sizing algorithms for the two modes, and the standards mode algorithm should already support variable-width fonts. So all we have to do is allow them. That should be pretty straightforward, you can assign that part to me.
Based on the CSS cascade mechanism, the font shouldn't be inherited, since the select (or other widget) is matched by a declaration in the UA stylesheet, which overrides inheritance. So don't do this for standards compliance. (Per CSS, if you want to style a widget, style the widget, since there are likely UA styles that you have to override, and you can't do this by depending on inheritance.)
Ah, almost forgot about ua.css, thanks for the reminder. :) We'll still have to enable fonts specified for style applied directly to the widget with an inline style sheet or a STYLE= on the element itself, right? This doesn't work right now. Steve, do you want this bug then? Feel free to grab it if you like. :)
Right.
Assignee: pollmann → buster
Priority: P2 → P3
Target Milestone: M13 → M14
assigning to myself. I agree with Mr. Baron, text controls don't inherit font, but should respect any font setting on the control itself in stardard mode. P2 seems too high a priority for this, and M13 too soon. Downgrading to P3/M14.
Dup of 17303 or vice versa?
Bug 17303 could be a dup of this bug if the sans-serif is already in the stylesheet. (Of course, I like bug 17303 the way it is now...)
Blocks: 7543
Status: NEW → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → DUPLICATE
This is in fact a duplicate of 17303. *** This bug has been marked as a duplicate of 17303 ***
Status: RESOLVED → VERIFIED
verified duplicate of 17303 (or part of 17303 at least). Text controls should respect font setting on the control itself (from this bug) was discussed and fixed as the conversation and fixes in 17303 moved somewhat from the 17303 original problem.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: