Block Typography preset in a global class or relative style does not get applied

General
1

Description:

When adding a block typography preset to a global class or a relative style, the styles from the preset (e.g. font-family, font-size, etc) do not get applied to the block.

Step-by-step reproduction instructions:

  1. Open the Post Editor for a Page
  2. In Cwicly Global Styles > Elements > Block Typography - create a Preset (with a font-family / font-size)
  3. Add a Heading block to the Page
  4. Add a Global Class to the Heading block
  5. (optionally) Add a Relative Style to the Global Class
  6. Select and enable the Preset created earlier (in the context of the Global Class or Relative Style above)
  7. Notice the Heading font does not reflect what was set in the Preset

Screenshots, screen recording, code snippet

Screenshot 2023-04-14 at 00.50.23

Environment info

  • WordPress version: 6.2
  • Gutenberg Plugin version: -
  • Cwicly Plugin version: 1.2.9.5.8.2
  • Cwicly Theme version: 1.0.3
2

This issue may or may not be related to:

It is distinct because it is reproducible irrespective of front-end rendering which was cited as a determining factor in the other bug.

3

I think the “bug” here is, that the font presets are not greyed out when a global class is selected (active).

4

@Marius, Are you saying that font presets are not applicable to global classes? If so, I’m curious what the rationale for this is.

If they are simply collections of styles, surely they can be applied in any context whether it is at the block level, relative style level or global class level.

The way I have been thinking about them is just another set of grouped styles that get added as part of the cascade, but perhaps there are implementation specific details I am not aware of.

5

The style(s) of a font preset is attatched to an actual class.
And I can’t see that this behaviour would change when using it on global classes.

So the logic in this case would be:
If a specific global class is added to a block, then add another class (font preset) to the block as well. Imo, that wouldn’t make any sense and I can’t see how that should be intentional.

That’s why the font preset is not being added and styles are not applied to your global class.
It’s just another global class.

1 Like
6

Thanks for clarifying, @Marius. This makes sense based on the implementation as you describe it.

It is unfortunate though as it would be more flexible if the styles were merged with the selected global class.

@Louis, do you have any input on this as a possible enhancement?

1 Like
7

While I understand why one would use these font presets, they always felt like a foreign object to me, as in my opinion they are kind of contradictory to Cwicly’s concept and philosophy.

The use case you are describing reads for me that using global classes could be the more appropriate way to go, as it gives you the flexibility you need. Font presets might hinder you.
You still can make use of them, they just won’t get added in the way you had in mind initially.

Making use of font presets is rather a thing when relying mainly on block classes.
When following a global class driven workflow, I’m not sure if that’s a proper concept.
It’s a nice concept and tool for beginners / average users. That at least is my take on it.

Maybe you want share your thoughts why you decided for font presets over global classes.
Font presets should always contain the main style, one or more additional global class could act like modifiers.
It kind of reads that your approach is the exact opposite way.
But maybe that’s only because you were trying to connect them somehow.

Ultimately, mixing font related global classes with font presets might not be the best idea.
You would need to manage global classes from 2 different areas inside the builder.

8

Yeah, I agree with @Marius. I don’t see any benefits for using typography presets when you can just use a class directly.

9

There are very simple considerations from our side.

  1. We need to be able to translate the font styles from the designs to the website in a clean easily repeatable way.
  2. Our clients (including non-technical ones) need to be able to choose the font in a way that is easy and consistent
  3. We therefore want to re-use the same methodology for both the site editing and the page/post editing (i.e. no duplication of code / effort)

Font presets provide the perfect container for the font styles in a way that our clients are familiar with (e.g. if we have migrated them from other page builders) and that encapsulate the responsive aspects so that they can choose once and get the benefits on all screen sizes.

While we as developers are more than happy with using global classes, our clients having to learn to add/remove and have to search/scroll through lists of global classes (which are numbered significantly more than our font presets are in most sites) is not a viable option.

Until Cwicly provides a way to curate visible classes per role in the role editor (for example), we would prefer that our non-technical clients avoid interacting with classes altogether.

So therefore presets are the obvious choice.

Regarding our intended usage of Presets with global classes, please review the following scenario:

You have a semantically grouped set of blocks (e.g. a Pricing plan card), that will potentially be displayed multiple times per page on various pages. Because of this, global classes are a good fit (e.g. .pricing-plan-card for the base block). You specify your global class and want to avoid using a class for every sub-element within the grouping to keep the code cleaner, so you use relative styles to target child elements of the .pricing-plan-card (e.g. .pricing-plan-card > h4 rather than .pricing-plan-card > .pricing-plan-title).

Notice that in this scenario, either way, you cannot use the presets for the relative styling and would have to add all of the responsive font styles again. This is a waste of valuable time when the styles have already been clearly and neatly defined in the preset.

We would simply like to select the preset within the global class / relative style and have those font styles applied in that context. Just in the same way that you can choose a globally defined background colour variable in the context of a global class.

If you believe there is a way other than the presets to define the font styles once and re-use them everywhere easily for both the developer and client, please let me know.

10

To put this into clear focus, please put yourself in the shoes of the non-technical client and see which of the following is easier to use:

A dropdown that contains all of the classes for the entire website which may or may not be font related and are named for coding purposes:
Screenshot 2023-04-14 at 04.48.31

A dropdown the sole purpose of which is to select font related styles that are named for human readability:
Screenshot 2023-04-14 at 04.46.56

I hope you can understand from all of this that we are holding our client’s needs as a high priority and therefore for them Presets are an extremely valuable feature. While we know we can use presets and classes together, duplicating the styles of each preset in a respective global class seems like an unnecessary maintenance headache.

11

Hey @StrangeTech.

Thanks a lot for explaining your situation in detail - that helped a lot.
However, I think you were trying to build something around the font presets which is not possible and wouldn’t make much sense in my opinion, at least not in the way you are intending.

You are focusing on the font presets because they feature the option of labeling and selecting them from a dropdown.
It’s a perfect example of how limiting other tools are which mainly/exclusively rely on these kinds of options.
They come with limitations by design and especially when working with Cwicly, this is not something one is facing in general at all. It’s an exception and as I mentioned:

However, what I could see as a potential improvement is the ability of adding global classes to individual font presets, and not the opposite way as you intended to do. Not in the block inspector, but in the block typography item area inside the global styles area.
So, when a block preset is selected from a dropdown in the block inspectors’ typography area, not only will the font preset styles gets added, but also all global classes which are added/connected to it would show up as actual global classes in the UI.

image
image867Ă—995 45.8 KB

It’s just a quick idea. Does it make sense? Would other users make use of it too?
I don’t know.
You could try to find out by creating a feature suggestion and collecting user feedback.
For me, font presets are just font presets. It’s good that things are not overcomplicated.

What I can see at some point are class collections.
Combining global/virtual classes (bundling, not merging) as presets which can be labeled and inserted from a dropdown, same principle as we see with the font presets.
Example: A preset, labeled as “Team Card Wrapper”, which holds 8 global classes.

12

I am making a feature request for something along the same lines - this will be ideal for enabling clients to quickly customise a block with pre-created styles, especially if we can show only specific “bundles” to specific roles.