Introducing Seedlet

A typography-led theme, built for the future of block-based theming.

This week the Automattic theme team launched a brand new theme called Seedlet. Seedlet is a simple, typography-driven foundation for folks to build their websites on. Its styles are opinionated, but generic enough that the theme can apply to a wide variety of different use cases.

This is a particularly exciting launch for us, because not only is Seedlet a lovely theme on the front end, but its backend was crafted with the future of theming in mind.

It ships with block patterns

As we’ve written before, block patterns are an incredible new tool for theme authors. We anticipate building these into every one of our themes going forward, giving users easy shortcuts to creating some of what they see in the theme demo.

Seedlet ships with a few patterns. Two of them leverage some creative use of gradient background presets, and the other makes your posts appear to snake down the page like a vine.

It’s built to be flexible

Behind the scenes, Seedlet has been built with a comprehensive system of CSS variables. If you’ve seen our Varia theme, you’ll be somewhat familiar with the system. Essentially, it’s a tiered system of variables inspired by modular CSS. In effect, everything from the site’s color palette to its spacing and structure is hooked into CSS variables.

Seedlet uses CSS variables as design tokens, instead of the SASS variables used in Varia. By relying on CSS variables for all of the core style attributes, we’re able to bridge the gap between the front end and the editor styles. If we change the value of Seedlet’s --global--color--background variable, the background of the site will update in both the front end and the editor immediately, with no compiling necessary.

CSS variables are also easily manipulated in the Customizer (as in Seedlet’s custom colors implementation), or in child themes. In the tests we’ve done, you can easily create a drastically different child theme by modifying only Seedlet’s CSS variables. Stay tuned for more to come on this, as we build out the first round of child themes based on Seedlet.

It’s ready for our block-based future

Seedlet’s extensive use of CSS variables also sets it up nicely to integrate with the block editor’s upcoming Global Styles functionality. CSS variables are what make Global Styles work, and Seedlet is full of them.

To demonstrate this transition, we put together a child theme that maps a number of Seedlet’s CSS variables to Global Styles values defined in experimental-theme.json. That, plus a few block templates, results in a fully functional, block-based version of Seedlet. You can explore this today by visiting Seedlet’s GitHub repository:

https://github.com/Automattic/themes/tree/master/seedlet-blocks

We plan to iterate on (and eventually launch!) this block-based version alongside the standard version of Seedlet.


We’re excited to see how Seedlet evolves as we continue moving towards block-based themes. In the meantime, give Seedlet a try, and feel free to contribute on GitHub if you’re so inclined.

Visit Seedlet on:


For more block-based exploration using Seedlet, check out this demo using Seedlet on the Gutenberg Times livestream:

Exploring Global Styles

Note: The code samples here are out of date. Please be sure to check out the block editor documentation for the latest on how to implement Global Styles.

Global Styles is an aspect of full site editing that will have a major impact on theme development. To further my understanding of this feature, I explored adding support for it to the block-based version of Twenty Twenty that Jeff Ong recently shared.

Some background: Global Styles aims to bring site-wide controls for things like colors, typography, and spacing into Gutenberg. The originating GitHub thread for the effort is a great primer on its goals and scope. From a technical perspective, Global Styles currently works by using CSS variables to define styles. A set of controls are being developed to allow users to edit those variables within the Gutenberg UI.

A lot of Global Styles work is still in flux, but early pieces are available for themes to experiment with. For example, while using the latest version of the Gutenberg Plugin, themes can define a base set of Global Style variables in an experimental-theme.json file. Here’s a simple example of what one might look like, courtesy of Andrés Manerio’s global styles demo theme:

{
    "color": {
        "background": "#fff",
        "primary": "#00f",
        "text": "#000"
    },
    "typography": {
        "font-scale": 1.2,
        "font-size": "16px",
        "font-weight": 400,
        "line-height": 1.5
    }
}

Each of these are automatically rendered out as CSS variables that the theme can hook into. On the front end, this equates to:

:root {
    --wp--color--background: #fff;
    --wp--color--primary: #00f;
    --wp--color--text: #000;
    --wp--typography--font-scale: 1.2;
    --wp--typography--font-size: 16px;
    --wp--typography--font-weight: 400;
    --wp--typography--line-height: 1.5;
}

Theme authors can pull those in like any other CSS variable. For example:

p {
    color: var(--wp--color--text);
    font-size: var(--wp--typography--font-size);
    line-height: var(--wp--typography--line-height);
}

To help wrap my head around this, I took Jeff Ong’s work on the Twenty Twenty Blocks theme, and adapted it to use CSS variables as defined in a brand new experimental-theme.json file. You can browse this here:

https://github.com/WordPress/theme-experiments/pull/26

This exercise was relatively straightforward. The concept really shines when thinking a little farther out though. Once I had those new variables in place, I tried them alongside an in-progress Gutenberg PR to add a Global Styles sidebar to the beta site editor. This provides a vision of how style editing might feel in the future:

This is still very early and very buggy, but the ability to modify these values globally in a single place is still very exciting. This is something my colleagues and I are looking forward to implementing into our themes when it’s ready.

In case anyone wants to dig in to the exploration, the full code and some instructions are available over in the WordPress/theme-experiments repository. Give it a test, and try adding an experimental-theme.json file to your block-based theme experiments as well.

For more information on Global Styles, follow the project board on GitHub, and consider joining the bi-weekly Block-based Themes meeting in the #theme-review channel of WordPress.org’s Slack.

Finally, if you’ve already given Global Styles a try, I’d love to hear about it! Please share your work in the theme-experiments repository, or drop a link into the comments.

Customizing Gutenberg blocks with block styles

Block styles are a simple way to get started with Gutenberg development: With a few lines of CSS, you can build something that feels like a whole new custom block.

This post was updated on January 13, 2020 to adopt the server-side registration approach described in the Block Editor handbook.


A few years ago, Matt Mullenweg urged us all to “Learn JavaScript Deeply.” Becoming more familiar and comfortable with JavaScript is increasingly important for those of us who build the web. In the world of WordPress, projects like Gutenberg have begun taking a major step into a JavaScript-powered future.

For designers and developers who are still getting used to these new languages and workflows, creating and customizing Gutenberg blocks can be somewhat intimidating. There are excellent toolkits like Create GutenBlock to help you get started, but even using those, building a block requires quite a bit of JavaScript familiarity. You also have to make sure you’ve got the right version of Node, learn some terminal commands, install some dependencies, etc. There’s quite a bit of up-front work necessary before you can jump in and start actually building something.

Despite these hurdles, we’ve seen an inspiring number of new block plugins surface lately: CoBlocks, and Atomic Blocks are great examples. They each add a variety of rich blocks, and truly enhance the site-building experience.

There’s a much simpler way to start customizing Gutenberg blocks though, and it’s something we haven’t seen utilized much at this point: block styles. They take only a few minutes to pick up, and mostly just require you to know CSS.

You’ve likely noticed block styles while using Gutenberg. The Quote, Pullquote, Separator, Table, and Button blocks ship with some alternate styles by default.

Block styles are an excellent but relatively unused area of Gutenberg customization. They’re a simple way to get started with Gutenberg development: With a few lines of CSS, you can build something that feels like a whole new custom block. Also, since they’re reusable across multiple sites, block styles help pave the way for a more flexible system of components that make up a site’s theme.

Technically, block styles are very simple. They’re composed of two things:

  • A few lines of PHP (or JavaScript) to declare the block variation and give it a custom class name.
  • CSS styles to fine-tune the appearance.

That’s it. A block style is a custom block class, with some styles applied.

Implementation

A block style can be implemented in a plugin or in a theme. For this example, I’m going to focus on making a plugin. One of the benefits of using a plugin is that it’s not tied to the user’s theme. This allows your block style to be used across any site, running any theme — as if you had built an entirely new custom block.

Block styles can be defined in JavaScript, or in PHP. To keep things simple, we’re going to focus on using the latter. This lets us set everything up with only two files:

  • index.php to set up the plugin, declare the block style, and enqueue the stylesheet
  • style.css to house the actual styles

index.php

By default, index.php just needs to initialize the plugin with a DocBloc, enqueue the CSS file, and register a new block style:

<?php
/**
 * Plugin Name: Block Styles
 */
 
/**
 * Register Custom Block Styles
 */
if ( function_exists( 'register_block_style' ) ) {
    function block_styles_register_block_styles() {
        /**
         * Register stylesheet
         */
        wp_register_style(
            'block-styles-stylesheet',
            plugins_url( 'style.css', __FILE__ ),
            array(),
            '1.1'
        );

        /**
         * Register block style
         */
        register_block_style(
            'core/paragraph',
            array(
                'name'         => 'blue-paragraph',
                'label'        => 'Blue Paragraph',
                'style_handle' => 'block-styles-stylesheet',
            )
        );
    }

    add_action( 'init', 'block_styles_register_block_styles' );
}

Let’s take a closer look at the block style registration portion:

register_block_style(
    'core/paragraph',
    array(
        'name'         => 'blue-paragraph',
        'label'        => 'Blue Paragraph',
        'style_handle' => 'block-styles-stylesheet',
    )
);

The second line tells Gutenberg which existing block to start with. In this example, we are going to create a block style for the Paragraph block. Any existing block can inherit a block style, so if you were to target a different block, you’d change core/paragraph to the name of a different block. Technically, these names are found in the Gutenberg block source code, but they’re usually easily guessable. For example: core/cover, core/separator, etc.

The name parameter on the fourth line creates the custom class that’ll be assigned to the block. In this case, I’m calling it a blue-paragraph, but it can be anything you’d like. Since this will be used for a CSS class, be sure not to use any spaces.

The label parameter corresponds to the text label for your block style. This will be shown in the interface when someone opens the “Block Styles” panel.

Finally, style_handle points WordPress to the stylesheet where it can find the CSS for your block style.

style.css

The CSS file is pretty straightforward. Use the custom class name you created in block.js (along with a is-style- prefix), and insert your styles inside:

.is-style-blue-paragraph {
// Custom CSS styles go here.
}

Your styles here will build off of the default block styles, and will be loaded in before a theme’s editor styles. So be sure to keep your selectors specific enough to override those potentially competing styles.

Block Styles Plugin Boilerplate

To help you get started, I’ve created a GitHub repository that you can clone and use to get started. It contains the three files detailed above, along with some light documentation.

https://github.com/Automattic/gutenberg-block-styles

Out of the box, the repository is a small plugin that adds a “Blue Paragraph” block style to the Paragraph block:

With a few small adjustments, it’s possible to change this into something drastically different. There’s another branch on that GitHub repository that includes a Music theme-style cover block variant:

I’ve included a third branch that adds a somewhat ridiculous animation to the text (or emoji) inside of a Cover block:

Both of these are accomplished by changing about a dozen lines of code in the repo. They took minutes to create, and work across any site that uses Gutenberg, regardless of the theme it’s using.

What will you create?

Block styles are ripe with possibility. I’d love to see a CSS Zen Garden-style plugin someday that showcases dozens of different ways to customize blocks through block styles.

In the meantime, have you built something cool using block styles? If so, I’d love to hear about it. Please share your explorations in the comments.

Designing a Gutenberg-Powered Theme: Music

Kjell Reigstad walks through his experience designing a block-powered theme.

Last week, Allan Cole and I shared a new Gutenberg-powered theme called Music. In this follow up post, I’m going to take you through the design process for the theme. At its core, this felt a lot like a typical theme design process, but I did learn a lot about block-based design along the way. 

Blocks

When Allan and I decided to make this theme, we already had a homepage comp featuring a handful of blocks. That comp did a great job of setting the tone for the design aesthetic. To get things going, I decided to apply that aesthetic to the other default Gutenberg blocks. I worked through the Gutenberg Blocks Sketch document from my last post, updating styles as I went.

 

Working this way was great for a couple reasons. First, it helped me focus — I’d never designed a block-optimized theme before, and this kept my design explorations squarely on the blocks themselves. I thought,  “Gutenberg is all about blocks, right? I’ll design some blocks.”

Second, the Sketch file allowed me to see every single block style in one place. In effect, I was creating a sort of pattern library as I went. I thought this was pretty cool, and figured it’d come in handy later on when we began development.

As I got further through these block designs, I realized the need to see all of these individual blocks in context; I’d design a wide-width cover image block, but I had no idea how it’d look in use. So I began dragging blocks around and stacking them up to get a sense of how they’d feel together.

Testing-Ground.png

This helped a little bit, but still wasn’t enough. At this point, I realized something that should’ve been obvious: blocks are not a theme. They’re just part of a theme. By designing blocks first, I’d been avoiding the big picture. Users will never see blocks all by themselves — they’ll exist within full pages. I needed to design more pages. 

Pages

My initial homepage design comp introduced a rough idea of a header and an off-centered text column. I began by duplicating that initial page and clearing out all the blocks on it, then pulled together some sample content. Looking at the project through the lens of my imagined client (the band Superserious), I was able to think through examples of blocks and block combinations that might exist on a real site: the columns block to display album information, the table block to display tour dates. This felt much more effective than randomly placing blocks on a page.

Around this time, I hit my stride, design-wise. I’d lay out a page using my existing blocks and the sample content. Then I’d iterate and experiment with everything on that page. Once things looked right, I’d migrate any new block tweaks back to the global symbols and start fresh on the next page. After a little while, I ended up with a solid set of sample pages.

 

Backing up and thinking about page design helped me shift focus to other, more traditional components that needed to be designed too: archive pages, page footers, post headers, etc. Designing these wasn’t all that different than it would’ve been without Gutenberg. In a way, we’ve all been designing with blocks all along — we just hadn’t called them blocks. Take a look at this entry summary:

Entry-Summary.png

If I’d designed this theme pre-Gutenberg, I still would’ve designed each one of those pieces — they’re all fairly standard parts of a theme. But thanks to Gutenberg, each piece is part of a clear pattern library, to be reused throughout the design by me and by the user. That’s pretty cool.

I’d gone into this project thinking I’d spend most of my time styling individual blocks, but I ended up splitting my time pretty evenly between designing block variations and overall page elements. In that sense, this wasn’t as drastically different from a traditional theme design as I’d anticipated.

Prototypes

I’d been getting ongoing feedback from Allan throughout the process above, but once we were happy with the page designs above, we gathered  with the rest of the Theme team to get broader design feedback. To help with that process, I pulled all my comps together into a prototype. This took just a few minutes to do, and really helped others get a sense of how the theme will work in practice.

I created two separate prototypes with Invision: one for desktop and one for mobile. If my transition from block design to full-page design was about looking at the bigger picture, these prototypes stepped back still further: they showed us the context around that big picture. We were all able to see the designs on-device and test some basic interactions. 

The team’s feedback was (as usual) very helpful — we made some subtle revisions to text contrast, adjusted a number of margins, and kicked off a lot of iteration on the mobile menu treatment.

Development

Allan had been focused on the build from the beginning, and had the majority of the framework in place at this point. After our design feedback session, I jumped into the code too.  

From the development angle, we’d already determined a few things in the design that we couldn’t do, or that would take too much effort. For instance, in my initial design comp I’d had a series of backgrounds run down the page. Gutenberg doesn’t have a method for doing something like that today; despite my wishful design thinking, there’s no method for layering a background behind a group of blocks. We could’ve accomplished it through customizer settings, but we shelved the idea in favor of keeping things simple. We also abandoned a bunch of the play buttons I’d originally included, since those’ll require some custom blocks (more on that later). 

Once I jumped into the code, my main revelation was that there were way more block options than I’d originally anticipated. A number of blocks had options I’d never noticed before. I hadn’t realized that paragraph blocks could be set to full width, or that cover image blocks could be floated left or right.

In addition, I realized some design decisions I’d made were actually supposed to be user-editable: I’d overlooked the fact that users can edit the text alignment and image opacity for the cover image block. This required more design exploration, but it guided us towards a much more customizable theme — definitely a win in the end.

Beyond those updates, the majority of the design-oriented development work involved minor fixes and adjustments — polishing up the CSS to make sure it aligned with the intent of the original design. 

Next steps

Now that we’ve had our initial release, Allan and I plan to build a separate plugin with complementary music-centric blocks, like a tour dates block and a mashup of a cover image and an audio player. We’ll hope to showcase those at some point in the future.

In the meantime, keep an eye out for the next post in the series: Allan’s experience from a development perspective.

 

Music: A Gutenberg-Powered Theme

Announcing the Music theme: an exploration of how Gutenberg can transform theme design and development.

A couple months ago, I created a Sketch document to assist with the design of block-driven themes. I posted about that here on Themeshaper, and provided a couple short examples of how it could be used in a theme design workflow.

Since then, Allan Cole and I have been working to make one of those examples — a site for an imagined band named Superserious — into a working example of a Gutenberg-powered WordPress theme. We named the theme “Music.”

Allan and I set out to experiment, learn, and create a resource for the community. We’ve documented our experience designing and building this theme, and will be publishing our notes in a series of posts here on Themeshaper.

To kick things off, we’re releasing Music on GitHub today. We’d love for you to give it a spin, tinker with it, and explore how it works with Gutenberg. Here are a few things to look out for:


Design

Our design goal for the theme has been to show that it’s possible (and encouraged!) to make a Gutenberg theme that doesn’t necessarily look like Gutenberg. We wanted to create something bold and a little experimental; a theme with somewhat aggressive, non-standard styles.

Gutenberg gives users unprecedented control over their site design, opening the door for variety and experimentation. Our favorite example of this is our cover image blocks. They look great out of the gate, but users can adjust the image, alignment, and color to achieve a wide range of looks:

cover-images.png

 


Development

You’ll be happy to hear that the overall theme development process wasn’t all that different with Gutenberg. Common patterns like headers, footers, and loops work just as you’d expect in a Gutenberg-powered theme.

In many areas, Gutenberg makes things easier for both users and developers. For instance, full-width header images used to require a custom-built customizer or theme option solution, but now they’re essentially built in. This was important to keep in mind while building the theme, and was a very positive change for development.

Creating stylesheets for blocks was pretty straightforward. Expanding on the built-in stylesheets in _s,  we added a blocks.scss file to the SASS directory and placed all of our block-specific styles and overrides there. This kept everything nice and organized and is likely to appear in _s in the future.

Since Gutenberg is output by the_content(), we learned to take special care with any wrapper divs that might clip or obstruct the expected behavior of Gutenberg blocks. We’ll talk more about that in a follow up post.



Block Styles

We’re truly excited about the custom editor styles that ship with Music. These styles are a breakthrough: they give users a much clearer sense of what their visitors will see on the front end.

Best of all (for theme developers at least), the editor styles were a breeze to integrate! We built all of these in over the course of just a few hours.



Like most of the work we do, the Music theme is open source. You can find it on GitHub:

https://github.com/automattic/musictheme/

If you’d just like to see the front end, feel free to click around our demo site here:

https://musictheme.mystagingwebsite.com/

In many ways, designing and building this theme was similar to the way we’ve made themes in the past — but we did carve out a few new practices along the way. Allan and I will be sharing them with you in upcoming posts. In the meantime, we encourage you to download, install, and experiment with Music yourself!

 

Read part two of this series: Designing a Gutenberg-Powered Theme: Music

Designing Themes with Gutenberg Blocks and Sketch

Follow Kjell Reigstad’s process as he explores designing a block-driven theme with Sketch, for the Gutenberg era.

There’s been an exciting discussion happening around the changes that Gutenberg will bring to themes. At Automattic, we’ve begun to prepare for Gutenberg by reevaluating our theme design and development processes.

As part of that work, I did some thinking about how I might start designing a block-driven theme today and what sorts of resources I’d want to have. The most important thing that came to mind was a way to access and customize all of the core Gutenberg blocks with a few clicks. This would allow me to quickly test and iterate on block design without having to dig into code. I do a good deal of my design work in Sketch, so I began to search for a way to make this possible there.

Luckily, there are already a few Gutenberg-related Sketch files in the wild. The Gutenberg Contributors page on GitHub and the Design Principles & Vision page on WordPress.org are great places to start. These are mostly aimed at the Gutenberg editing interface, however, and didn’t quite accomplish what I was looking for, so I ended up building a new file instead:

Gutenberg-Sketch-File.jpg

This new Sketch file contains symbols for all of the default Gutenberg blocks (with the exception of all the embeds, since those aren’t very customizable). With this set of symbols, it’s possible to quickly build a layout composed entirely of Gutenberg blocks using Sketch:

It’s actually pretty fun to use! In a way, it’s Gutenberg — but for Sketch. 😄
From here, it’s easy to start customizing styles:

I took this method for a spin and tried to mock up a theme for an imagined restaurant. To get started, I built out the page structure using default Gutenberg blocks:

From there, I started doing some light customizing. I cut myself off after a while, but the end result looked fairly decent:

I find this pretty cool. It’s an example of what a block-driven theme might look like with just a little bit of CSS customization.

From here, I could easily keep going and put together a complete, modular design system for this theme by customizing the rest of the Gutenberg blocks. I could view the blocks all at once on the Symbols page, and quickly build out a wide variety of layout options to make sure my styles held up to intense layout customization.


I almost ended there, but I decided to confront a lingering concern I’ve had about Gutenberg: I’ve feared that if we lean too much on Gutenberg for theme layout, we’ll end up with lots of very similar, “blocky” themes. The restaurant site I designed above looks fine, but it’s also clearly made of blocks. I wondered if it’d be possible to create something more experimental using this same Sketch file as a base.

So I took another stab at a pretend site design (this time for a band named Superserious), and forced myself to break out of the blocks a little more. Again, I began with a pure-Gutenberg layout:

But this time, I was much more aggressive in my customization and aimed for a more tailored mobile experience with bold typography:

This was a fun exercise, and it helped allay my fears a bit. That first Cover Image has all the usual pieces, but they’re styled in a very opinionated way. The rest of the blocks are fairly standard, but they still stand out because they exist within a heavily stylized, off-balance frame. The overall effect is drastically different from the theme in the previous exercise.


This process was very useful for me, and I’d love to see if it’s useful for the rest of the community as well. You can download and contribute to the Sketch files here:

https://github.com/Automattic/gutenberg-themes-sketch

The repository includes a basic Sketch file with just the symbols, plus all the text hierarchy styles (H1, H2, etc). I also created a library file in case that’s preferable for anyone. We hope to update these files periodically, and would love to hear feedback from others who use them.

In the meantime, we’ll keep experimenting with ways to design themes in this new Gutenberg-based future.