489284 - possibly incorrect height computed for statically positioned, block-level button

Status: RESOLVED DUPLICATE of bug 140562

(Core :: Layout: Form Controls, defect)

Description

[philentropist]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8

On the linked page, the button (left) is taller than the p (right) although both have the same style rules.  Inspecting the DOM and performing a diff shows that the only differences are the computed height and computed -moz-user-select property.

Chrome renders the same as firefox, but safari renders both elements with the same dimensions.  This behavior seems wrong, but I can't tell for sure from the css specifications.

Reproducible: Always

Steps to Reproduce:
1. See source on linked page
Actual Results:  
button and p have different height

Expected Results:  
button and p should have the same height

Comment 1

[Kevin Brosnan]

bug 471763 talks about similar issues with <button>.

Comment 2

[Kevin Brosnan]

Attachment: testcase from url

Comment 3

[Boris Zbarsky [:bzbarsky]]

Bug 471763 is not really relevant here, because it has to do with the handling of absolutely positioned boxes; this box is statically positioned.

What's happening here is that the page overrides box-sizing on the button and sets the padding to 0, but the padding on buttons is never allowed to go to zero in practice because we leave room to paint a focus indicator.  That is, there is some non-CSS padding on those buttons.  Safari (at least on Mac) doesn't do that because the focus indicator is painted outside the button.  We want to size our buttons the same on all platforms, though, so even on mac we leave the focus indicator space.

I could swear we have existing (invalid/wontfix) bugs on this, but I can't find them (apart from bug 427265 which mentions this as part of a whole list of "issues").

Comment 4

[philentropist]

Is there any reason not to paint the focus indicator inside the css padding (or the content area if padding is too small) instead of adding extra padding?

As far as I know, the specs don't give a standard amount of padding to add to a button, so it makes it difficult for designers to create buttons that look consistent across browsers.  It also makes it difficult to put a button next to a link and have them styled the same (for instance a button that issues a post query and a link that issues a get query).

Painting the focus indicator inside the padding area would aid compatibility with other browsers and give designers more power.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Is there any reason not to paint the focus indicator inside the css padding

Yes: sites commonly set that to 0.

> or the content area if padding is too small

Then it overlaps the text and creates a terrible user experience.

> As far as I know, the specs don't give a standard amount of padding to add to
> a button

Further, the specs don't say anything about what applying CSS to a button does or doesn't do.  And they _do_ explicitly say that they don't say this.

> it difficult for designers to create buttons that look consistent across
> browsers

This is true, but if that's your biggest worry then native theming is a much bigger problem for you than the padding issue here...

> It also makes it difficult to put a button next to a link and have them
> styled the same 

Agreed.  This is indeed a problem.  I don't see a good solution...  The right place to discuss such a solution would be [e-mail].

> Painting the focus indicator inside the padding area would aid compatibility
> with other browsers and give designers more power.

It would also not work well with existing sites (and not give very good IE compat, for that matter).

Comment 6

[Emil Ivanov]

If the button from the testcase is styled with ::-moz-focus-inner {border:0;} there is no difference between the elements.