Closed Bug 41140 Opened 24 years ago Closed 24 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: 24 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: 24 years ago → 24 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: