Global Styles: Try color and typography presets in Site View #59594
Conversation
scruffian
added
[Type] Enhancement
|
Size Change: -39 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
Nice! Incredibly fast work. Here's a screenshot of the site editor > styles section: First question is whether each of these categories should be their own drilldown, simply due to the height of the page as is. Especially with TT4 the variations take up a lot of space. So instead of Site Editor > Styles having all three, you'd have Site Editor > Styles > Variations|Fonts|Colors. Happy to try one and then move to the other based on a little time in the plugin. A few small things. This heading should use the same heading style as inside the style inspector:
ie. this one:
All the cards should have $radius-block-ui (2px) rounded corners. These are sharp:
There may actually be some componentry you can copy from here: I believe @richtabor or @SaxonF had some mockups for the color presets as well, though, I don't recall the latest feedback on that. Something went wrong with the font presets, though, they all have the same style. That's both in the site view sidebar, and also in the global styles inspector: In trunk, in the style inspector looks right: Nice work! |
Thanks. It is actually using the same components but they look different in that context for some reason! Wr probably need to move some CSS around... |
scruffian
force-pushed
the
try/presets-in-site-view
branch
from
cf067df
to
f65aa46
Compare
|
Thanks for the feedback @jasmussen, I have updated this PR as suggested and also the screenshots in the description. The only thing I haven't done is to make the colors and typography sections part of a drill down, since you weren't sure if that was necessary and it does make things more complex. Happy to try it if you think we need to... |
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @unprintedch. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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. |
|
Nice, this is getting really close. Here's a GIF of me clicking in the site editor styles sidebar:
There's a discrepancy with the borders here:
The colors have an outer ring, the font presets do not. I can't tell if both or none of them should have that outer border in the dark material or not, probably if there's a unified "preset" component that gets used that'll be the answer. But CC: @jameskoster @SaxonF for any input. There's still the open question around whether these three should be additional drilldowns, since the many TT4 variations push these two things down. We can go either way in the first merge, then revisit. |
|
Thanks! They styles don't have a border, so I'm guessing that is preferable, but I'll wait to see what @jameskoster anf @SaxonF think |
|
I'd lean in the same direction, though there's also this one to consider:
|
|
This comment is an observation about presets in general – it's not specific to this PR, but it's something that feels particularly prevalent here. It may just be me, so I'm keen to hear thoughts of others. I worry the interplay between the selected states is going to confuse users. Not only because of the styling discrepancy Joen mentioned (easily fixed), but in general it just feels odd to: Select a style variation, then select a typography preset, then find that my chosen style variation is no longer selected. Technically I understand why that happens, but it feels a bit uncanny to use imo. I think there are ways to fix that (tweaking the iA, or removing the 'selected' styles), but I'll wait and see if anyone else feels the same before diving in. Regarding the aforementioned styling discrepancy, I find the treatment of the Style Variations and Typography tiles to work best. IE the white ring on the selected tile: 
That seems most closely aligned with the tiles in the Styles panel here: 
|
|
Hello. |
|
There's a lot of discussion about the hover / focus / selected states in #59508 IMO we should merge this as is and iterate there... |
| <h3 className="edit-site-global-styles-variation-title"> | ||
| { __( 'Typography' ) } | ||
| </h3> | ||
| <TypographyVariations /> |
There was a problem hiding this comment.
I think we should check if variations exist before showing the headings.
Here's emptytheme (no typography styles):
There was a problem hiding this comment.
Thanks, I updated the PR, though when I tested with emptytheme I don't see the above as I don't have any style variations :hmm:
There was a problem hiding this comment.
I ended up including some of the changes from #59717 so that this works as expected
There was a problem hiding this comment.
Ah, I see now. It's failing the uniqueTypographyVariations test.
Empty theme has the following "typography" variation:
{
"settings": {},
"styles": {
"elements": {
"h2": {}
},
"blocks": {
"core/post-title": {
"typography": {
"fontWeight": "700"
}
}
}
},
"title": "variation"
}
But it doesn't have any fontFamilies, so it fails.
The same thing might happen for colors if there are no color settings:
I've pushed a change to check for this in a30eb5b. Seems to work okay, feel free to revert.
|
I'd tend to agree. @unprintedch your instincts are correct, there's a big opportunity for the Styles section of the site editor. The work in this PR improves the situation, but importantly does not preclude explorations such as those you point to from still happening in the future. One of the philosophies that's being refined and discussed, notably in #59745, is the role of the site view (dark background, preview on the right) and the edit view (fullscreen editor), in terms of which options you edit where. A tentative delineation is that you only ever edit high level, site-wide options in the site view, and that you need to enter edit view for more granualar stuff. So font sets, color sets would be high level, individual fonts, individual colors, would be granular, low level. This is far from a solidified rule, and I can definitely see reason to changing the heading font across your site in the site view, without having to pick only a set, so it's still fertile ground to explore. But a reason, still, to move forward with this is that should we decide to move more controls into the site view styles panel, it would require componentry (inputs, toggles, checkboxes, etc) to work on a dark background, that support doesn't yet exist, and would be a prerequisite for a lot of the block editing tools to function there. |
| @@ -69,6 +75,18 @@ function SidebarNavigationScreenGlobalStylesContent() { | |||
| }; | |||
| }, [] ); | |||
|
|
|||
| const colorVariations = useCurrentMergeThemeStyleVariationsWithUserConfig( { | |||
| property: 'color', | |||
| filter: ( variation ) => !! variation?.settings?.color, | |||
There was a problem hiding this comment.
To make things consistent, maybe the same should be applied to the global styles side bar:
diff --git a/packages/edit-site/src/components/global-styles/variations/variations-color.js b/packages/edit-site/src/components/global-styles/variations/variations-color.js
index 04b8c47696..8377029148 100644
--- a/packages/edit-site/src/components/global-styles/variations/variations-color.js
+++ b/packages/edit-site/src/components/global-styles/variations/variations-color.js
@@ -16,6 +16,7 @@ import { useCurrentMergeThemeStyleVariationsWithUserConfig } from '../../../hook
export default function ColorVariations() {
const colorVariations = useCurrentMergeThemeStyleVariationsWithUserConfig( {
property: 'color',
+ filter: ( variation ) => !! variation?.settings?.color,
} );
if ( ! colorVariations?.length ) {
diff --git a/packages/edit-site/src/components/global-styles/variations/variations-typography.js b/packages/edit-site/src/components/global-styles/variations/variations-typography.js
index c59e9e872c..5526d06d13 100644
--- a/packages/edit-site/src/components/global-styles/variations/variations-typography.js
+++ b/packages/edit-site/src/components/global-styles/variations/variations-typography.js
@@ -26,6 +26,8 @@ export default function TypographyVariations() {
const typographyVariations =
useCurrentMergeThemeStyleVariationsWithUserConfig( {
property: 'typography',
+ filter: ( variation ) =>
+ !! variation?.settings?.typography?.fontFamilies,
} );
const { base } = useContext( GlobalStylesContext );Or, maybe create an optional headingText/headingElement prop to these components so the heading renders with the component?
There was a problem hiding this comment.
I'm not sure we need to do this. There could be instances where the style variation doesn't introduce any new settings, but the style variation itself still changes the look of the site - for example look at how TT3 deal with typography - the setting all live in the parent variation, but each child uses them differently.
There was a problem hiding this comment.
Fair point. Then we could revert a30eb5b. Still, it would be good to have a way to show variations without settings to avoid a blank area. 🤔
Maybe a fallback preview icon or something?
scruffian
force-pushed
the
try/presets-in-site-view
branch
from
a30eb5b
to
cdf5af9
Compare
Good!
To be clear about wording:
How can i help? |
I'd suggest add a bit more nuance:
The thing is, you'll still be able to make some local changes even in the site view, such as renaming a navigaiton block or a pattern, as well as bulk editing two or three pages rather than all pages. And in the fullscreen editor/edit view, you'll still have synced patterns or template parts where you make global changes.
The overwhelming amount of work on this happens right here in GH, on the main tracking issues, or in any of the "needs design" or "needs design feedback" labels. There's also a label for tracking issues. Thank you for contributing! |
|
I just started to read this: |
…ss#59594) * Global Styles: Try presets in Site View * get typography working in mobile * add border radius * tidy up styles * only output the preset headers if there are presets * Filtering for settings before showing titles. * Remove the filters that might remove variations that are valid * move the unique typography variations to a hook --------- Co-authored-by: ramon <ramonjd@gmail.com> Co-authored-by: scruffian <scruffian@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org> Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
What?
This adds color and typography presets to the Site View of the Site Editor.
Why?
These are top level settings that should be easy to change
How?
Just adding the components to the top level of Styles in Site View.
Testing Instructions
Screenshots or screencast
Also test the mobile view:
