Closed Bug 41140 Opened 25 years ago Closed 25 years ago

-moz-fixed is no longer overridden by inheritance

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: rods, Assigned: pierre)

Details

(Keywords: regression, Whiteboard: [nsbeta2-])

Attachments

(2 files)

simple test case
161 bytes, text/html
Details
Testcase showing how to get inheritance to work over -moz-fixed
253 bytes, text/html
Details
When input text or textareas are inside a div with different font-famly specified they should pick up the new font. But -moz-fixed is longer overridden by inheritance. This used to work. This used to be a special "property" of the -moz-fixed font.
This is important because you need to be bale to set a special inital or default font for text control and be able to have that font overridden thru style inheritence. nominating for nsbeta2
Keywords: nsbeta2, regression
Target Milestone: --- → M16
Attached file simple test case —
Rod, I was looking at bug 30127 and it indicates that you can get inheritance on an element with a -moz-fixed font-family, you just need to put a rule in your document style sheet indicating that the font-family should inherit. I'll attach a modified version of your testcase that shows how this works... I think this might be the correct behavior, actually.
Thanks Marc. Closed as invalid.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
I am reopening this bug because it is still a regression, you didn't used to have to do this. This approach means that users would need to explicitly define that they want the font to be inherited. They wouldn't know this. Look at it in this way, Joe-average-user write sthis html: <form> <div style="font-family:arial;">Hello<br> <input type=text value="Hello"> <textarea>Hello</textarea> </div> then files a bug on mozilla because the textarea didn't display in "arial", he would just assume that by specifying arial that it would override the default font.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Here is another interesting thing, it's related to this bug but may be a separate bug. If change the rule in html.css to: input[type="button"] { font: button; ... and then my example is: <BODY> <div style="font-family:arial;"> <input type="button" value="Default Button"> </div> </BODY> The button should have an arial font. In otherwords, the default font of "button" in the html.css should be overridable via inheritence. I guess a general rule is: font specifications in the html.css for replaced elements needs to be overridable via inheritance.
Rod, I'm going to ignore you last point because I think it is a much bigger issue than allowing -moz-fixed to be inherited over. Trying to break the CSS-specified inheritance rules for *any* font value specified in the backstop style sheet (even if only on replaced elements) is probably a recipe for disaster, not to mention a violation of the specification. This bug, if I understand it correctly, is that a font specified as -moz-fixed should be inherited over as if it were not set at all. We have a chance at fixing this, since -moz-fixed is a 'special', internal keyword. I'll look around to find out how hard it is to special case -moz-fixed and allow inheritance over it. We need to make sure the UI is not going to be wrecked because of this, so maybe we should give a heads-up to someone over there?
Hold on before doing anything, Marc. I think that Rod is wrong, I'm fairly sure we always had to explicitely inherit the font inside text edit fields.
[nsbeta2-] would reconsider if you can agree on a scenario we should hold for.
Whiteboard: [nsbeta2-]
Rod, like Marc I'm going to ignore your last comment because it clearly violates the spec. Back to the original point... We never had AFAIK the inheritance you are talking about for the text fields font. During a long time, the font was hard-coded by a custom style rule in the Editor. When that got fixed, it became specified as "font-family:-moz-fixed" in html.css. The only meaning of "moz-fixed" is "Use the fixed-width font which is set in the prefs". There isn't any particular inheritance attached to it. The closest thing I found to that kind of inheritance is in nsFormControlHelper::GetFont(). We used to have some code that caused the buttons to use the fixedFont when the font face or the font size was explicitely set on the parent (NS_STYLE_FONT_FACE_EXPLICIT) but you removed this code late in January (btw, it means that the _EXPLICIT flags are no longer used anywhere - which is fine with me). The spec doesn't say anything about the font used in text fields, it's left up to the UAs and their local implementations. We chose to display them with a font that is set in the prefs; MacIE5 chose Arial; previous browsers have similar choices but we can ignore them for that matter because they don't allow to override the font. Having a default font on input elements is perfectly legit. The appearance of these widgets is part of the look-and-feel of the application or platform, we can display them the way we want. If a web site designer doesn't like it, or if she wants a cross-platform look on her site, she can override it. It's very similar to what we have for other elements such as CODE and KBD which also come with a default font. Now the contention is on how to override the font. You are saying that we should be able to do so by explicitely setting the font on the parent element. Problem: it violates the cascading rules and it is not justified by any Nav quirk. Besides, I think it would break many pages because the text fields which used to be in moz-fixed/Courier would be rendered with the same font and size as their surroundings. As far as I'm concerned, I don't see any reason to change the current behavior: it is correct and it's also what Microsoft did in their CSS- improved MacIE5. Closing as Invalid again. If that causes problems I did not understand with what you are working on, please give me a call or just do another verbose-reopen on this bug.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
Marking VERIFIED INVALID on: - MacOS9 2000-07-18-10-M17 Commercial - Linux6 2000-07-19-20-M17 Commercial - Win98 2000-07-19-11-M17 Commercial
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: