2007-02-06 09:11:23 Chris Petersen: * SUMMARY With TOT, the "Find Jobs" input button (type=image) is misaligned on page. See attached screen shot. * STEPS TO REPRODUCE 1. With TOT, go to http://www.flipdog.com/ 2. Notice the misaligned "Find Jobs" button. 3. This problem doesn't occur with stock Safari under Tiger or with FF 2.0.0.1. I have a reduction test case called "flipdog.html" that reproduces the problem. The DOCTYPE of this HTML file is STRICT which is required to reproduce this issue. * RESULTS "Find Jobs" input button (type=image) should be displayed correctly on page * REGRESSION Yes 2007-02-06 22:37:15 Beth Dakin: Something about this bug is specific to strict mode. When I remove the doctype, it renders fine. 2007-02-06 22:49:07 Beth Dakin: I attached a slightly smaller reduction. 2007-02-06 23:07:35 Maciej Stachowiak: What happens in other browsers with this file? Is it a bug in our strict mode? 2007-02-06 23:10:07 Chris Petersen: This problem doesn't occur with stock Safari under Tiger or with FF 2.0.0.1 with this Strict DTD. <rdar://problem/4978574>
Created attachment 13045 [details] Reduction
The web inspector shows a computed width of 209px for the <form>. Firefox's DOM inspector shows a computed width of 205px. The extra 4 pixels are from the 1px of padding we put around every <input> element in html4.css. Firefox has 1px on top and bottom, but 0 on left and right. I'm not sure if this should be fixed in html4.css or if this is something that we should adjust during layout. It is also worth noting that this reduction requires a strict-mode doctype. Without the doctype, it renders correctly.
Adele -- cc-ing you to see if you have any input on the htm4.css part of this bug. Like I said, could be a layout issue. Is it right to have 1 px of padding on all sides?
We have a rule in html4.css to override the 1 px padding for input type="image" (line 362), so I don't think that's it. I think the cause of this is the quirk we have for text fields where we use box-sizing: border-box in quirks mode, and content-box in strict mode. So their hard-coded widths are off when we leave out border + padding in our width calculation.
oh no! the 1 px of padding is not coming from the input type=image...it's coming from the two input type=texts...hence the extra 4 pixels.
I think you may still be right, though. Just wanted to clarify that the padding that seems questionable is on the text inputs, not the image.
The issue here basically boils down to: (1) We now respect border on text fields (just like FFX) (2) In strict mode this border is excluded from the width (just like FFX) (3) We have 1px padding on our text fields by default (this is not like FFX). Firefox's text fields actually look like crap because they have too little padding. The site in question is clearly buggy in that it does nothing to override padding, so it has no idea what those values might be for a given form control. Here are our options: (1) Remove the padding to be more like Firefox. Would result in ugly controls that don't match AppKit. (2) Remove the padding only if the AppKit look gets turned off. I still think this results in ugly controls if you end up styling the border. (3) Ignore the strict mode box-sizing behavior and just make form controls always use border-box box-sizing. I actually think this is potentially a really good idea. It does not match Firefox, but I think it might match WinIE (and make more sense to users of form controls). (4) Evangelize the site.
I tested in WinIE,7 and they render just like ToT. This is a bug in the site. WinIE also has a pixel of padding by default on text fields. This is clearly an evangelism issue.
The site itself even misrenders in IE7, so I expect they will (ahem) be revving soon.
I checked the page with Webkit r30123 and I don't notice misaligned "Find Jobs" button. So the bug is fixed. Funny thing it's still misaligned on IE7 ;)