Closed Bug 697451 Opened 13 years ago Closed 10 years ago

Allow use of line-height for <input type="reset|button|submit">

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Version:
9 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla30
Tracking Flags:
Tracking Status
relnote-firefox --- 30+

People

(Reporter: fvsch, Assigned: dbaron)

References

Details

(Keywords: dev-doc-needed, site-compat)

Attachments

(3 files)

Testcase.697451.html
544 bytes, text/html
Details
Testcase.697451 - Screenshot
79.99 KB, image/png
Details
Stop overriding line-height (max-ing with 1.0) on inputs other than single-line text inputs
3.17 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review 
This is a proposal to change forms.css so that <input type="reset|button|submit"> elements may receive a line-height other than "normal".

Back in 2002 it was decided in Bug 82265 that INPUT elements should always use line-height:normal. So we have this in resource://gre-resources/forms.css:

input {
  /* ... lots of stuff */
  line-height: normal !important;
  /* ... more stuff */
}

I think the line-height property should be available to stylesheet authors for INPUT elements of the "button|reset|submit" types, in the same way it's available for the BUTTON element. Actually in forms.css we have this block:

button, 
input[type="reset"],
input[type="button"],
input[type="submit"] { 
  /* ... lots of stuff */
  line-height: normal;
  /* ... more stuff */
}

The issue here is that line-height remains impossible to use in author stylesheets because of the "!important" in the first declaration.
For the record:
- Internet Explorer and WebKit allow authors to modify line-height for those elements.
- Firefox and Opera don't.
See tests #2 and #3 in this test case: http://covertprestige.info/css/button-basic/test.html

It would be great if we could align on WebKit and Trident (I'll send a bug report to Opera as well) and remove one small browser inconsistency.

I guess the fix requires a change to form.css, removing the !important in:

input {
  /* ... lots of stuff */
  line-height: normal;
  /* ... more stuff */
}

… and adding the "!important" rule only for the relevant INPUT types:

input:not([type="reset"]):not([type="button"]):not([type="submit"]) {
  line-height: normal !important;
}
> - Internet Explorer and WebKit allow authors to modify line-height for those elements.

Not quite.

See bug 349259 comment 42 and the screenshot attached to that bug in attachment 525341 [details].  Specifically:

1)  WebKit allows changing the line-height on some buttons but not others, depending on
    whether they're being natively themed.
2)  IE in quirks mode does not allow _reducing_ the line-height on buttons.

Now I would really rather not introduce a quirk here, and I don't think the WebKit native theming thing makes sense... but given past experience with trying to remove the !important here, I suspect sites may well depend on the combination of the two.

Can we get IE and WebKit to remove those quirks?  That would make it a lot easier for us to remove our quirk here, so that we're actually aligned.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I second this bug, although I don't think the !important should remain in the other input styles either. It's really ridiculous to have declarations in a user-agent stylesheet that cannot be overridden by any means.
Even Bootstrap https://github.com/twitter/bootstrap/issues/2985 counts with the requested behaviour. From what day mozilla do things after ie&chrome?
Jan, from the day when doing something else breaks websites.

Please read the entire history of this bug, including all of bug 349259 for the whole sordid story.
And one more note.  Per CSS spec, this property should have no effect on inline replaced elements.  Which is what buttons are at the moment, again per spec....
(In reply to Boris Zbarsky (:bz) from comment #4)
> Jan, from the day when doing something else breaks websites.
> 
> Please read the entire history of this bug, including all of bug 349259 for
> the whole sordid story.

From what I know at this point, mosts of websites works on IE, Chrome and Opera who're all implementing this behavior correctly. And, I'm pretty sure releasing a patch for this bug on FF nightly will let user find out if this behavior breaks out website or not. At least, you could take it to nightlies and decide once there.
> who're all implementing this behavior correctly.

My data, cited above, says otherwise.  Did something change since then?

> At least, you could take it to nightlies and decide once there.

Seriously, read the bugs!  I already did that once; people reported problems, I backed it out.  Now can we please stop wasting time unless there's actual new data to be had here?
Boris, I appreciate your position that "this is what the CSS spec says" and that FireFox is standing by its principles and adhering to that guideline. I am concerned, that the current behavior makes FireFox look bad from a designer/user perspective--especially on websites using Twitter Bootstrap or trying to do more than the seemingly text-only orientation of the discussion in the section of the CSS spec that you cite. For example, trying to do a horizontal form with a text input and a button input that are the same size. (Specifically, the button ends up being smaller because it ignores line-height.) 

It is very interesting that you argue that inline elements are not allowed to listen to line-height. I look at Bootstrap's css-tests.html page, in the Forms section, and see an example with an inline text input, an inline button input, and an inline button (all styled with inline-block, font-size 1rem, line-height 1.618em) where the text input and button are one height, but the button input is another. Firebug reports different line-height calculations for the button-input compared to the other elements. This kind of inconsistency is difficult to understand. Perhaps you could help?

Likewise, the decision to ignore line-height seems to be causing other problems where adjacent elements in a horizontal form are not the same height, and where establishing a consistent height is not trivial, requiring different values for different font-size values (responsive text designs).

I looked through the other bug referenced. I found it interesting that you cited YouTube because they "depend on the web browser ignoring" their CSS. I question whether relying on a browser to ignore a design is good design. If I, as a designer, put something in my CSS or HTML, I expect the browser to listen. I should at least be able to insist that the browser listen. A web browser that listens is especially critical for people doing responsive design.

Perhaps the issue is that the CSS spec needs to be revised to consider horizontal forms, which the current version does not seem to consider. That section of the spec seems to be very text-block centric. Perhaps the CSS spec needs to say that the currently described logic only applies to text elements, not to input, button, and other UI elements. If you don't think that's so, can you help me understand why? And if you do think that's so, perhaps you (who probably have a louder voice with the CSS-gods than many of us) could bring this issue up and ask them to consider changes to the spec that would allow designers to produce more consistent designs, and give Firefox a spec to comply to when making the design/user experience more consistent.
> It is very interesting that you argue that inline elements are not allowed

Inline replaced elements.  The "replaced" part is very important.

Furthemore, "inline" and "inline-block" are not the same thing; your example uses "inline-block".

> where the text input and button are one height, but the button input is another

Had you read bug 349259 (as comment 1 suggests) you would have seen that we allow line-height to affect <button> elements, just not <input> elements...

> I question whether relying on a browser to ignore a design is good design.

Of course it's bad design.  If you get YouTube and other sites that have such designs to stop doing doing it, I'm happy to change the behavior here.  Note that I tried once and had to back the change out because there were too many user reports of broken pages.

> Perhaps the issue is that the CSS spec needs to be revised

The main issue for this bug right now is that too many sites depend on the wacky behaviors of Gecko/WebKit/Trident in various ways and it's therefore hard to change any of those behaviors without breaking those sites.  There is no spec issue, and no real implementation issue with allowing line-height to have an effect (though if you want to allow the really weird WebKit behavior then there are both spec and implementation issues).  But there is very much a "compatibility with existing content" issue...
When I look at how the examples in css-tests render on Chrome and IE and compare them to what Firefox does compared to what the CSS code says to do, Chrome and IE are not the ones who seem wacky from a visual appearance and "doing what the designer said" perspective. You're standing on the letter of the spec. On the one hand I respect that from a principle perspective, but you're losing the battle from the designer/user perspective.

Yes, I did read that "we allow line-height to affect <button> elements, just not <input> elements". But that doesn't really explain the problem I'm seeing.

I tried putting a min-height on the submit, but that didn't change the height. When I put a height:1.618em on it (same as the min-height and line-height on the adjacent input text), the submit button gets shorter. (Computes ~16px on a font-size of 1rem (16px).) Setting height: auto Firefox inspector and Firebug tell me the submit is height:20px (based on line-height, I guess, which is computing at 20px even though it's 1.618em too). That explains why min-height doesn't make a difference. On the other hand, the adjacent input text has a min-height of 1.618em with no explicit height. When I set height:auto in it, Firefox and Firebug tell me it's height is ~26px. 

The way this looks to me (and probably a lot of other people) is that, the input type="submit" is not behaving like the adjacent input type="text". The way it appears is that 1.618em on a 1rem(16px) font-size is ~16px or ~20px on an input submit and ~26px on an input text. (You'll probably trot out the "replaced" thing again, which doesn't help make it work as desired or explain why the math is different.) Hearing, "Everyone else is wacky. We're the only ones doing it right," and "Because it breaks web sites that rely on the browser ignoring what the designer says," doesn't help web designers and Firefox users understand how to work around this "new math" where 1.618 * 16 = 16 in one place, 20 in another, and 26 in yet another.

Also, consider that W3C describes input type="submit" as a button. "The submit state represents a button that, when activated, submits the form." (http://www.w3.org/wiki/HTML/Elements/input/submit) Throughout the discussion on the referenced page, the submit input is referred to as a button. I'm sure you'll argue that input buttons are not buttons even though the language is very clear about describing them as buttons, that buttons means two different things. Again, you're standing on principle and losing the designers/users who are frustrated when the render on screen does not agree with the CSS. 

I realize you aren't going to change your mind about line-height, but the apparent workarounds don't seem to work--at least not consistently in the way mere mortals might expect. You're alienating designers and users because you're standing on principle (against the majority of browsers and against desired visual outcome) without explaining how designers trying to design forms like those in css-tests can get the desired results--preferably with CSS that works on all browsers so we don't have to do a Firefox-specific workaround. A little help here might go a long way to resolving the repeated complaints. And sorry if I've missed that help buried somewhere in the multiple bug reports. I've tried to find it, but haven't succeeded.
> Chrome and IE are not the ones who seem wacky from a visual appearance and "doing what
> the designer said" perspective.

Then you haven't tested their behavior carefully enough.  Chrome's behavior can't even be explained in terms of CSS.

> You're standing on the letter of the spec. 

No.  I suggest you read comment 9 again.

> I tried putting a min-height on the submit, but that didn't change the height.

Then you put a min-height that was smaller than the actual height.

> the input type="submit" is not behaving like the adjacent input type="text"

Well, one of them has border-box sizing and one has content-box sizing, by default. 

But none of that has anything to do with this bug; the long unrelated comments are just making this bug all that much less likely to ever be fixed.

> "Everyone else is wacky. We're the only ones doing it right,"

Please don't scare-quote things that no one ever said, ok?  Much less imply that I _did_ say such a thing, when I most certainly did not.

> I realize you aren't going to change your mind about line-height

I'm totally happy to change the line-height behavior as soon as I can do so without all sorts of web sites breaking....  I just don't see a way to get there from here. If you have a concrete proposal for what actions we should take in this situation, I'm all ears.
Oh, as far as help, please feel free to mail me privately and we can talk.  But this is a bug database, not a help system.
How about just saying the simple workaround so people who find this bug don't have to go through the frustration I went through? 

-moz-box-sizing:content-box;
min-height: (height);

Example:
-moz-box-sizing:content-box;
min-height: 1.618em;

will make an input type="button" the same height as an adjacent input type="text" with min-height: 1.618em. (And probably many other, similar.)

(Figured out after much blood, sweat, and tears and time that should have been spent on more productive things.)
It doesn't really make sense to distinguish input buttons and button elements.  Furthermore the fact that web developers / UI designers can't even override the behavior doesn't make sense at all.

The fact that this doesn't work even if I turn -moz-appearance off seems very unhelpful, provided that I can nuke the quirks in Trident/Webkit with a similar rule.

I understand that these changes are bound to cause existing websites to complain.  I understand it's a rough situation to choose between consistency and alienating other developers.  As standards have progressed, bugs like these are bound to crop up (e.g. The Arial Black situation).  Internet Explorer has survived even though they didn't budge their stance a bit.  I guess if this affects big sites (e.g. YouTube), I think it would be more an evangelism bug than anything else.  This is also one of the reasons why we have Nightly.

Leaving this unfixed means that to achieve visual consistency, webdevs need to hardcode heights, which tends to lead to fragile layouts when fonts change.

I hope my vote counts.
> I understand that these changes are bound to cause existing websites to complain.

Sites complaining we can deal with.  The problem is sites being no longer usable for our users.

> I think it would be more an evangelism bug

We tried.  Youtube wouldn't fix their code; they claimed it works in every browser right now so must clearly be correct.

> This is also one of the reasons why we have Nightly.

We tried this in a nightly and had to back it out because too many sites were broken too badly.  As you'd know if you had read the bug...
I'm not sure if I misread the bugs though, it seems that YouTube is only affected by the line-height in text fields?  It certainly doesn't make sense that <input type=button> is different than <button>.

It's a second thing that website developers can't override this.

I do understand "rendering slightly bad" is better than "not rendering at all".

With the testcase in bug 349259 on latest Webkit, the behavior is simply cap line-height at a minimum of normal for text fields (native or not), cap line-height at a minimum of normal for native <input type=button>, and let the developer screw everything for <button>.  At least this approach gives me the ability to specify a larger line-height, instead of relying on display:flex and other heavyweight solutions to align buttons and input (and other display:inline-block elements).  Whether or not Gecko chooses to take this yucky behavior, I am quite sure not with my experience.  However I must point out it is a rightful compromise for them.

As of today, I just checked the YouTube CSS (on Google Chrome, if that makes a difference), and it only contains two references to line-height:0, and these are already font-size:0.

For sony.jp, they even specify " button, input { line-height: normal; } " with an (erroneous) comment referring to Firefox.

I doubt the result two years ago is still relevant today.  Anyhow, if there is any list of websites that broke, I'll willing to spend time to check if they are still relevant today :)
> It certainly doesn't make sense that <input type=button> is different than <button>.

It does, actually.  They have totally different behavior in terms of how their contents are rendered.  Try sticking an image inside an <input type="button">...

> I doubt the result two years ago is still relevant today.

You're welcome to take the trivial patches involved, apply them locally, and test the sites involved.  Those are all listed in bug 349259 and its dependencies.  If they no longer have problems, we can try checking those patches in again.
349259 - http://host.epper.org/firefox/line-height.html - GONE (Unavailable via Web Archive either :( )
attachment.cgi?id=529629 - input/input type=button/button consistent
attachment.cgi?id=440225 - Behavior now same as the attached "webkit" rendering.  Chrome's rendering is now Trident's.
attachment.cgi?id=591049 - Did not test, irrelevant.

658982#c0 - This UI is not used in YouTube anymore.  The current YouTube search bar renders the same between patched build / unpatched / Blink (only difference is the text - D2D vs GDI).
NOTE: The change DOES affect how the testcase renders: it shrinks up.  This is arguably expected since we (or just I) expect Firefox to honor its small line-height.

658982#c6 - No rendering difference.  As mentioned before, they specified {line-height:normal} in their global stylesheet already.

For some other bugs I went through anyway, to make sure I didn't miss anything:
485335 - exact same rendering
494126 - irrelevant (never fixed either) exact same rendering (testcase and link)
425004 - irrelevant but anyhow exact rendering
82265 - exact same rendering
45745 - irrelevant, optgroup specific (did not test)
82626 - irrelevant, select specific (+exact same rendering)
90884 - exact same rendering
118386 - exact same rendering for all 3 testcases
128115 - irrelevant, same rendering anyway
146096 - exact same rendering
171214 - irrelevant, same rendering anyway
155483 - irrelevant, same rendering anyway
Attached file Testcase.697451.html — 

    
    

    
  


  

    
    

    
  
Sounds good.  If someone commits to watching for bug reports about this issue, we can try this again in nightlies.

    
    

    
  
I would very much like to volunteer, however my skills stop beyond CSS.  Anyhow, if any bug reports crop up, we could always back it out if it breaks a lot of sites, can't we?  I've been browsing for quite a while now (Facebook, etc), and nothing jarring has come up yet.

    
    

    
  
> Anyhow, if any bug reports crop up, we could always back it out 

Sure. The issue is noticing the bug reports before we've shipped.  _That_'s what requires someone to basically watch all incoming bugs looking for bug reports related to this issue.  It doesn't need any particular skills; just time.  :(

    
    

    
  
Is there any interface which can assist me in doing that?

    
    

    
  
Just watching bugzilla bugs as they come in.... :(

    
    

    
  
Is there any interface which can list new bugs as they come in?

    
    

    
  
Great... Is it possible the bug be patched now?

    
    

    
  
Is someone committing to watch out for regressions?

That said, I just had an interesting idea.  David, how do you feel about adding a new property (say -moz-allow-small-lineheight or something) that would be set to "no" or equivalent on inputs.  When set that way, a computed line-height smaller than font-size (or smaller than 1 if set as a number) would be clamped to font-size.  That seems like it would get us the WebKit/Trident behavior, more or less.
Flags: needinfo?(dbaron)

    
    

    
  
Oh, and we could probably not expose that property in computed style and disallow setting it in unprivileged stylesheets, to avoid exposing Yet Another Prefixed Thing on the web.

    
    

    
  
A new property seems a little excessive; we could just hard-code the behavior in C++ code.

(It might also be possible even without C++ code, if there is an *inline* inside the input with a line height of 1.0.  Though that depends on there happening to be an inline inside the input.)
Flags: needinfo?(dbaron)

    
    

    
  
That said, I'd be ok with the new property.

    
    

    
  
> Though that depends on there happening to be an inline inside the input

There definitely isn't inside button inputs, and pretty sure not inside text inputs.

I'm pretty happy hardcoding in C++ too, just wasn't sure where a good place to do that would be.

    
    

    
  
David, see comment 33?
Flags: needinfo?(dbaron)

    
    

    
  
Off-radar?

    
    

    
  
nsLineLayout::VerticalAlignLine, probably right after the call to VerticalAlignFrames?
Flags: needinfo?(dbaron)

    
    

    
  
I just landed bug 349259, which fixes this bug for line heights greater than orequal to 1.0; I'll use this bug for seeing if we can fix inputs other than text types for line-heights less than 1.0.

    
    

    
  


  
This allows *native-themed* button-type inputs to shrink more than
Chromium allows them to, but it might still be Web-compatible.

        Attachment #8390312 -
        Flags: review?(bzbarsky)
Assignee: nobody → dbaron
Status: NEW → ASSIGNED

    
    

    
  
Comment on attachment 8390312 [details] [diff] [review]
Stop overriding line-height (max-ing with 1.0) on inputs other than single-line text inputs

r=me

        Attachment #8390312 -
        Flags: review?(bzbarsky) → review+

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/0e768e11d2c6
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla30

    
    

    
  
That, in turn, means that this should be fixed for Firefox 30, unless something changes (which could certainly happen if it leads to regressions).

    
    

    
  
And we have our first compat issue from this change... :(

    
    

    
  
Compat doc coming.
Keywords: site-compat

    
    

    
  
Should probably say "increase (but not decrease) the value" instead of "modify the value"?
Flags: needinfo?(kohei.yoshino)

    
    

    
  
Thank you again Boris! Fixed.
Flags: needinfo?(kohei.yoshino)

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
  
Restrict Comments: true

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: