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

[davidmurdoch]

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).

[jzaefferer]

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]

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]

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. :-)

[maggiewachs]

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).

[davidmurdoch]

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.

[maggiewachs]

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.

[davidmurdoch]

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/.

[gnarf]

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.

[mikesherov]

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!