Update default button styles in core

[lessbloat]

Wondering if it's time to put the pill button to rest... ;-)

In 21598.diff, I hacked together a quick patch to replace the existing default buttons with button styles designed by Automattic for the WP.com reader (props @iammattthomas).

This will need some serious testing, as it affects lot's of pages.

Here's a quick comparison:

Have a look, and let me know if you spot anything out of place.

From the screenshot they doesn't look quite pretty.

But please no -o-box-shadow, -ms-box-shadow and -moz-box-shadow.

Replying to ocean90:

From the screenshot they doesn't look quite pretty.

Can you please explain a bit more? What do you like/not like? :-)

The secondary button looks like an inactive button because of the color. Grey on grey isn't the best contrast.

Should it be a 3D Button? Since the secondary button has a darken bottom line/shadow but, if you take a look at zoom.png​, the primary button not.

Also the light blue line at the top of the primary button looks misplaced, it looks like a missing blue line. On wp.com it's better solved.

Replying to ocean90:

I appreciate the feedback, thanks.

I took another pass at these in 21598-v2.diff

The v2 buttons look good. Few releases ago there was a last minute css error (ok, it was my fault) making some of the buttons in the admin with border-radius: 3px:

Trying this again makes them look somewhat small, at least in QuickPress. Perhaps we can increase the padding a bit but not make them taller than the text input fields.

It's about time our buttons were updated to have mouse-nibbled corners. I'm a fan of v2. I think the shadow on the over state might be a little too aggressive, but that can be tweaked.

I'm not sure the size of the buttons work as well in a few scenarios, especially with the large text size on smaller buttons. We may want to explore having several sizes of buttons for this purpose. After looking through the patch, also I'm noticing quite a few inconsistencies in the size and spacing of the buttons. I'd like to address these sooner rather than later — if we want to do this for 3.5, we should get the patch in on the early side to allow us time to find and fix any issues we miss.

I've refreshed the patch to account for the move from .dev.css to just .css in [21592].

Replying to koopersmith:

I'm not sure the size of the buttons work as well in a few scenarios, especially with the large text size on smaller buttons. We may want to explore having several sizes of buttons for this purpose. After looking through the patch, also I'm noticing quite a few inconsistencies in the size and spacing of the buttons.

Mind sharing a screen of these, or shooting me a list of areas you think need some attention? I'm happy to make another pass.

As discussed ​in UI chat today, Helen has also been ​experimenting with button styles, and will take a shot at revising the patch.

I'm curious if we can communicate importance better through various sizes and styles of buttons (like those found in Helen's styles). ​Bootstrap's buttons are particularly inspiring.

Replying to lessbloat:

Mind sharing a screen of these, or shooting me a list of areas you think need some attention?

Off the top of my head, the filter buttons on the list tables, and the buttons in the publish box and permalink actions on the edit post screen.

Going for it. If we haven't done it in the next week, we should punt it back out.

21598.4.diff​ is a fresh look at the patch, with a bunch of tweaks to classes on various buttons to account for having some lovely new structures for small and short buttons (and larger, but unused in core). The blue button could use some crisping up, probably with the nice light inset shadow (highlight) on the top.

The real goal of the patch is to have something more structurally sound in place for the CSS - colors can be tweaked from here, and any funky spacing issues addressed as we sweep around the admin. I'm also pretty sure we can do better with the selectors, especially the ones in large groups that just keep living.

A bigger picture item to keep in mind is that we should be creating something that is reusable by additions to the admin. We may need to create a little plugin to have an example/component styleguide type of page for full testing.

Example from the post screen: Screen Shot 2012-08-30 at 1.09.51 AM.png​

One more thing: I wanted to note some pitfalls I ran into for whoever picks this up next. Firefox does not apply line-height to input buttons (ARGH), and browsers do all kinds of fun and different things when em values end up in partial pixels. Be looking in multiple browsers at all times, especially for this.

In 21598.5.diff:

• Added :focus styles
• Played with a few highlights
• Played with :active styles

Have a look, and let me know what you think.

Small button tweaks: text-shadow on top for primary button, hover style for focus, slightly darker border on focus

21598.5b.diff​ is looking quite nice to me. We might still want to consider making a demo page with various button types/common layouts, especially if we still add some extra goodies for extensions to use. Would love eyes on this and a sweep around the admin, especially with plugins and such.

First draft of a "style guide" plugin. Adds a new admin page with all button styles.

Err.. wrong file. Here it is!

21598.5b.diff​: The outer shadow on mouse over should be reduced. 0 0 1px looks good in my eyes.

I would highly encourage those working on these buttons (thanks, by the way!) to consider :focus styles that are several orders of magnitude more obvious. I say that as someone with "normal" vision who prefers to keep both hands on the keyboard whenever possible; I would imagine that for someone who is vision-impaired but not blind this would be even more important.

Slight tweak to box-shadow - bring it down a notch.

adds .focus, .active, and .hover styles (and adds some missing .button-highlighted styles)

(plugin) 5 buttons times 5 states

same plugin, less yelling

add missing 'short' style

Patch adds .focus, .active, and .hover styles to make it easier to check styles (without needing to actually focus/activate/hover).

In doing so, discovered some missing styles for the highlighted button style and added those.

Also sharing a plugin that displays 6 styles of buttons (Primary, Secondary, Highlighted, .button, .short, .small) in 5 states each (normal, :hover, :focus, :active, disabled)

Would it be preferable to create a re-usable function to render all the button variants?

Preview of buttons.3.php with 21598.6.diff applied:

Disabled buttons shouldn't have any :hover styles assigned.

Replying to travisnorthcutt:

I would highly encourage those working on these buttons (thanks, by the way!) to consider :focus styles that are several orders of magnitude more obvious.

lessbloat and I discussed the focus state in a previous patch, where they were more obvious but had the "depressed" look, which also seemed wrong. Suggestions (from anybody) about focus state are welcome. I am also largely a keyboard user and so far find them to be serviceable, but we're always interested in alternatives.

In the mock-ups, the text looks a pixel or two too high (line-height issue?) Either that, or too much bottom padding.

azaozz's alignment in comment:8 appears more balanced to me.

Replying to helenyhou:

lessbloat and I discussed the focus state in a previous patch, where they were more obvious but had the "depressed" look, which also seemed wrong. Suggestions (from anybody) about focus state are welcome. I am also largely a keyboard user and so far find them to be serviceable, but we're always interested in alternatives.

I agree that a "depressed" look, while great for an action like clicking, is not the right solution for :focus and :hover states.

How about gradients that are visually lighter than their base state? Think of it as the *opposite* of depressing a button; by making them several shades lighter, they leap out a the viewer a bit, which is a better metaphor for focus IMHO.

21598.7.diff​

• removes :hover styling from disabled buttons (:active still there though)
• reduces bottom padding very slightly. Tried changing line-height, but that only worked in Chrome, not Firefox

buttons.5.php​

• incorrectly had 'active' applied to the disabled buttons
• incorrectly used null
• adds 'big' button style

Together:

In [21789]:

New button styles.

Using the new buttons:

• Button classes are now stackable.
• All buttons should use a base class of "button".
• Buttons default to the gray style (formerly "button-secondary"). Buttons can add a style by adding additional classes. To make a primary button, add the "button-primary" class.
• Buttons can be rendered in various sizes. In addition to the default size, you can add "button-large", "button-small", or "button-tiny".

For backwards compatibility reasons, "button-primary" and "button-secondary" both work as standalone classes.

get_submit_button() has been adjusted to handle shorthand button classes (i.e. button classes can be passed without the "button-" prefix).

props lessbloat, helenyhou, trepmal, nacin. see #21598.

IMO the link/button on Update Network screen should be a small button.

21598.theme-search-buttons.patch​ adds small to submit_button for theme search buttons.

21598.remove-small-style.patch​ removes .small.active, .small:active styles from colors-fresh.css.

Small buttons for custom fields: #21847

The new get_submit_button() does not seem to transform $type='secondary' to a CSS class .button-secondary. Is that on purpose?

Also: What's the idea of adding all of those .XYZ.focus and .XYZ.hover selectors? I can see a use case for .XYZ.active in button groups (though that would also need extra CSS), but what the use case for .focus, .hover and .active here? Why are :focus/:hover/:active not enough?

1. Looks like disabled primary buttons still have a hover style (text-shadow).
2. There is a size difference between button and button-primary which is noticable on the Updates screen: (Firefox 15.0.1 on Win7)

Some wonkiness on the Customize screen. Firefox 15 on Win7 the buttons are different sizes:

Chrome 21 on Win7 the buttons aren't vertically aligned:

Safari on iPad, button text isn't cetered vertically. Trunk compared to 3.4:

I think the change in size of buttons is going to cause some issues. Buttons by default have 20% more height than they did in 3.4.

I think default buttons should be the size that button-small is currently, and anything that needs some extra size should be given button-large and button-largest classes which have the size of the current default buttons and button-large buttons respectively.

Thoughts?

Replying to ocean90:

IMO the link/button on Update Network screen should be a small button.

Also, "click this link" should probably be replaced with "click this button".

[21789] broke AJAX in custom fields: #21852.

The secondary buttons are too bulky.

Old:

New:

Note how the new buttons are several pixels taller than the dropdowns.

I guess you can get the old height by adding the .button-small class, but it's something that plugin devs need to be aware of.

Current size names:

.button-tiny
.button-small
.button        (default)

Proposed:

.button-small
.button        (default)
.button-big

scribu, since [21789] there's also .button-large. That would then remain bigger/larger than .button-big? :-) (Ah, fun with names... :-) )

And can maybe someone please explain the extra CSS classes like .hover/.active to me (see my comment above)? Thanks!

And can maybe someone please explain the extra CSS classes like .hover/.active to me (see my comment above)? Thanks!

What should we explain here? If a plugin author needs to style a button like an active button he can use the class. Nothing more.

Thanks, Dominik. I do understand this use case for .active (button groups), but for .focus and .hover this doesn't really make sense. I really don't think that this will be done a lot. IMO, it's just bloating the CSS, especially as core is not using it.
If a plugin dev really wanted to do this, why don't we let him do it himself in his own CSS?

Replying to johnbillion:

I think default buttons should be the size that button-small is currently, and anything that needs some extra size should be given button-large and button-largest classes which have the size of the current default buttons and button-large buttons respectively.

It seems that we should make the swap, yeah :) Maybe something not -large and -largest. I'm not 100% on needing what's currently called large with the larger font size, even as a component for other use - maybe just replace it. Or call it jumbo or something.

setup-config.php and install.php still have the old button style. It looks like those buttons are also the only ones in core that would actually use the button-large style. I can't find button-large used anywhere currently, otherwise.

Replying to johnbillion:

Some wonkiness on the Customize screen. Firefox 15 on Win7 the buttons are different sizes

Related: #21889

Since we are rewamping both the button styles and the Upload/Insert media interface in #21390, shouldn't we grab this opportunity and apply our sweet new button style to the Upload/Insert media link?

We can actually see this link rendered as a button in the first pages of the wireframes at ​http://make.wordpress.org/ui/2012/07/30/media-wireframes/ which seems a really obvious improvement to me... but I don't find any mention of this change here in trac.

I would see it as a big UI improvement to have that link styled as a button.

Replying to tar.gz:

I would see it as a big UI improvement to have that link styled as a button.

You are probably looking for #19956.

Seeing some inconsistencies in Firefox:

The buttons seem a bit too large there? Save and Reset are too close?

Looks like these should be the same size.

Again, the 3 buttons are different size.

This Save is huge there?

All 3 are quite different size :)

Not sure about the .hover, .focus and .active classes too. Using them will disable the corresponding CSS states and make that button's behavior inconsistent. Even worse, the user would not be able to tell when .button.active is "activated" by tabbing.

If a plugin really wants to make its buttons different, best would be to add couple lines of CSS.

Replying to azaozz:

Not sure about the .hover, .focus and .active classes too.

I'm pretty sure they were just intended to be used with the plugin in: http://core.trac.wordpress.org/ticket/21598#comment:27

A way to see them all visually on one page.

21598.9.diff consolidates:

• 21598.upgrade-small-button.patch
• 21598.theme-search-buttons.patch
• 21598.remove-small-style.patch

in addition:

• Removed hover style in disabled primary buttons - #comment:33
• Fixed button and button-primary size difference - #comment:33 & #comment:53
• Fixed customizer button sizes and alignment - #comment:34
• Fixed QuickPress button sizes and margin - #comment:53
• Change widget save buttons to button-small - #comment:53
• Changed "upload" button to button-small - #comment:53

Remaining issues:

• Make button-small the default button size - #comment:36, #comment:41
• setup-config.php and install.php need new button styles (do we include wp-admin.css and colors-fresh.css, or extract the button styles into their own CSS file?).

Replying to lessbloat:

I'm pretty sure they were just intended to be used with the plugin...

Ah, that makes sense for testing not in Chrome or FF/Firebug. Shouldn't comment on trac before the first coffee :)

#21889 was marked as a duplicate.

21598.10.diff adds a bit bolder :focus styles:

Related (closed) #21958 - The secondary button/tablenav icon is still full sized, vs the other buttons on that row. Most apparent when you have Akismet on and go to look at comments.

Notes for 21598.11.diff:

• Added new focus styles to colors-classic.css
• Made small the default button size (also fixed Akismet plugin "check for spam" button)
• Fixed tablenav alignment
• Fixed search box button alignments (across multiple pages)
• Lightened up grey buttons a bit more
• Increased tiny button font-size from 11px to 12px
• Fixed QuickPress button alignment

If we can commit this updated patch, that might help us in finding additional areas that can be improved. Please have a look, and post additional bugs that you find.

Removed button-tiny, button-medium, and button-jumbo in 21598.12.diff.

Now we are left with:

• button-small - fits well next to text or select box
• button - regular button size
• button-large - most button-primary buttons inherit this style (slightly taller)

In [21944]:

Updates and fixes to the new button styles. By default, buttons are now the same size as they were in 3.4. Then there is a smaller button (designed for minor elements) and a larger button (designed for things like Publish and Save Changes). Better focus styles. props lessbloat. see #21598.

I have some reservations about the line-height, as Firefox will not apply it to inputs but will apply it to other HTML elements. However, a brief excursion into attempting to change it ended in tears. I will leave it alone for the moment, but it does seem that the text is low in some OS/browser combinations and we should address that.

If we're having the upload button in custom header/background as small, then we'll want to change theme and plugin install from upload as well to match.

I also think disabled should perhaps not have the pointer cursor, or an active state. Patch on #20855 is good for testing that.

IE 7 doesn't apply button height properly: 21598.ie7.png​.

Couple bug fixes in 21598.13.diff:

• Removed pointer cursor for disabled buttons
• Removed disabled :active, and :hover styles
• Added button-small to theme and plugin upload buttons
• Fixed search themes text box size to match button size
• Fixed button height in IE7

In [21944]: .button-large, .button-small, but .button.regular?

Replying to TobiasBg:

In [21944]: .button-large, .button-small, but .button.regular?

.regular just overrides a primary buttons padding to act more like a regular .button (it's a bit of a hack).

Changed .button 2px inset box-shadow to 1px in 21598.13b.diff

Replying to lessbloat:

.regular just overrides a primary buttons padding to act more like a regular .button (it's a bit of a hack).

Thanks for the explanation, but why is not named .button-regular for consistency? It just sets padding (ok, with an !important), just like .button-small and .button-large.

Has anyone thought of the "Move to Trash"? I think a button for that would look great too.

21598.14.diff​ refines the button styles to have crisper edges and retunes the gray button to be visible against both white and gray backgrounds.

It also remove the application of button-large styles to button-primary. While that should be a default in submit_button(), adding the large size to all primary buttons breaks the cascading nature of the various CSS button modifications. We should be aiming for stackable classes.

In [22099]:

Refine button styles, notably the gray buttons.

• Crisper edges, fewer outer shadows.
• Higher contrast borders on the gray buttons.
• Separates button-large from button-primary, and removes the regular override class.

props hugobaeta, helenyhou, lessbloat. see #21598.

Next steps:

• Refresh 21598.13.diff​. Keep the IE changes, cursor: default; on disabled buttons, and the changes to wp-admin.css.
• Audit core for usage of submit_button( $text, 'primary', $etc ); and update primary to primary large.
• Finally, since the buttons CSS in colors-fresh and colors-classic is identical (not to mention a substantial amount of CSS), I propose we move the button CSS to a section in wp-admin.css.

I really like the stackable classes approach!

However, IMHO, the linear background gradient on .button is now a little bit soft after [22099]: On a white background the gradient from #fefefe to #f4f4f4 will be hardly noticable for the average user with a non-calibrated monitor. And then the buttons just look like text with a border around them. Especially, if you view a .button next to a .button-primary, you can see the difference in the "3D effect".

Also, compare .button to the Quicktags toolbar buttons. Those have a higher gradient contrast and make the buttons more "3D-ish". Maybe we can come up with something between those two gradients?

Empty spam on the bottom row is missing it's tushie.

​http://cl.ly/image/070s0n0Q2b0e

Removing height: 1em; from #edit-slug-box means that #edit-slug-box no longer takes up space on post-new.php. That blank space is taken up by the permalink editor after an autosave. Without it, you end up with the editor getting bumped down. Adding it back; if there's a better solution, that's fine too. We need a solution.

Replying to Ipstenu:

Empty spam on the bottom row is missing it's tushie.

Ipstenu,

I can't seem to be able to replicate this. However, I did notice that the margin-top for that button was off. Does 21598-tushie.diff perhaps fix the tushie missing issue you mentioned?

Replying to nacin:

Removing height: 1em; from #edit-slug-box means that #edit-slug-box no longer takes up space on post-new.php. That blank space is taken up by the permalink editor after an autosave. Without it, you end up with the editor getting bumped down. Adding it back; if there's a better solution, that's fine too. We need a solution.

I'd say just add it back when the slug is visible. Something like:

.post-php #edit-slug-box { 
    height: 1.8em;
}

Which prevents having a huge gap on the new post page.

Replying to SergeyBiryukov:

IE 7 doesn't apply button height properly: 21598.ie7.png​.

Also reported in #22136.

Replying to SergeyBiryukov:

Replying to SergeyBiryukov:

IE 7 doesn't apply button height properly: 21598.ie7.png​.

Also reported in #22136.

I believe I fixed this in 21598.13b.diff, but it has yet to be committed. See http://core.trac.wordpress.org/ticket/21598#comment:75 @koopersmith added it to a next steps list.

Replying to Ipstenu:

Empty spam on the bottom row is missing it's tushie.

Could not reproduce in any of my browsers, which browser is that? Confirmed that 21598-tushie.diff​ fixes the margin though.

Replying to lessbloat:

I believe I fixed this in 21598.13b.diff, but it has yet to be committed.

21598.13b.diff​ fixes the button height, however the line height seems a bit off: 21598.ie7.2.png​.

Changing line-height: 12px to 15px in line 569 of ie.css appears to fix this (21598.ie7.3.png​) everywhere but the Publish button, which I guess needs more height: 21598.ie7.4.png​.

Related: #22034

Related: #22156

The sample permalink spacing issue has been broken out into #22184.

#22136 was marked as a duplicate.

In [22236]:

Consolidate buttons CSS into a single file.

Adds wp-includes/css/buttons.css to consolidate buttons files and make them available in a modular fashion. Buttons are included automatically with the colors styles, and can be included independently by running:

wp_enqueue_style('buttons');

fixes #22197, see #21598.

In [22237]:

Make <button> elements inherit font settings. fixes #22201, see #21598.

In [22239]:

Revise and combine button selectors.

• Simplifies button selectors. Maintains backwards compatibility for several classes and makes creating new button styles considerably easier.
• Adds buttons documentation.
• Raw input submit/reset/button types now use default browser styles (instead of half-styled borders that did not look like buttons).
• Moves basic button color standardization to the beginning of wp-admin.

see #21598, #22197.

In [22242]:

Add button groups. see #21598, #21390.

In [22245]:

Add a down arrow button. see #21598, #21390, #21813.

In [22247]:

Add attachment display settings to the media modal.

• Add a media view for button groups.
• Add button dropdown containers.
• Add a dropdown property to the button media model.

fixes #22206, #21814, see #21390, #21813, #21598.

The vertical misalignment of the "Log In" button in Firefox/Win and a little bit in Chrome/Win is caused by an !important (surprise!). How about we use .button-large on the login screen?

The login screen with 21598-15.patch applied in Firefox and Chrome on Win:

Added slightly bolder :focus styles back in 21598-16.patch. In my mind it's okay to have slightly bolder box-shadows for :focus, since users will only see them when tabbing.

Here's what it looks like:

Added in missing ticket:21598:21598-tushie.diff, as well as 1px margin-top from ticket:22034:22034-2.patch in 21598-17.patch.

In [22288]:

Buttons: slightly bolder :focus styles, make the "Log In" button '.button-large', props lessbloat, see #21598

In [22289]:

Fix the buttons in IE, make them better in IE7, remove the default padding in Firefox, make all .button <a> and <input> look the same, fixes #21598

The primary buttons are 2px smaller than the secondary buttons in FF (Mac):

On further inspection, the issues is between <input class="button"> & <a class="button"> not primary and secondary buttons.

21598-18.patch is my attempt get button heights to match up cross browser:

Having line-height plus height may look odd, but it's the only way I've been able to figure out how to get this right cross browser.

@lessbloat, yeah, was going to reopen it.

Seems Firefox renders buttons differently on Mac and Win :(

Also Firefox always overrides line-height in all <input> and <button>. This cannot be fixed. Also adds 3px left and right padding, thankfully this can be fixed in css.

Tweaked test plugin to show input.button and a.button

Turns out the top and bottom padding were causing most of the issues cross browser. 21598-19.patch seems to work pretty well for me cross browser.

21598-19.patch​ does something funky to the welcome panel button:

And doesn't look very good for some of the buttons (not necessarily all of them) in FF/OSX:

Install screens plus 'create configuration' & 'no db'

21598-20-install+errors.diff​ updates button styles on the install pages and the error page generated by _default_wp_die_handler()

Before:

• Create config (error) - ​http://cl.ly/image/2A1M3k1K3T3S
• Install 1 - ​http://cl.ly/image/1O1T2k0s0D3L
• Install 2 - ​http://cl.ly/image/2L3H3B0U3P3W
• No database (error) - ​http://cl.ly/image/0D3O433M2U2o

After:

• Create config (error) - ​http://cl.ly/image/3b0l1T0L0K0U
• Install 1 - ​http://cl.ly/image/320h313h450P
• Install 2 - ​http://cl.ly/image/0E1g1j2j263h
• No database (error) - ​http://cl.ly/image/1r311o1c223J

21598-20.2.diff​ uses wp_admin_css() in install.php

And ugh, here are the remaining Install screenshots:

Before:

• Install 3 - ​http://cl.ly/image/1J393E3R0a1C
• Install 4 - ​http://cl.ly/image/3M2v1C3M2p31
• Install 5 - ​http://cl.ly/image/2T1g0n0g0y2U

After:

• Install 3 - ​http://cl.ly/image/3V210a2t2u3m
• Install 4 - ​http://cl.ly/image/3i0d3x3G1M2l
• Install 5 - ​http://cl.ly/image/2R311D1J2A3f

I think those need to be bigger buttons / larger text, since it's what the screens currently have and makes sense to retain.

Replying to helenyhou:

I think those need to be bigger buttons / larger text, since it's what the screens currently have and makes sense to retain.

Bigger buttons and larger text are covered in 21598-20.3.diff​

Before/Afters:

+ repair.php

21598-20.4.diff​ adds updated styles to repair.php

Updated before/afters: ​http://cl.ly/image/073u0h361C2y

21598-21.diff includes:

• 21598-19.patch
• Fix for welcome screen button
• Fix for FF (OSX) buttons
• 21598-20.4.diff (with updated new button styles in wp-includes/functions.php)

@DrewAPicture pointed out that the button styles in function.php used 14px font. Updated in 21598-21b.diff.

Version of 21598-21b.diff without !important.

Also, it appears that for some reason the 'Install WordPress' button is shorter than the others with button-large applied, by maybe 2-ish pixels. It's on the first screen we see on install.php after the wp-config is generated.

Buttons in the "error" pages use printed styles coming from markup generated by _default_wp_die_handler() but are assigned classes like .button and/or .button-large in the file generating the error.

We need to locate all files that generate error pages with buttons and apply the .button-large class. 'Create a configuration file' in wp-load and 'Repair database' et al in repair.php are covered in 21598-21c.diff​.

Adversely, in setup-config.php and install.php we can rely on admin stylesheets.

Something to keep in mind is that until now all of the aforementioned buttons had a font-size 14px which differs from the updated styles at 12px. Using a body class was ​suggested in IRC and it would make it possible to further condense some styles without having to resort to thinks like !important.

I forgot to mention that I think we should continue to treat _default_wp_die_handler() as a unique case and set whatever button styles we need to in there, separate from the body class discussion concerning setup-config.php and install.php.

Replying to DrewAPicture:

Also, it appears that for some reason the 'Install WordPress' button is shorter than the others with button-large applied, by maybe 2-ish pixels.

21598-22.diff should fix this.

Tried to fix FF/Win buttons as much as possible without affecting other browsers in: 21598-23.diff.

In [22314]:

Buttons:

• Update the install/initial configuration/repair screens buttons, props DrewAPicture
• Fix the welcome screen buttons and fine-tune the buttons css, props lessbloat

fixes #21598

As far as I see all buttons look good in all browsers. If specific places still need fixing, lets handle them in new tickets.

In 22327:

Buttons: make install.css depend on buttons.css (so button styles are always loaded), see #21598

In 22424:

Larger buttons for the DB upgrade screens. see #21598.

#22490

In 22707:

Buttons: Remove unused button arrows and dropdowns. see #21598, #21390.

In 23044:

Use correct button class hierarchy to ensure the 'Update' button is button-large. see #21598.