User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030204 Phoenix/0.5 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030204 Phoenix/0.5 The border atrribute in <input type=image ... border=1> improperly shrinks the image by one pixel in each direction. In my test case, the correct width= and height= are specified, but the browser atttemps to squeeze the image _and_ border into that space. So the image appears broken up a bit by the bad resizing. Reproducible: Always Steps to Reproduce: 1. Create a form with an image input control <input type=image src=...>. 2. Add the correct width and height attributes and border=1. 3. Compare to the equivilant <img src=...>. Actual Results: The input image in badly resized, differing from the <img...> equivilent. Expected Results: The input image should be identical to the <img...> in size, or should ignore the border attribute. Exactly how Mozilla should treat <input type=image ... border=1> is debatable, but it should not resize the image. Possible renderings include: 1. A one pixel border in the default border color. 2. A one pixel border in the link color. (Netscape 4.7 does this.) 3. Ignore the attribute and require CSS. (Opera 6.50 and IE6 ignore border=1, but you will not find CSS much help for this tag in those browsers.) It should probably render very like an <img...> within an <a href...>...</a>, and have the same CSS available. Support for input image attributes is generally bad in other browsers, although "align" does usually work. Netscape <=4.7 was unusual in setting a colored two-pixel border by default, even with no border attribute. I originally posted this info in Bug 171598, but the fix for that transparency bug did not fix this bug.
This is due to our box-sizing quirk on inputs... Should this quirk really apply to <input type="image">? (it has all along, of course). In standards mode we treat the border as being in addition to the specified width.
The box-sizing quirk probably shouldn't apply to inputs with type=image.
15 years ago
Comment on attachment 113599 [details] [diff] [review] something like this, perhaps? Could this please be approved for 1.3b? It makes us a little less quirky in the case of <input type="image">....
Comment on attachment 113599 [details] [diff] [review] something like this, perhaps? We're trying to get 1.3beta out the door. This is going to have to wait.
15 years ago
Comment on attachment 113599 [details] [diff] [review] something like this, perhaps? Are drivers ok with taking this de-quirk for 1.3?
Comment on attachment 113599 [details] [diff] [review] something like this, perhaps? a=asa (on behalf of drivers) for checkin to 1.3 final.
fixed for 1.3final.