Clove: A Showcase of Block Patterns by Anariel Design

Category Image 091
Clove theme homepage.

Earlier today, Ana Segota tweeted and announced via the Anariel Design blog that her company had submitted its second block-based theme to WordPress.org. Clove is a more well-rounded follow-up to her first such theme, Naledi. It is currently under review for inclusion in the official directory, but anyone can give it a test run by snagging the ZIP file from its ticket. Or, just peruse the live demo.

This should officially be the 10th block-based theme to go live in the WordPress.org theme directory (note that a couple by Automattic are not tagged). That is assuming all goes well during the review process.

It has been a long road thus far, but 10 themes with the Full Site Editing tag is a notable milestone. The Q theme by Ari Stathopoulos was the first to land in the directory back in October 2020. Now, eight months later, there is still room for other theme authors to become pioneers in the space. With almost no competition, who will design that first block theme that squeezes its way into the most popular list?

If “practice makes perfect,” Segota is now ahead of the curve by pushing her second theme to the directory. This makes her theme company only one of two with multiple block themes.

Clove is experimental, as all block themes are. It relies on the ever-shifting parts of the Gutenberg plugin, but it all comes together into a floral, nature-themed design. There are hints of inspiration from Twenty Twenty-One, but it feels more structured, less chaotic.

The design is less of a theme and more of a showcase of block patterns and styles. Even on the template level, it reuses those same elements across each of its seven templates, providing multiple entryways for users to tinker with its features.

Clove even includes pricing columns. I seem to recall writing about how theme authors could implement them via patterns just over a month ago. Maybe the Anariel Design team came to the same conclusion. Maybe they took my message and ran with it. I like to think the latter is true. Either way, the result is a beautiful, theme-specific pattern — the sort of artistry that is tough to achieve from a plugin.

Nature-themed pricing columns block from the Clove WordPress theme.
Customizing the Pricing Columns pattern in the WordPress editor.

I am less of the fan of the overlapping and uneven columns in some of the designs designs, preferring some of the more-structured patterns, such as Three Quotes Images:

Three columns of images plus quotes, a pattern from the Clove WordPress theme.
Three-column pattern that showcases images along with quotes.

Despite my general dislike of the uneven column style, my favorite piece of the entire theme is the Illustrations page template, which leans into that design method.

The page intro section is an announcement to the world, “Hey, check out my work.”

Page intro section with uneven columns and two nature-based images.
Illustrations template intro section.

I also like the Illustrations page template’s widgets-like area in the footer. It manages to stuff several blocks in without feeling too crowded. It even showcases a box for artists to highlight their next exhibition.

Three columns of blocks that appears like a traditional footer widget area.
Illustrations page template footer “widget” area.

The Clove theme also registers 10 block styles for users to choose from. Most of them add different types of borders or frames to various elements. Plus, there is the fun-but-kind-of-an-oddball blob “Shape” for images.

Segota was one of several people to submit custom designs to the upcoming block pattern directory. There is some noticeable crossover between her current theme work and submissions, such as the Playful Gallery pattern that did not quite make the cut. Others, like her Recipe design, did. There is still an open invitation for people to contribute.

I am always like a kid in a toy store when a new block theme comes along, reaching out to grab the latest gadget. I want to see more experiments like Clove. Keep them coming, theme authors.

Side note: For people interested in the background-clipped text design used in Clove’s site logo, I opened a ticket to take us one step closer to doing it in the editor. Currently, users must create an off-site image and upload it.

TablesNG — Improvements to table rendering in Chromium

Category Image 091

When I blogged “Making Tables With Sticky Header and Footers Got a Bit Easier” recently, I mentioned that the “stickiness” improvement was just one of the features that got better for <table>s in Chrome as part of the TablesNG upgrade. I ain’t the only one who’s stoked about it.

But Bramus took it the rest of the nine yards and looked at all of the table enhancements. Every one of these is great. The kind of thing that makes CSS ever-so-slightly less frustrating.

Just the writing-mode stuff is fantastic.

Direct Link to ArticlePermalink


The post TablesNG — Improvements to table rendering in Chromium appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Using Performant Next-Gen Images in CSS with image-set

Category Image 091

The CSS image-set() function has been supported in Chromium-based browsers since 2012 and in Safari since version 6. Support recently landed in Firefox 88. Let’s dive in and see what we can and can’t do today with image-set().

Multiple resolutions of the same image

Here’s what the CSS spec has to say about image-set():

Delivering the most appropriate image resolution for a user’s device can be a difficult task. Ideally, images should be in the same resolution as the device they’re being viewed in, which can vary between users. However, other factors can factor into the decision of which image to send; for example, if the user is on a slow mobile connection, they may prefer to receive lower-res images rather than waiting for a large proper-res image to load.

It’s basically a CSS background equivalent to the HTML srcset attribute for img tags. By using image-set we can provide multiple resolutions of an image and trust the browser to make the best decision about which one to use. This can be used to specify a value for three different CSS properties: content, cursor, and most useful of all, background-image.

.hero {
  background-image: image-set("platypus.png" 1x, "platypus-2x.png" 2x);
}

1x is used to identify the low-res image, while 2x is used to define the high-res image. x is an alias of dppx, which stands for dots per pixel unit.

Chrome/Edge/Opera/Samsung Internet currently require a -webkit- prefix. If you’re using Autoprefixer, this will be handled automatically. Safari no longer requires the prefix but uses an older syntax that requires a url() function to specify the image path. We could also include a regular old background-image: url() to support any browsers that don’t support image-set.

.hero {
  /* Fallback */
  background-image: url("platypus.png");

  /* Chrome/Edge/Opera/Samsung, Safari will fallback to this as well */
  background-image: -webkit-image-set(url("platypus.png") 1x, url("platypus-2x.png") 2x);

  /* Standard use */
  background-image: image-set("platypus.png" 1x, "platypus-2x.png" 2x);
}

Now users on expensive fancy devices will see a super sharp image. Performance will be improved for users on slow connections or with cheaper screens as their browser will automatically request the lower-res image. If you wanted to be sure that the high-res image was used on high-res devices, even on slow connections, you could make use of the min-resolution media query instead of image-set. For more on serving sharp images to high density screens, check out Jake Archibald’s recent post over on his blog.

That’s pretty cool, but what I really want is to be able to adopt the latest image formats in CSS while still catering for older browsers…

New image formats

Safari 14 shipped support for WebP. It was the final modern browser to do so which means the image format is now supported everywhere (except Internet Explorer). WebP is useful in that it can make images that are often smaller than (but of the same quality as) JPG, PNG, or GIF.

There’s also a whole bunch of even newer image formats cropping up. AVIF images are shockingly tiny. Chrome, Opera and Samsung Internet have already shipped support for AVIF. It’s already in Firefox behind a flag. This image format isn’t supported by many design tools yet but you can convert images to AVIF using the Squoosh app built by the Chrome team at Google. WebP 2, HEIF and JPEG XL might also make it into browsers eventually. This is all rather exciting, but we want browsers that don’t support these newer formats to get some images. Fortunately image-set() has a syntax for that.

Using new image formats by specifying a type

Browser support note: The feature of image-set that I’m about to talk about currently has pretty terrible browser support. Currently it’s only supported in Firefox 89.

HTML has supported the <picture> element for years now.

<picture>
  <source srcset="./kitten.avif" type="image/avif">
  <img src="./kitten.jpg" alt="a small kitten"> 
</picture>

image-set provides the CSS equivalent, allowing for the use of next-gen image formats by specifying the image’s MIME type:

.div1 {
  background-image: image-set(
    "kitten.avif" type("image/avif"),
    "kitten.jpg" type("image/jpeg")
  );
}

The next-gen image goes first while the fallback image for older browsers goes second. Only one image will be downloaded. If the browser doesn’t support AVIF it will ignore it and only download the second image you specify. If AVIF is supported, the fallback image is ignored.

In the above example we used an AVIF image and provided a JPEG as a fallback, but the fallback could be any widely supported image format. Here’s an example using a PNG.

.div2 {
  background-image: image-set(
    "puppy.webp" type("image/webp"),
    "puppy.png" type("image/png")
  );
}

In Chromium and Safari, specifying the type is not supported yet. That means you can use image-set today only to specify different resolutions of widely-supported image formats but not to add backwards-compatibility when using WebP or AVIF in those browsers. It should be possible to provide both multiple resolutions and multiple image formats, if you are so inclined:

.div2 {
  background-image: image-set( 
    "puppy.webp" type("image/webp") 1x,
    "puppy2x.webp" type("image/webp") 2x,
    "puppy.png" type("image/png") 1x,
    "puppy2x.png" type("image/png") 2x
  );
}

Hopefully browser support will improve soon.

Using <picture> for backgrounds instead

Maybe you don’t need background-image at all. If you want to use modern image formats, you might be able to use the <picture> element, which has better browser support. If you set the image to position: absolute it’s easy to display other elements on top of it.

As an alternative approach to using position: absolute, CSS grid is another easy way to overlap HTML elements.


The post Using Performant Next-Gen Images in CSS with image-set appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

“Weak declaration”

Category Image 052

PPK looks at aspect-ratio, a CSS property for layout that, for the most part, does exactly what you would think it does. It’s getting more interesting as it’s behind a flag in Firefox and Safari now, so we’ll have universal support pretty darn soon. I liked how he called it a “weak declaration” which I’m fairly sure isn’t an official term but a good way to think about it.

This will produce a 16 / 9 element:

.movie-card {
  aspect-ratio: 16 / 9;
}

This will too:

.movie-card {
  width: 50%;
  aspect-ratio: 16 / 9;
}

But this won’t:

.movie-card {
  width: 150px;
  height: 150px;
  aspect-ratio: 16 / 9;
}

Because you’ve explicitly set the height and width, that is what will be respected. The aspect-ratio is weak in that it will never override a dimension that is set in any other way.

And it’s not just height and width, it could be max-height that takes effect, so maybe the element follows the Aspect ratio sometimes, but will always respect a max-* value and break the Aspect ratio if it has to.

It’s so weak that not only can other CSS break the Aspect ratio, but content inside the element can break it as well. For example, if you’ve got a ton of text inside an element where the height is only constrained by aspect-ratio, it actually won’t be constrained; the content will expand the element.

I think this is all… good. It feels intuitive. It feels like good default behavior that prevents unwanted side effects. If you really need to force an Aspect ratio on a box with content, the padding trick still works for that. This is just a much nicer syntax that replaces the safe ways of doing the padding trick.

PPK’s article gets into aspect-ratio behavior in flexbox and grid, which definitely has some gotchas. For example, if you are doing align-content: stretch;—that’s one of those things that can break an Aspect ratio. Like he said: weak declaration.


The post “Weak declaration” appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.