Customizer: aggregate similar CSS rules

[afercia]

There are so many CSS rules in customize-widgets.css and customize-nav-menus.css that are duplicate (just different selectors) and could be aggregated in customize-controls.css.
A first bunch is handled in #33327.

Some examples:

in customize-widgets.css:

body.adding-widget .add-new-widget,
body.adding-widget .add-new-widget:hover {
	background: #eee;
	border-color: #999;
	color: #32373c;
	-webkit-box-shadow: inset 0 2px 5px -3px rgba(0, 0, 0, 0.5);
	box-shadow: inset 0 2px 5px -3px rgba(0, 0, 0, 0.5);
}
body.adding-widget .add-new-widget:before {
	-webkit-transform: rotate(45deg);
	-ms-transform: rotate(45deg);
	transform: rotate(45deg);
}

in customize-nav-menus.css

.adding-menu-items .add-new-menu-item,
.adding-menu-items .add-new-menu-item:hover,
.add-menu-toggle.open,
.add-menu-toggle.open:hover {
	background: #eee;
	border-color: #929793;
	color: #32373c;
	-webkit-box-shadow: inset 0 2px 5px -3px rgba(0, 0, 0, 0.5);
	box-shadow: inset 0 2px 5px -3px rgba(0, 0, 0, 0.5);
}

.adding-menu-items .add-new-menu-item:before,
#accordion-section-add_menu .add-new-menu-item.open:before {
	-webkit-transform: rotate(45deg);
	-ms-transform: rotate(45deg);
	transform: rotate(45deg);
}

etc. In the example above there's just one small difference in a border-color property that should be paired I guess. They're typically rules related to the available-widgets and available-menu-items panels that basically look the same. Not to mention the selectors could be unified too.
I'd propose to start reviewing them and get some sanity.

[afercia]

One of the drawbacks of having duplicate CSS rules in different files for UI elements that should look similar, is that they inevitably tend to lose consistency. For example, see the search inputs in the screenshot below:

Working on a patch, mostly experimental for now :)

[afercia]

First pass, aggregates and moves many duplicate rules to customize-controls.css. About the search fields, they can be made a bit smaller of course so they would be aligned with the main panel on the left, that's a design decision would need some feedback about. At least, they look the same now:

If you get a chance to have a look at the patch, you will notice all the similar UI controls that should probably be unified too, meaning using the same markup and same CSS selectors.

[afercia]

Related (for the search input fields): #34061.

[afercia]

Refreshed patch. I'd suggest to do it now since we're at the beginning of a new release cycle :)

[celloexpressions]

I found two issues with 34333.2.patch​ (screenshots above):

• Missing nav for add menu items panel (the back arrow & section heading) on mobile
• Missing/broken nav for add widgets panel on mobile

I wonder if we should merge these files entirely? Either widgets and menus together, or both into customize-controls.css. It could also be nice to generalize some of the selectors and other code around these so that plugins can implement similar UI more easily. @helen may have opinions there too.

[afercia]

@celloexpressions thanks. Yep, the previous patch missed a comma after a selector and some rules currently have a higher specificity just because they're loaded after the ones in customize-controls.css so I've moved some more rules from customize-widgets.css and customize-nav-menus.css to customize-controls.css.
Should work better now. Hopefully :)

About further optimization, merging and generalizing code I'm all for improvements. After all this patch proves that many things can be standardized in components (for example abstracting selectors). Also, this helps in discovering small inconsistencies and makes them easy to fix.

[afercia]

Agreed with @celloexpressions to commit the last patch, it's early enough in the release cycle to fix things that may break. If discrepancies in the rules merged for similar components will pop up, please feel free to reopen the ticket in order to make a complete list of those for reference.

[afercia]

In 36291:

Customizer: Aggregate similar CSS rules.

Fixes #34333.