Add: Font Family picking mechanism #24868
Conversation
jorgefilipecosta
requested review from
ajitbohra,
ellatrix,
Soean,
spacedmonkey,
talldan,
TimothyBJacobs and
youknowriad
as code owners
jorgefilipecosta
added
the
Global Styles
|
Size Change: +477 B (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
|
Should the select control show plain - unstyled - text instead of the font previews? |
ZebulanStanphill
added
the
Needs Accessibility Feedback
Hi @aristath, That's a good point. But if one makes a set of google font available will not the fonts need to be enqueued all the time anyway? Because a font may be used in a paragraph somewhere so the assets need to be loaded so the font displays correctly when used in a random paragraph. |
|
It depends on how that font-selector is used... It's pretty common practice for current (legacy/non-FSE) themes to add a dropdown in the customizer for example where the user can select any google-font for their body, headers etc. Imagine they want to port that functionality to global-styles... it's a common and valid scenario, as for example some locales require specific fonts that the theme can't fit in a list of hand-picked fonts. The way things are currently handled in the customizer in themes is that the Font-family selectors will get abused real fast... It would just be safer if it was a plain unstyled |
|
As for when the fonts get loaded, I can easily picture themes adding a filter on |
|
We should use this opportunity to provide some beautiful and slighty more modern font stacks! What you can do across Windows, Mac and Linux now, is a fair bit better than it was back in the comic-sans days 🙈 😅 |
jorgefilipecosta
force-pushed
the
add/font-family-picking-mechanism
branch
from
02f0512 to
e791e77
Compare
Hi @jasmussen, the list I used seems to be what people normally call web-safe fonts. I guess currently we have other options and the list may be outdated. Do you know any resource that contains an updated list of fonts we can safely use on the web? Or are there any specific fonts you would like to include? |
Hi @aristath, this solution may work but has some costs e.g: iterate on all blocks to generate the list of fonts that should be enqueued depending on the fonts used on the blocks. But in scenarios where one wants to provide a very large set of fonts, I guess there is no other way. |
|
for > It depends on how that font-selector is used...
The problem of loading the fonts is very complex; on one side, we want to be very unopinionated so our mechanism can be used by everyone, including to display a list of fonts from a third-party provider. @pinarol are there plans to support themes loading third party fonts and have them displayed correctly on mobile? E.g: google fonts https://fonts.google.com/specimen/Oswald?standard-styles=&sidebar.open=true&selection.family=Oswald:wght@600;691 If the plan is to support mobile and given that we may not be easily able to run arbitrary code there, I guess we may need a declarative mechanism for font loading. One simple option would be on theme JSON provide something like: That declaration would make sure the editor and frontend always enqueue the stylesheet. So parsing it and retrieving the font URL https://fonts.gstatic.com/s/oswald/v35/TK3iWkUHHAIjg752GT8Gl-1PKw.woff2 (for 200 font-weight) is not very hard. We would only parse the font-face declarations on that URL. The ways fonts are set are complex. We may have different font files depending on weight and even Unicode ranges. So on the same line of text, to render some Unicode character, one should use a font file to render another Unicode character; one may need to use another font file. One the web browsers deal with using the correct files etc., so we get that for free I'm not sure how this would work on mobile. This simple loading mechanism assumes the cssSrc links to a file that provides all the font weights available in that font-family as font-weights are not being taken into account in this simple mechanism. I guess if we want to take into account font weights, a possibility would be to say that the WordPress font loading mechanism follows a specific syntax: E.g. "example.com/font-loader.php?font-family="Oswald"&font-weights=200,400". Where we would append "?font-family="Oswald"&font-weights=200,400" to the font loader resource. Any thoughts on these approaches to load fonts? |
|
Regarding mobile, this link says woff files (seems the most common format on the web) are not supported on react native android https://docs.expo.io/guides/using-custom-fonts/. I'm not sure if that is accurate. |
|
A few thoughts here, pulled from our discussion in today's design meeting:
|
|
I think the idea of an advanced component to manipulate the stack is a good compromise which is similar to the idea of padding/margin controls displaying S, M, L, and custom. The fallbacks should be handled by the theme in the case of a simpler control where a single preferred font is selected from this dropdown as opposed to a full fallback stack. Regardless, the end-user will always have full control of the fonts used through their browser settings. |
|
Hi @richtabor, @jrtashjian, |
Not really. We are not interested in loading 3rd party fonts on native mobile side. More context in these comments: #24165 (comment) #24165 (comment) We are interested in allowing to change size related things, like font size, line height etc. But not changing the font family. |
Absolutely, I recognize it. So long as the list is eventually extensible, I think we have an opportunity to do a bit of curation of the default offering. This also touches on what @richtabor asks:
One of the options I'd personally love to have on this list, is a "system font" stack:
☝️ that is intrinsically a very long list because it needs to include fonts from a multitude of operating systems to intentionally fall back on the one that is available. Much as I'd like it, there may not be a place in WordPress for a "system fonts" stack, perhaps it's too high concept. But it illustrates the point Rich outlines, that the list can get unwieldy. For that reason, I like the suggestion of a human-friendly field to describe a stack.
That works for Google because the font is expected to work across platforms. But for the non-Google stacks, unless we include cross-platform alternatives, we'd very quickly skew the aesthetics towards a particular platform. Here's a chart of which fonts are installed on which platforms, and it becomes quite a puzzle. At a very quick glance, this resource looks like a decent starting point, insofar as it offers exactly that, font stacks with human readable names, such as "Georgia-based", "Times New Roman-based" (but with better labels). From that list, I'd start with these: That's a decent base spread of fonts, and it's always easy to expand the range later on. As a next step I'd reduce that stack to at most 4 or 5 in the stack. @kjellr do you have any insights to help guide how to reduce those stacks? Or any other thoughts? |
That would be brilliant... in most cases a carefully curated list of system fonts works wonders and works across the board. Taking this a step further, the ideal solution for me would consist of options like these:
They are abstract enough to convey the message that these are system fonts that may vary depending on the platform, and they're specific enough to convey what they are. We also need to think of cross-platform... I'm on Ubuntu so most of the font-families that by default exist in Windows & OSX don't exist on my laptop. If the list consists of multiple sans-serif variants (Arial, Helvetica, Tahoma, Geneva and the likes all as different options) then they're all going to look the same to me 'cause they'll fallback to sans-serif. |
I think I agree with your general sentiment, though perhaps I'd go a little bit less abstract than just serif and sans-serif. But I wanted to clarify that by using the term "system fonts", in this case I was referring to a so called system font stack whose purpose is to emulate the same font your operating system uses. I.e. SF for Mac, Segoe UI for Windows. |
|
I have a list of modern font stacks here if that helps: I would also like a |
|
Thank you Ben, that is an excellent resource! Shorter stacks, human readable names (though I'd skew the sans serif name in favor of Helvetica ;) ) and useful. I would still start smaller, though, because it's trivial to expand the list, but it's VERY hard to reduce the list. If we were to start with, say, 2 sans serif, 2 serifs and 1 monospace font, which stacks would you choose? |
+1 to not enqueing any. There are many ways to enqueue a font, and there are dozens of webfont providers out there. Core shouldn't enqueue anything here, if a theme or plugin adds 3rd-party fonts it's up to them to implement their enqueing. Google Fonts don't work the same as Adobe fonts or locally-hosted webfonts, or any other provider... each one needs separate implementations and all core can do is say "you need to get this font". How that font is added in the browser is outside the scope of Gutenberg. For system fonts that don't need enqueueing there is no issue.
I'll have to disagree with that... If on my theme I have 3 system fonts, 10 google-fonts and 5 adobe fonts I'd like them in separate groups. System fonts will be picked by those who want something native & fast, gfonts by those who don't have issues with privacy and performance, adobe fonts by those who have an API key. |
Hi @nosolosw, @aristath I agree core should not enqueue any font. This PR is not enqueuing any font. We allow the user to select between 5 fonts + the system font. We don't enqueue these fonts. We choose these five fonts because they were all very safe, and we are assuming users will have these fonts on their system. The users having some choice, even if very limited, is an excellent way to get attention to the feature; otherwise, the future would not be noticeable unless the time provides some fonts. |
I tend to agree with @aristath and I think having groups is helpful because fonts are typically grouped. We don't force the group usage in this PR it is something themes and plugins can provide or not. |
Regarding the css vars and unfiltered_html. This problem is a little different from the link color. On the link color, we need to use a CSS variable here, we just want to use a CSS variable. But we could still expand #25411 to allow all css variables and that would fix the issue. Regarding the usage of classes, I did not follow that option because I thought we had a decision to not use classes for presets and instead use CSS variables. We should revert that decision and just use classes for presets here like we currently do for colors? cc: @youknowriad |
aristath
added
the
[Feature] Themes
|
@jorgefilipecosta It was no longer possible to test this PR because it was too far behind the master branch, and FSE themes that worked on the master branch no longer worked with this one. |
|
Merged master here again, keeping this branch sync'd 'cause it's important. @jorgefilipecosta what is blocking us here? |
jorgefilipecosta
force-pushed
the
add/font-family-picking-mechanism
branch
from
32ab15d to
ba5cecc
Compare
|
I think this PR should be ready to merge I applied the feedback and right now core does not expose any font family preset so by default the system is disabled. One thing that we need to clarify before the merge is if we should expose the font family picker on the post editor. Right now we do that as we do for the other UI parts, but if I'm not in error I think @mtias referred that for font-family we should not expose it to individual blocks. @mtias would you be able to confirm if that's the case? If yes I will update the PR to remove the font family from individual blocks if not I guess we can merge. |
|
Let's start with this only in the global context and for specific blocks that want it (through theme.json) like "navigation". Do we need the |
jorgefilipecosta
force-pushed
the
add/font-family-picking-mechanism
branch
from
ba5cecc to
b6d1fcb
Compare
|
Hi @mtias, your feedback was applied:
We can test the font family mechanism by adding the following data under typography to theme.json. Themes can disable font family picking for the global level and for each block level by simply setting font families options to empty: Following the same approach, we have for the other blocks. |
jorgefilipecosta
force-pushed
the
add/font-family-picking-mechanism
branch
from
b6d1fcb to
081494a
Compare
|
Merged master branch here, resolving some conflicts that existed due to recent PRs that got merged. |
jorgefilipecosta
dismissed
oandregal’s stale review
The review was addressed.
|
@jorgefilipecosta @aristath This PR landed without documentation. I've prepared a fix for it at #26891 |
| $font_family_name = substr( $font_family, $index_to_splice ); | ||
| $styles[] = sprintf( 'font-family: var(--wp--preset--font-family--%s);', $font_family_name ); | ||
| } else { | ||
| $styles[] = sprintf( 'font-family: %s;', $block_attributes['style']['color']['fontFamily'] ); |
There was a problem hiding this comment.
Under which situations a font-family value is not in the form of var:preset|font-family|etc?
Unlike other style properties, users can't provide custom values, so I don't see how this path is reached. I presume we can remove it. The fact that this has been using style.COLOR.fontFamily without a bug being reported seems to confirm this is a code path we don't need. cc @jorgefilipecosta @aristath
For context, this question comes from a PR I'm working on at #31910 to use classes instead of CSS Custom Properties for font-family. I'm looking at removing this code path there.
There was a problem hiding this comment.
I guess a situation where font-family may not be preset is in the case of a block pattern where the pattern is excitedly using a specific font family in a block.
Regarding the usage of classes for font-family presets I think we can use variables for now it is not clear classes bring any advantage in that use case. For the colors, we are outputting CSS vars anyway so a block could use the vars directly and we need to support that. For the font family, I guess we can keep with just vars for now and see what feedback we get.
There was a problem hiding this comment.
I guess a situation where font-family may not be preset is in the case of a block pattern
Nice thinking, thanks! I'll keep that use case then.
Regarding the usage of classes for font-family presets I think we can use variables for now it is not clear classes bring any advantage in that use case
I'd think we want to do it the other way around: what's the advantage of font-family using custom properties instead of classes, as the other style properties do?
|
Thank you for your assistance! |
|
@jorgefilipecosta is there updated documentation for this? You used this example of theme.json contents to opt into the font picker: But that structure (block > settings) isn't documented in any way I can find here, let alone in relation to enabling the font picker. |
|
Hi Ethan Clevenger, One can control settings per block, now the syntax is not that one but there are updated samples of using settings per block at https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/#settings-examples e.g: "Disable border radius for the button block:". Any setting can be set globally or for a specific block. |
This PR adds a font family picking mechanism to the global styles similar to line-height and adds the mechanism at the block level to the paragraph block.
By default, we present as options the list of web-safe fonts https://www.w3schools.com/cssref/css_Websafe_fonts.asp. Themes are able to overwrite the font families available and even use custom ones e.g: google, adobe, etc provided they are enqueued.
Related: #23204
How has this been tested?
I verified I'm able to change the font family in a paragraph.
I verified I can change the font families of all paragraphs globally using the following theme.json: