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:

A schema for Gutenberg blocks

At Jetpack we recently created a new Gutenberg block which displays “Related Posts”. This block is similar in content to the “Latest Posts” block in WordPress.org; it’s just a list of posts. The difference is the way the posts are displayed:

There are plans afoot to update the “Latest Posts” block, so that it contains an image and a post summary (see image below).

As these two blocks grow they seem to be converging on similar layouts, but with different content.

There are similar overlaps with other blocks. For example the layout of the WordPress.org gallery block could also be used to display a list of posts, as could the recently launched Tiled Gallery block. Evidently there are many layout possibilities for a list of posts!

The problem

As the number of Gutenberg blocks grows these overlaps become more obvious. As we start to build pages with Gutenberg it starts to become apparent that this is going to get very messy very quickly.

Essentially blocks have a content and a presentation element. Taking the example we began with, we can see overlap between many different types of content:

Lists of content

One type of content is a list of text, images and links. These come in many different forms, but they share the same structure:

  • Latest posts
  • List of posts in a category
  • List of post in a tag
  • Archive of posts by month/year etc
  • List of categories/tags
  • List featured posts
  • List of images
  • List of authors
  • List of [custom post type]

Similarly, all of the above types of content could be displayed in any of the following ways:

Layouts

Here are some examples of the different types of layout that this content could use:

The challenge is that each of these different types content can be displayed in each of these different layouts. If we wanted to create blocks for each of these combinations we’d end up with over a hundred different blocks. On the other hand we could build one single block which was so complex that it could display all these combinations within one block. Neither of these would be sensible solutions.

Can we use Block Style Variations?

Block Style Variations offer an API which allows us to modify the CSS for a block – they let us overlay a presentation layer on top of an existing block. This is ideal when modifying the way a block looks. However many of the layout variations I have examined above require more than just a different CSS, they need different markup and additional JavaScript.

Separating Content and Presentation

One solution to this problem could be to separate content from presentation in our blocks. What if we were able to define semantics for the content in our blocks, which could be interpreted by different layouts? This would mean users would first think about the content they wanted to show, and then all display options would be open to them.

A Shared Data Structure

The overlap between these blocks occurs because they all share the same data structure (an array of text, image and link). It would be possible to define a standard data structure that blocks can use. When blocks share a data structure, then it should be possible for them to share common layouts. This would mean a photo gallery display could be reused to display a list of posts, or a block that displays a list of recent posts could be reused to show a list of authors.

How Could this work?

“Block Transformations” are an existing mechanism which converts one block into another. At present every transformation has to be coded separately.

Could we re-imagine the way that transformations work, so that if blocks share a common data-structure, they can easily be transformed into each other, without writing custom transformation code?

Similarly, could we make changes to the way “Block Style Variations” work, so that they can apply a layout to our structured data?

Feedback

What do you think? Is this a problem? Are there other solutions I haven’t considered? Leave a comment!