Button: Fixed 5254: Input, button and anchor buttons aren't consistent in IE7 #273

wants to merge 3 commits into


None yet

5 participants


Fixed 5254: Input, button and anchor buttons aren't consistent in IE7. They really weren't consistent in any browser. Now they are. http://bugs.jqueryui.com/ticket/5254

There is some heavy use of CSS hacks to get the buttons to play nicely together. Most of the hacks are well-known: _ (IE6), !ie (IE6-7), \0/ (IE 8-9), and a new one I haven't named yet for IE9 (goo.gl/OCKzi).

davidmurdoch added some commits May 13, 2011
@davidmurdoch davidmurdoch Fixed 5254: Input, button and anchor buttons aren't consistent in IE7…
…. They really weren't consistent in any browser. Now they are.
@davidmurdoch davidmurdoch The \0/ CSS hack needs a space before it to target only IE, otherwise…
… it will apply to Opera as well. Thanks mathias.
@jzaefferer jzaefferer commented on the diff May 15, 2011
@@ -36,3 +42,11 @@ input.ui-button { padding: .4em 1em; }
/* workarounds */
button.ui-button::-moz-focus-inner { border: 0; padding: 0; } /* reset extra padding in Firefox */
+@-moz-document url-prefix() {
jzaefferer May 15, 2011 jQuery Foundation member

Do we really need two different moz specific hacks? Or in other words, can't you use ::-moz-focus-inner or the moz-document thingy for both of these?

davidmurdoch May 16, 2011

I believe ::-moz-focus-inner acts similarly to ::after and ::before in that the CSS rules don't apply to the element itself, but some psudeo element, instead. So, -moz-focus-inner isn't really a hack...it is modifying the focus "ring" in firefox (http://stackoverflow.com/questions/71074/how-to-remove-firefoxs-dotted-outline-on-buttons-as-well-as-links)

davidmurdoch May 20, 2011

I sounded like I wasn't sure about '-moz-document url-prefix()' so I just want to make it clear that I am positive about what I said in my previous statement. :-)

@davidmurdoch davidmurdoch Updating the IE9 hack to be less verbose - the media expression wasn'…
…t actually needed. Also, I've appended "ie8+9" and "ie9" to the end of the winning-man hack, aka \0/, just to show exactly what that hack targets (don't want to confuse future devs TOO much).

Hi guys. This seems like an awful lot of hackiness to fix an edge case -- when will a button, input, and anchor element (or some combination) with identical styles sit side-by-side in a real site? My understanding is that we want to avoid browser-specific hacks whenever possible, so I vote that we don't include this fix, and instead rework the button demo page so that it reflects a more realistic scenario (and looks better).


I agree, it is pretty hacky; but jQuery ui buttons are expected to look identical, or as close to it as possible, regardless of their node-type.

While these browser hacks may not be the best solution, modifying the demo page just to hide an inconsistency in the library is definitely not the way to go.


I'm not suggesting that we do anything sketchy like "hide an inconsistency." I'm questioning whether the inconsistency here is a real problem, or a perceived one because of how the demo pages are set up. I can't think of a use case where different markup for each button is absolutely necessary on the same line.

When we start integrating hacks to this degree -- for multiple browsers and versions -- we start down a path that I think is unsustainable. And it doesn't seem justified in this case.


I don't know whether the extra css hacks are justified here, but the problem is real. Here is an example use-case of a relatively common button layout: http://jsfiddle.net/musicisair/vHRfF/.

jQuery Foundation member

I think that the best solution would be to include the CSS hacks, or better yet find a way to do it without browser specific hacks, on the DEMO / documentation pages. If someone happens to run into the situation where they need a <a> <input> <button> and <div> button all on the same line - we should at least document what is needed to make it happen.

We avoid browser specific hacks, and this whole pull request feels like one.

jQuery Foundation member

Thanks for contributing this pull request! However, we're going to close it as the original ticket describes the approach we're going to take during the rewrite, which is to wrap the native elements in a consistently styleable element. Thanks again!

@mikesherov mikesherov closed this Nov 10, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment