Themes.css - Add Custom Props#14
Themes.css - Add Custom Props#14fwazeter wants to merge 40 commits intoryelle:try/custom-propertiesryelle/wordpress-develop:try/custom-propertiesfrom
Conversation
Replaced static color values in wp-admin/css/themes.css with CSS custom properties. If no existing custom property in wp-includes/css/custom-properties , a new custom property was created.
Fixed missing # in hex color (line 159, custom-properties) & switched new custom prop from general --wp-admin to --wp-admin--themes (line 54 to line 145 custom properties), line 175 & 180 themes.css
Converting static colors to custom props in /wp-admin/css/customize-nav-menus.css . We're getting a lot of overlap of common colors for elements, experimented with putting colors explicitly from WP color palette as base props to be used by more specific props.
Moved custom props to themes.css to follow ryelle's convention for now, since there are a ton of them here.
Added customize-preview to this PR because it's a small file. Even though it's small with only ~11 color values, it adds a lot of different custom props.
Went back and refined with a more component based approach. Put themes.css specific custom props at top of themes.css following --wp-admin--admin-menu precedent.
Changed naming conventions to be more based on the components most used throughout the themes.css file.
Fixing git - files didn't get reconciled in the way expected. Manual restored non-edited files from this branch.
Weird spacing change not reflecting in local code editor that is not an intended change.
Spacing tab added on four lines that was never intented.
Corrected minor spacing.
|
Working On: Moving custom props into custom-properties, double checking odd rgba() occurrence bug noted earlier. Removing fallback colors. |
-Moved custom props from themes.css to custom-properties.css , removed all fallback colors, converted box-shadows to contain whole value (rather than just color), set properties for background-color: none / transparent, etc.
|
Commenting here for easier readability: last commit removed all fallback colors, moved the custom props from themes.css to custom-properties, and made some tweaks, such as including the whole value of a box-shadow in the custom prop rather than just color, in reference to commentary on other PR's about box-shadows. Original old RGBA fallbacks were removed as well. Additionally, set custom props for some background / border-color that had none or transparent so that they are editable since logic would dictate that although the default is none or transparent, it's something someone might want to manipulate. Left out border: none; since that might imply not just color. |
# Conflicts: # src/wp-admin/css/themes.css
| /* black grayscale rgba # = 0, 0, 0, # */ | ||
| --wp-admin--themes--black-0: rgba(0, 0, 0, 0); | ||
| --wp-admin--themes--black-05: rgba(0, 0, 0, 0.05); | ||
| --wp-admin--themes--black-2: rgba(0, 0, 0, 0.2); | ||
| --wp-admin--themes--black-5: rgba(0, 0, 0, 0.5); | ||
| --wp-admin--themes--black-6: rgba(0, 0, 0, 0.6); | ||
| --wp-admin--themes--black-7: rgba(0, 0, 0, 0.7); | ||
|
|
||
| /* white grayscale rgba */ | ||
| --wp-admin--themes--white-65: rgba(255, 255, 255, 0.65); | ||
| --wp-admin--themes--white-7: rgba(246, 247, 247, 0.7); | ||
| --wp-admin--themes--white-9: rgba(240, 240, 241, 0.9); | ||
|
|
||
| /* unique rgba colors */ | ||
| --wp-admin--themes--alpha-dark: rgba(44, 51, 56, 0.7); | ||
| --wp-admin--themes--alpha-gray: rgba(140, 143, 148, 0.1); | ||
| --wp-admin--themes--blue: rgba(34, 113, 177, 0.8); | ||
| --wp-admin--themes--light-blue: rgba(79, 148, 212, 0.8); |
There was a problem hiding this comment.
For the most part we've been avoiding using the color name in the properties. Rather than creating these intermediate properties and using them later, could you use them directly below?
| --wp-admin--radio--color--focus: #1d2327; | ||
| --wp-admin--radio--border--checked: #8c8f94; | ||
| --wp-admin--radio--border--focus: #4f94d4; | ||
| --wp-admin--radio--box-shadow: var(--wp-admin--themes--blue); |
There was a problem hiding this comment.
These aren't radio controls, it's for the buttons here:
I think these properties should be either merged with button properties (if they exist), or change the name to use button for the location.
There was a problem hiding this comment.
I agree - leaving them named as radio in either case would be confusing, case in point being that I couldn't locate that control you brought up and thought they were a hidden / optional radio button based on the property name.
| --wp-admin--themes--icon--shadow--hover: #4f94d4; | ||
| --wp-admin--themes--icon--background--disabled: var(--wp-admin--surface--border); | ||
|
|
||
| /* Theme Card */ |
There was a problem hiding this comment.
Can these card properties be moved to a more generic card set? Or maybe it could use the surface properties?
There was a problem hiding this comment.
Which would you prefer as a best case? More generic card set or just inherit the surface properties directly? I tried to break up the file into components as much as possible to make it slightly easier to dig through, so I'd lean more towards generic card set personally.
Replaced static color values in wp-admin/css/themes.css with CSS custom properties. If no existing custom property in wp-includes/css/custom-properties , a new custom property was created. On colors using rgba() SOME do not render associated custom property unless a fallback is explicitly stated. Lines 60, 84, 163, 295, 368 and 570 are confirmed examples where not setting an explicit fallback color resulted in no color rendering.
Trac ticket: https://core.trac.wordpress.org/ticket/49930