WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#34333 closed defect (bug) (fixed)

Customizer: aggregate similar CSS rules

Reported by: afercia Owned by: afercia
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords: has-patch has-screenshots
Focuses: ui Cc:

Description

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.

Attachments (5)

34333.patch (20.4 KB) - added by afercia 4 years ago.
34333.2.patch (20.3 KB) - added by afercia 4 years ago.
34333.missing-broken-nav-add-widgets-mobile.PNG (33.8 KB) - added by celloexpressions 4 years ago.
34333.missing-nav-add-menu-items-mobile.PNG (18.4 KB) - added by celloexpressions 4 years ago.
34333.3.patch (21.5 KB) - added by afercia 4 years ago.

Download all attachments as: .zip

Change History (17)

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.


4 years ago

#2 @afercia
4 years ago

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:

https://cldup.com/TpC4v1wOwI.png

Working on a patch, mostly experimental for now :)

@afercia
4 years ago

#3 @afercia
4 years ago

  • Keywords has-patch added

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:

https://cldup.com/nP_iy4orGf.png

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.

#4 @afercia
4 years ago

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

@afercia
4 years ago

#5 @afercia
4 years ago

  • Keywords has-screenshots added
  • Milestone changed from Awaiting Review to 4.5
  • Owner set to afercia
  • Status changed from new to assigned

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

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.


4 years ago

#7 @celloexpressions
4 years ago

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
4 years ago

#8 @afercia
4 years ago

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

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.


4 years ago

#10 @afercia
4 years ago

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.

#11 @afercia
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 36291:

Customizer: Aggregate similar CSS rules.

Fixes #34333.

This ticket was mentioned in Slack in #core-customize by helen. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.