Blog

If you are a WordPress theme developer, chances are high that you’re working with the Customizer to provide certain design options to your themes’ users – whether it is for colors, fonts, spacing or else. Providing customization opportunities is crucial for a theme’s adoption as you will never be able to please every user with your theme’s out-of-the-box design. As widely known, most WordPress users look for feature-rich solutions when assembling their site. They may find your theme’s base design very appealing, but if they cannot modify it to e.g. use their brand colors, they’ll quickly move on to something else. Long story short: Allowing users to customize your theme is crucial for adoption.

Now there’s an issue with that though: Most of these design options affect the site’s CSS, and CSS is a largely static resource. Therefore the typical approach to integrate these Customizer controls with the theme’s actual appearance is to copy the pieces of CSS that would be affected by the respective options from the stylesheet into a PHP file, and from there generate that stylesheet on the fly. This results in three major problems:

1. You are most likely sending a whole bunch of duplicate CSS down the line, negatively affecting performance of the site.
2. Because you are duplicating CSS, the approach is quite error-prone. For example when modifying CSS later, you need to remember to also make the exact same change in the Customizer CSS, if it applies there too.
3. This also affects the WYSIWYG experience in the editor, as you also need to manually maintain the CSS for the editor (Gutenberg / classic) in the same way.

There is a solution to all of these problems though, and its name is “CSS Custom Properties”. In this post we will look at how to use this CSS feature to improve UX for both website visitors and content creators, all at once.

Continue reading “Using CSS Custom Properties for better UX in Frontend and Gutenberg”

This is essentially a written version of the talk of the same name that I gave at WordCamp Europe 2019 (see the related slide deck).

As I’m sure we can all confirm, WordPress provides a strong toolset for creating awesome content. Particularly with the availability of the Gutenberg editor, publishers can now implement more interesting layouts and take their content quality to the next level. However, while the content itself is certainly the most important part of a website, there are a few other supporting pillars to ensure delightful content experiences for users consuming that content. Websites should be:

For more details on these four pillars, see the “Progressive WordPress Themes” talk by my colleagues Alberto Medina and Thierry Muller.

Unfortunately, satisfying each of these four requirements is anything but trivial. You might already know that just installing a performance or a security plugin is not actually going to magically solve these respective points.

Technologies and best practices on the web are constantly evolving: Regularly new APIs are introduced, new standards being established, former best practices being overruled. Add in all the popular frameworks that have come and gone over the years, and it becomes even more evident: Even the most senior rockstar full-stack developer cannot keep up with this technology complexity on their own.

In addition, even in the scope of a single website or application, maintaining a good overview of the different pieces can present a huge cognitive challenge. HTML, CSS, JavaScript, code for different areas shed across everywhere, with possible incompatibilities in functionality as well as in appearance with all thiese pieces being used in combination. This is what we can refer to as content complexity.

Fortunately, there are ways to reduce and work around both of these complexities. In this post we will look at a component-based approach and a relatively new technology called “Custom Elements” and how they address the aforementioned problems.

Continue reading “Leveraging the Power of Custom Elements in Gutenberg”