Add a client-side font face resolver in the editor #65019
Conversation
matiasbenedetto
added
[Type] Enhancement
|
Size Change: +481 B (+0.03%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
|
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. |
packages/block-editor/src/components/editor-fonts-resolver/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/editor-fonts-resolver/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/editor-fonts-resolver/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/editor-fonts-resolver/utils.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/editor-fonts-resolver/utils.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/editor-fonts-resolver/utils.js
Outdated
Show resolved
Hide resolved
matiasbenedetto
requested review from
justintadlock,
carolinan and
richtabor
Co-authored-by: Sarah Norris <[email protected]>
| @@ -43,6 +44,7 @@ export function ExperimentalBlockCanvas( { | |||
| __unstableContentRef={ localRef } | |||
| style={ { height, display: 'flex' } } | |||
| > | |||
| <EditorFontsResolver /> | |||
There was a problem hiding this comment.
@youknowriad or @ellatrix since you've edited this file before, could you please sense-check how the fonts resolver is being added here?
|
This seems to work well in the editor content area and loads up everything as expected. The two areas where I'm still seeing fallback fonts from the stack are under the Typesets panel:
And in the Styles sidebar (both the theme and typography style variation sections):
Basically, what the user sees as options is not matching what they're getting in the editor content area. |
| }, [] ); | ||
|
|
||
| // Get the fonts from merged theme.json settings.fontFamilies. | ||
| const [ fontFamilies = [] ] = useGlobalSetting( 'typography.fontFamilies' ); |
There was a problem hiding this comment.
I know it's hard to figure that out on your own but If I'm not wrong useGlobalSetting doesn't work consistently in all editors. In fact, we should probably avoid using it in the "block-editor" package entirely because it relies on the presence of a provider that may or may not exist (it doesn't exist in the post editor for instance).
@aaronrobertshaw added a recently a new block editor setting that allows us to access global styles in all editors if I'm not wrong and we should probably be using that.
There was a problem hiding this comment.
Thanks for the ping 👍
a new block editor setting that allows us to access global styles in all editors
This was specifically related to the styles data from Global Styles as the settings values were already included within the block editor settings.
The Global Styles settings and styles weren't merged as there wasn't consensus on what the shape of those settings should be while maintaining BC. That led to using a symbol as a private key for the Global Styles style data.
Here's the PR adding the style data to the block editor settings: #61556.
Without looking into the code I'm not sure whether the Global Styles settings under __experimentalFeatures in the editor settings are kept in sync with unsaved Global Styles changes in the site editor. It could be possible that aspect needs addressing or perhaps in the short term this could fallback to the editor settings if the Global Styles context isn't available (in post editor).
There was a problem hiding this comment.
Good point, I mistakenly thought this is about the styles.
This PR reminds of the "styles" prop that we pass to the block editor to render the current theme styles. I could suggest a new "type" within the same "styles" prop to load fonts (like we do for svg for instance) but first. I would like to understand more.
What fonts are we trying to resolve here. I'm guessing the fonts that are used in the theme styles right? In which case, I feel like "resolving them" or "rendering them" should be done in the EditorStyles component. It's a component that is already used to "resolve or render" SVGs and CSS, it's already rendered in both iframe and non-iframe, so I'm starting to think that it's probably the right place for this change? (Introduce a new "type" of style and render it within that component)
Please correct me if my argumentation or abstraction seem too far off
There was a problem hiding this comment.
I'm not sure how to access global styles settings in a component like EditorStyles without using useGlobalSetting. For this particular implementation I'm interested in getting the 'client side latest version' of settings.typography.fontFamilies.
as the settings values were already included within the block editor settings
@aaronrobertshaw could you show me how is this done? I haven't found how to access the fontFamilies path mentioned before.
What fonts are we trying to resolve here. I'm guessing the fonts that are used in the theme styles right?
Yes. This PR was motivated by that, but implementing this would make us able to remove the manual loading of fonts when a font is installed using the font library, too, so we could simplify a little bit that code.
I feel like "resolving them" or "rendering them" should be done in the EditorStyles component.
@youknowriad I'm not sure about that, EditorStyles gets styles and not settings. At least, as it is today, that component is not getting the data needed to implement the desired functionality.
There was a problem hiding this comment.
I'm not sure about that, EditorStyles gets styles and not settings. At least, as it is today, that component is not getting the data needed to implement the desired functionality.
EditorStyles renders the CSS variables for the color presets for instance, renders the SVG filters used by Duotone. Isn't it the same for fonts here? We're resolving the fonts that are used in the CSS.
It is possible that I'm misunderstanding the issue that this PR solves though and if it's the case please clarify? I'm assuming that resolving the fonts is done in the frontend somehow right? How is it done today?
I'm not sure how to access global styles settings in a component like EditorStyles without using useGlobalSetting. For this particular implementation I'm interested in getting the 'client side latest version' of settings.typography.fontFamilies.
The styles prop received by the EditorStyles component can contain things like that
const styles = [
{
css: `some css`,
},
{
__unstableType: 'svgs'
assets: `some sig element`
},
{
__unstableType: 'presets'
assets: `css with CSS variables generated from the presets`
},
];This represents all what's necessary for the "styles" to be rendered properly and to work properly.
Would it be out of the question to consider "fonts" at the same level as these and just add
{
__unstableType: 'fonts'
fonts: `whatever is needed to resolve the fonts`
},
Again, it's possible that I'm wrong
There was a problem hiding this comment.
Btw, right now that "styles" prop come from the block editor settings array that is passed from the backend to the frontend during the initialization of the editor. So custom CSS files are resolved there for instance and added to that array of styles
In the site editor, since we have the ability to update global styles, that "styles" setting (the one that comes from backend to server) is also updated on the fly as we make changes to the global styles Here
There was a problem hiding this comment.
could you show me how is this done? I haven't found how to access the fontFamilies path mentioned before.
In the block-editor store, under settings.__experimentalFeatures.typography.fontFamilies, you should find the data you're chasing in the post editor.
One example of accessing theme.json settings via the block editor store can be found in the layout block support. Another example (that might change soon) is the block style variations block support which prefers the GlobalStyleContext data, if available, falling back to the block editor store's data.
Hope that helps a little 🤞
There was a problem hiding this comment.
Thanks for the insights.
In this commit I removed the use useGlobalSetting and replaced it by the use data from block-editor store and move the call to the font faces resolved inside the EditorStyles component: c6a32f9
| } | ||
|
|
||
| if ( addTo === 'iframe' || addTo === 'all' ) { | ||
| const iframeDocument = document.querySelector( |
There was a problem hiding this comment.
Did we consider moving this logic elsewhere. I feel we should avoid using DOM APIs like that, it's really not clear which "editor-canvas" this is targeting. I can see a world where there are two editors iframes on the same page.
If fonts need to be loaded in the iframe, can we instead move the logic to load fonts into the Iframe component instead?
We can probably use a memoized selector to fetch the fonts from the global styles config we have in the global styles config key of the block editor settings and load the fonts when they change. I believe we may have logic that get close to this for "styles"...
There was a problem hiding this comment.
If fonts need to be loaded in the iframe, can we instead move the logic to load fonts into the Iframe component instead?
Fonts should be added in both the main document and the iframe's document. If we move that logic to the iframe document, could we add those to the main one with the same code? Should we repeat the font loading in both places? What happen when the editor is not rendering the iframe? (shouldIframe is false in a few places across the codebase)
There was a problem hiding this comment.
I think in most places for block themes (the ones that supports fonts), we're using the iframe. There are still some case where we are not though: In the post editor, and only if v<3 blocks are registered or no metaboxes and only in Core (Gutenberg plugin forces iframe for the post editor I think in block themes).
We are working on removing these edge cases but yeah in the meantime we can probably have a reusable hook or something and I think BlockCanvas is where the switching happens between iframe or not.
There was a problem hiding this comment.
In this commit I removed this hardcoded references to the document and 'iframe' references. Now it's using a ref to reference the document following the useDarkThemeBodyClassName example: 5a9e2d0
| if ( ! node ) { | ||
| return; | ||
| } | ||
| function useDarkThemeBodyClassName( scope, ref ) { |
There was a problem hiding this comment.
Why did you refactor this from a hook that returns a ref to a hook that receives a ref as an argument?
Returning a ref allow supporting conditional rendering, you can adapt the hook when the "node" changes, it's not something you can do in hooks that receive refs.
Receiving refs in hooks is a pattern we should avoid (See recent discussion here #64943 (comment) )
There was a problem hiding this comment.
Why did you refactor this from a hook that returns a ref to a hook that receives a ref as an argument?
Because it's hard to understand the pattern (at least for me 😆 ), so I thought it wasn't something 100% intentional. Thanks for providing context. Now I see the reasons why it is like that. I reverted the changes to that hook and refactored the new useEditorFontsResolver to follow that pattern: 463fa95
…esolver follwing useDarkThemeBodyClassName pattern
There was a problem hiding this comment.
This tests well for me in the Editor; I can see the correct font faces being loaded and applied when switching style variations.
The change to how the fonts resolver is now added to EditorStyles looks good and seems more aligned with the other style element used here.
I also believe the feedback in this comment from @youknowriad has been addressed, although it'd be great to see if Riad has any further feedback here.
Otherwise, I think this is looking ready to bring in 👏
@justintadlock, could you provide the theme you are testing? |
| currentTheme: | ||
| // Disable Reason: Using 'core' as string to avoid circular dependency importing from @wordpress/core-data. | ||
| // eslint-disable-next-line @wordpress/data-no-store-string-literals | ||
| select( 'core' )?.getCurrentTheme(), |
There was a problem hiding this comment.
This is not allowed in the block-editor package. We shouldn't add an eslint exception. Why do we need the theme object here?
There was a problem hiding this comment.
To get the base url of the theme's fonts.
Example: the theme.json data has something like file:/assets/fonts/one-font.woff2.
We need to know how to resolve that theme relative font URL in the browser.
There was a problem hiding this comment.
We need to find an alternative solution. The block editor is a generic package independent of WordPress and can't make REST API calls.
The alternative I suggested initially is to "resolve" the files in the server and add a new _unstableType for the "styles" object received by the editor.
There was a problem hiding this comment.
to "resolve" the files in the server
Do you mean when the theme.json data is read from the file / database?
add a new _unstableType for the "styles" object received by the editor.
Sorry but I don't understand this.
There was a problem hiding this comment.
Do you mean when the theme.json data is read from the file / database?
Yes, basically in this place, in the code base. We read global styles and enqueue "styles" setting in the block editor. We could add a new "style" in that array with a specific "_unstableType" => "font" that we treat in a custom way in the EditorStyles component.
I know that function is in WordPress Core but in Gutenberg we have a hook to override the output of this function block_editor_settings_all filter I think.
I know that we used this approach in the past for "svg filters" which are also "special styles" that are not just CSS. @ajlende would know more but I think we moved a little bit from it (not entirely sure why though)
There was a problem hiding this comment.
you're right in the sense that useGlobalStylesOutput is also a block-editor API it seems. I thought personally that it was an "edit-site" API, so we could fetch the theme and do the resolution from there. That said it seems useGlobalStylesOutput is a private API for now. I think we can add the "theme path/url" as an argument to address that.
It's unfortunate thought that "resolving fonts" is the only thing from a "theme.json" object that requires outside data (theme) in order to resolve the styles properly.
There was a problem hiding this comment.
This touches upon many of the issues we grappled with when dealing with background image relative paths.
Ultimately, we settled on a balance between the server and client, where:
- the server resolves relative paths
- sends them to the client in the
_linksarray in the REST response - the client then has access to both relative and absolute paths for different tasks, e.g., using relative paths for exporting theme.json, and absolute paths for building CSS
If you think something similar would be appropriate here, I'd be happy to help out.
See the original PR: #61271
Also, there is a slightly related discussion about whether absolute paths to theme assets should be saved in the global styles CPT at all: #61809
There was a problem hiding this comment.
Thanks @ramonjd that is indeed very similar. It seems like we're starting to have multiple needs for the same thing: resolving relative paths during "global styles resolution". It would be good to normalize/document/generalize this a bit so the path is clear if it comes up again.
There was a problem hiding this comment.
Thanks for the additional context. I took a look to the _links implementation and (at a first glance) it seems to be more complex than needed for this particular dutie (resolve the theme relative path of a font face in the browser). Does the _linksknowledge of global styles implies that the global styles components know about the rest API design? It's good the intention to provide a common way to do this but is the backend code added really needed?
Could injecting the currentTheme into the editor settings using the GlobaStylesRenderer component be a simpler approach that works? I tried that in this commit: 8ced871
GlobaStylesRenderer is inside the edit-site package and I imagine that is ok it knows about a theme, is this correct?
Maybe the problem is that we would need to read the theme from the editor settings in the useEditorFontsResolver which is inside block-editor package.
How bad is this solution?
There was a problem hiding this comment.
resolve the theme relative path of a font face in the browser
What does "resolve" mean in this context? Resolving to get the full URL I presume.
Can you be sure that currentTheme.stylesheet_uri is the base URL of the font assets always?
If so, then it might be enough to do it on the clientside.
One of the considerations with which I had to contend when looking at theme.json image assets is that the file could be in the current theme's directory, or, in the case of a child theme, inherited by the parent theme.
Also there are filters that allow themes/plugins etc to change the stylesheet URI.
I wasn't testing with any one specific theme. What I shared above could be seen with any theme that includes web fonts in a style variation. I saw the same with Twenty Twenty-Four. Do the changes since my last comment address loading the fonts in the iframes in the two sidebar panels? I can certainly test again. |
|
The latest PR is behaving much better than it did when I initially tested. There's still an issue with the initial state in the sidebar panels, but they are updated as you attempt to preview. Here's a quick video that walks through what's currently happening: pr-65019-type-001.mp4I zipped a copy of my theme, which has a lot more variety with typography than TT4: x3p0-ideas.zip |
noisysocks
added
[Type] Bug
|
Flaky tests detected in 8ced871. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10960108376
|
What?
Add a client-side font face resolver in the editor.
Why?
To load font faces dynamically in the browser, for example, when they change as a result of applying a theme style variation.
Fixes: #59965
How?
The editor font face resolver loads the font faces of the global styles. It keeps track of the already loaded assets to avoid loding them twice.
Testing Instructions
Try to load a style variation and check that the fonts referenced in those style variations load as expected. See the screencast below as example.
Screenshots or screencast
2024-09-05.13-05-42.mp4
Follow up:
Make the editor fonts resolver something exposed out of the package so it can be accessed by other parts of the code, for example the font library. This will also allow us to have a global registry of already loaded font assets in the client. (Currently there are 2 one is used by the font library (part of the
edit-sitepackage and one by the site editor (part of theblock-editorpackage). Having a unique list of already loaded assets would save us from making some repeated requests. This could help to reduce the partial code duplication of some of the utils functions used here too.