The Publishing Project

Revisiting multi-column text

This set of features related to multi-column text is near and dear to my heart. I first researched this feature when I wrote about it for the Web Platform Documentation Project (since retired). The idea is to let the browser take care of creating the columns and the details about the columns, the gap, and other elements. We can also play with headers and how they span across the columns. Browser support, as always, is the stumbling block for using columns across browsers but it appears to be better than when I first tried it. I searched caniuse.com for column-

Using gulp-libsquoosh to replace Imagemin

All my Javascript projects include imagemin, a tool that allows you to convert images between different formats and do some level of processing to the images as it converts them. Unfortunately, the project is in life support mode and the original maintainer stopped working on it years ago according to the pinned issue in the repository issue tracker. So it’s time to take a look at the alternatives and see how well they work in a Gulp-based Javascript project. Squoosh is an image compression and manipulation tool. The main difference between Squoosh and Imagemin is that Squoosh has created WebAssembly

Creating epub3 content.opf file

One of the hardest files in an epub book is the content.opf manifest file. This file tells an epub reader what files are in a specific rendition of an ebook. There are three components to a content.opf file: Metadata Provides information about the book using a combination of meta tags and Dublin Core metadata elements The normative reference is in the EPUB 3.2 package specification metadata section Manifest The manifest element provides an exhaustive list of the Publication Resources that constitute the given Rendition, including the media type, the file path and the media encoding See the Manifest section of

Plugin Topics: JSON Block Configuration

Starting in WordPress 5.8, there is a JSON metadata file we can use to register blocks. The block.json file is the block-level equivalent to theme.json and is now the preferred way to register blocks. The following example contains a block.json definition for a fictional my-plugin/notice block. { “apiVersion”: 2, “name”: “my-plugin/notice”, “title”: “Notice”, “category”: “text”, “parent”: [ “core/group” ], “icon”: “star”, “description”: “Shows warning, error or success notices…”, “keywords”: [ “alert”, “message” ], “version”: “1.0.3”, “textdomain”: “my-plugin”, “attributes”: { “message”: { “type”: “string”, “source”: “html”, “selector”: “.message” } }, “providesContext”: { “my-plugin/message”: “message” }, “usesContext”: [ “groupId” ], “supports”: {

Plugin Topics: Meta boxes in the Block Editor

Meta boxes work in Gutenberg but they may not do so for a while or be the best solution for your needs. During the full migration to the Block Editor, WordPress Provides two compatibility flags. Most of the time the compatibility setup works out of the box. However, you must test the meta boxes on Gutenberg to make sure the code will still work and that you won’t need to write new blocks to handle the meta box data. You also need to modify the add_meta_box() function to look like the example that follows: <?php function rivendellweb_custom_meta() { add_meta_box( ‘rivendellweb_meta’,