Add color and typography presets to Global Styles #56622
Conversation
|
Size Change: +1.64 kB (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in b63b417. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/8007146955
|
scruffian
force-pushed
the
add/colors-and-typography
branch
from
e00a931
to
a39c4c8
Compare
scruffian
changed the title
|
|
||
| const { GlobalStylesContext } = unlock( blockEditorPrivateApis ); | ||
|
|
||
| const getFontFamilies = ( themeJson ) => { |
There was a problem hiding this comment.
There's a lot of duplicate code in this function that could be extracted to a function.
| }; | ||
|
|
||
| export default function ScreenTypographyTypesets() { | ||
| const variations = useSelect( ( select ) => { |
| const { base, user } = useContext( GlobalStylesContext ); | ||
|
|
||
| const typographyVariations = | ||
| variations && getVariationsByProperty( user, variations, 'typography' ); |
| } ); | ||
| }; | ||
|
|
||
| const selectOnEnter = ( event ) => { |
There was a problem hiding this comment.
Quite a lot of this is just copy/paste from the Variation component.
|
|
||
| export default function ColorVariations() { | ||
| const { user } = useContext( GlobalStylesContext ); | ||
| const variations = useSelect( ( select ) => { |
| ).__experimentalGetCurrentThemeGlobalStylesVariations(); | ||
| }, [] ); | ||
| const colorVariations = | ||
| variations && getVariationsByProperty( user, variations, 'color' ); // should also get filter? |
There was a problem hiding this comment.
Add the default variation
| } | ||
|
|
||
| export default function TypographyVariations() { | ||
| const variations = useSelect( ( select ) => { |
|
|
||
| const { base, user } = useContext( GlobalStylesContext ); | ||
|
|
||
| const typographyVariations = |
There was a problem hiding this comment.
Add the default variation
scruffian
force-pushed
the
add/colors-and-typography
branch
from
c0616c6
to
98a2dad
Compare
|
This doesn't seem to be working for variations with more than 2 fonts. I added this variation to TT4 that uses a third font for buttons and it didn't show under typesets: |
|
@scruffian @MaggieCabrera If you need help moving this one forward, I'm happy to rebase and test, and tinker with it. I'll take it for a spin next week. If there are any outstanding items or gotchas, let me know. Thank you! |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
|
||
| typographyVariations?.forEach( ( variation ) => { | ||
| const [ bodyFontFamilyName, headingFontFamilyName ] = | ||
| getFontFamilyNames( mergeBaseAndUserConfigs( base, variation ) ); |
There was a problem hiding this comment.
Maybe we need to come up with a way to name style variations with no font-families, e.g., cases where variations have typography styles only like this:
{
"settings": {},
"styles": {
"typography": {
"letterSpacing": "10px"
},
"blocks": {
"core/post-title": {
"typography": {
"fontWeight": "700"
},
"color": {
"background": "red"
}
}
}
}
}Possibly ${variationTitle} - typeset or, when variation.title doesn't exist in the theme.json ${variationFileName} - typeset?
There was a problem hiding this comment.
Maybe we need to come up with a way to name style variations with no font-families, e.g., cases where variations have typography styles only like this:
To simplify this, I propose we lean in on a "Font book" type approach, where the heading and body fonts are used in for A and a respectively, like this:
We already do that for styles:
There was a problem hiding this comment.
I updated the PR to use these designs:
There was a problem hiding this comment.
Yeah, this looks good. We can expand later on listing exactly what aspects are being modified, which is a general concern of variations.
ramonjd
force-pushed
the
add/colors-and-typography
branch
from
98a2dad
to
cde7009
Compare
| <VStack spacing={ 3 }> | ||
| <FontFamilies /> | ||
| <ItemGroup isBordered> | ||
| <NavigationButtonAsItem |
There was a problem hiding this comment.
Wondering if the all the work grabbing the typography settings from the variations could be done in a memoized hook, or store selector.
That way we could do a length check on the array here and skip rendering the button.
packages/edit-site/src/components/global-styles/variations-color.js
Outdated
Show resolved
Hide resolved
|
I'm thinking we could split this PR. First we could work on the hook to grab theme style variation styles by property: This could more quickly unblock the work @apeatling is doing. This would mean we'd work on the UI/site editor components etc in another PR. It would further help to split up the PR as there are some aspects of how and what we show in the editor that I think need resolved. For instance how should the site editor, if at all, present theme style variations that have no presets? Related comments: https://github.com/WordPress/gutenberg/pull/56622/files#r1477640893 and https://github.com/WordPress/gutenberg/pull/56622/files#r1477627148 Maybe we shouldn't focus on presets so much and rather present them as subsets of variations (typography and so on) So if a theme hasn't got a any heading/body font families defined, what do we do? In short, in my estimation, the discussions about UX and UI will take longer than getting some working utils ready. What do folks think? |
I think they're one and the same. Having a full theme style variation is a nice way to switch up your whole site's look, but splitting out the colors and typesets within each is nice so you're not having to go all-or-nothing.
I wouldn't expect there to be a preset for it then. |
|
Thanks for the feedback @richtabor! This gives us plenty to go off, thanks! |
I agree with this. There's a whole lot of crazy javascript manipulations happening that need to be tidied up and tested thoroughly. We can get a lot of this in place before making the UX decisions. Thanks for working on this. |
packages/edit-site/src/components/global-styles/font-library-modal/utils/preview-styles.js
Show resolved
Hide resolved
Pulling out the utils from #56622 so we test separately
… same as the typography preview Reducing the vheight of the color panel to match typography Some light refactoring
…ation. We do this in order that any user config changes with the same property don't "bleed" into variations. The variation should be "pure". For example, if the user has defined a background color, but the variation has not, we shouldn't merge the two and allow the user background color to persist. Rather the variation's color properties should take the place of all color properties.
scruffian
force-pushed
the
add/colors-and-typography
branch
from
aa20b91
to
b23d64c
Compare
… colors This is so that theme colors that are the same value as the background are more noticeable
There was a problem hiding this comment.
This is working pretty well, thanks a lot!
I'm happy if @mtias and @richtabor are happy. 😄
I've tested in about 12 block themes and didn't notice any huge blockers.
For follow ups
It would be good to have some fallbacks for highlightedColors in case the background/text styles are the same as the available palette colors. See comment: #56622 (comment)
From this comment: Might also be a good janitorial follow up to move variation components into components/global-styles/variations and then all the related CSS as well
My feeling is that we should probably refactor the StylePreview component into smaller pieces that can be reused, so that all three previews share the same code, but this will take a bit of unpicking...
Agree. This would be a good refactor follow up.
| */ | ||
| const ratio = ratioState ? ratioState : fallbackRatio; | ||
|
|
||
| const { highlightedColors } = useStylesPreviewColors(); |
There was a problem hiding this comment.
While testing I noticed an issue with some themes that had only 2 palette colors, e.g., Freddie.
If those colors match heading or background colors, they're being filtered out:
gutenberg/packages/edit-site/src/components/global-styles/hooks.js
Lines 68 to 71 in f7b735e
The result is that, although there's a variation, the colors are empty:
CanvasLoader already gets around it this way:
gutenberg/packages/edit-site/src/components/canvas-loader/index.js
Lines 19 to 23 in f7b735e
Not sure what's appropriate in <StylesPreviewColors />
Maybe something like:
const { paletteColors, highlightedColors } = useStylesPreviewColors();
const previewColors = highlightedColors.length
? highlightedColors
: paletteColors.slice( 0, 2 );There was a problem hiding this comment.
Update: this is already an "feature" of trunk, in that style variation previews won't show them either.
I think it just looks strange in the preset previews. Maybe good for an immediate follow up.
To replicate the above issue, here's a style variation example. The palette colors are the same as the background and text colors so the variation will show nothing.
{
"version": 2,
"settings": {
"color": {
"palette": [
{
"color": "#000000",
"name": "Base",
"slug": "base"
},
{
"color": "#ffffff",
"name": "Contrast",
"slug": "contrast"
}
]
}
},
"styles": {
"color": {
"text": "#000000",
"background": "var(--wp--preset--color--contrast)"
}
}
}
| key={ slug } | ||
| style={ { | ||
| boxShadow: | ||
| 'inset 0 0 0 1px #0003', |
There was a problem hiding this comment.
I added this to ensure the colors have a border like the ColorIndicator component.
In some themes, the background color matches the highlights, or are close in contrast:
Before
After
There was a problem hiding this comment.
I added this to ensure the colors have a border like the ColorIndicator component.
I don't think this is necessary, as I want to update these colors to be more representative of the style by using the text and button colors for the indicators. I will open another issue on that (to do as a follow-up).
I agree, hierarchy wise they're a bit in the mix—rather than appropriately placed. I think this could work for this initial effort, then we can revisit secondary affordances for when there are more than 6 (perhaps a "View more/all" and a flyout, like the Colors panel):
|
|
Design updated: 
|
|
I'm going to bring this in, but just noting the followups here:
|
|
Sorry I did the merge and forgot to add the props to it again :( |
Follow up issue here: #59444 |
|
Good stuff! The best part of this effort is that all existing block themes will inherit this without having to do a thing. Anyone running a block theme can use any combination of colors or fonts, from any of their theme variations. Very nice. |
|
Hi 👋 , I'm sorry to be late to this conversation. I think the typography presets are not working as users would expect. Its behavior could feel unpredictable. I submitted an issue around this: #59574 |
This should have been part of #56622
What?
A popular feature in classic themes was to allow users to change the color palette and font families of their theme, usually the customizer. This is already possible in Global Styles, but the UI to do so is tricky to use - it takes a lot of clicks and a deep understanding of how Global Styles works. This PR abstracts that complexity away for users so they can change colors and typography details easily without knowing how Global Styles works.
These color and typography settings are extracted from the style variations, and exposed in the Global Styles UI.
Why?
This makes it possible to mix and match color and typography settings from different style variations. In the future this will also allow theme developers to offer a much wider range of color and typography variations and potentially even mix and match these variations between themes.
How?
Testing Instructions
Screenshots or screencast
There's also a demo video here: https://ben.blog/2023/12/07/global-styles-add-color-and-typography-presets/
Todo
Questions
Notes
One of the powerful things about the approach taken here is that it will work for existing themes - it doesn't require theme developers to add special settings to their themes.