Input, button and anchor buttons aren't consistent in IE7

visual test: http://jquery-ui.googlecode.com/svn/trunk/tests/visual/button/button_ticket_5254.html

From FJ on http://blog.jqueryui.com/2010/03/jquery-ui-18/#comment-1269

I tested the buttons on IE6,7,8 and 9 preview:

• IE6: http://i44.tinypic.com/wcl103.jpg
• IE7: http://i40.tinypic.com/14t7iq0.jpg
• IE8: http://i44.tinypic.com/2hq83s3.jpg
• IE9: http://i41.tinypic.com/2iitvtz.jpg

Fixed in https://github.com/jquery/jquery-ui/pull/273

Replying to [comment:6 davidmurdoch]:

Fixed in https://github.com/jquery/jquery-ui/pull/273

As noted in git, I don't think this fix is necessary. I'm also not sure why this was ever marked as a critical bug? :) The differences between these buttons are negligible, and are noticeable only when they sit right next to each other -- is that a realistic use case? If the problem is how the buttons appear on the demo page, let's use a more realistic example on the demo page instead of incorporating a slew of hacks into the CSS for an edge case.

I agree that this is not a fix that is needed. I am currently using the buttons within a modal where we have a "cancel" and "confirm" button that sit next to each other and they work well.

One way to fix this inconsistency with no CSS hacks would be to override the original element with a new one. That way, no matter what element is declared, it will produce the same HTML. The new element can be added immediately after the original, and the original can be hidden. On removal, just remove the created element and show the original.

I do think a fix is needed but I am not sure there is one. These buttons do not work consistantly in IE 7. I have run into several examples of the behavior being posted here and I would be happy to provide more examples of goofy IE7 behavior if anyone thinks it would help. The biggest most glaring example being the jQuery UI documentation/demo page for the buttons that does not work properly when using IE7. View it in any other browser, everything snaps into its correct position.

Replying to [comment:9 straussm]:

One way to fix this inconsistency with no CSS hacks would be to override the original element with a new one. That way, no matter what element is declared, it will produce the same HTML. The new element can be added immediately after the original, and the original can be hidden. On removal, just remove the created element and show the original.

This is an interesting idea because I have seen differences in the way that IE 7 treats a div with the button() call on it and a button with the button() call on it. I have different results based on how its being used but in at least one case, things work better calling button() on a div tag than a button tag.

I'm clearly in a case where I need Cancel / Delete buttons close to each other. This is ugly, whatever the browser. This is not to me a strange use case (please, have a look at Google Mail buttons layout for example) and should be fixed.

I'm still of the opinion that this needs to be fixed or a different approach taken. The idea of replacing / overlaying a div structured button is an interesting one, but I'm unsure about the accessibility issues that might be at play. If we definitely need to retain the input / button / a element, is it possible to involve an additional element to make standardisation across browsers easier?

Do any other styles in jQueryUI require additional effort for certain browsers?

We'll address this as part of the rewrite, following the jQuery Mobile approach, which avoids styling all these elements consistently and instead just wraps the native element in a generic, styled element.

We're no longer landing bug fixes for IE7 and will fully drop support soon.