Hacking on microformats and Gutenberg at IndieWebCamp East Online 2020, day 2

Today is day 2 of IndieWebCamp East Online 2020, a general hack/create day.

I’m hacking on microformats and implementing them in Gutenberg, which means I’m thinking in blocks.

Main personal inspirations for this include:

• I write a frequent week’s end series that is composed mostly of individual thoughts or notes. I can imagine a future where someone (me) could link or reply directly to a thought rather than the entire thing. Doing this means that each unique thought likely deserves to be its own h-entry.
• I want to reply to others’ posts via webmentions. Having a block or pattern dedicated to this would be nice.
• Yesterday’s conversation during the IndieWebCamp session gave me some initial sparks into how this may all work in the future.

As I somewhat mentioned in yesterday’s wrap-up post, a default pattern for WordPress themes has been to do something like this:

<article <?php post_class(); ?>>
    // header info

    <div class="entry-content">
        <?php the_content(); ?>
    </div>
</article>

The post_class() function outputs a handful of classes for the article wrapper. WordPress includes hentry with this by default, a property of the first microformats version that indicates a general container for the content of an entry.

The block editor allows for a much greater level of content flexibility, which makes specific markup like this less likely to be appropriate.

I decided my initial workaround would generally be this:

if ( has_block( 'mfblocks/h-entry' ) ) {
	$has_h_entry = true;
} else {
	$has_h_entry = false;
}
?>

<?php if ( $has_entry ) : ?>
    <div class="entries-content-wrapper">
<?php else: ?>
    <article <?php post_class(); ?>>
<?php endif; ?>

If my h-entry block is detected, I can assume that the post content itself will take care of describing entries with microformats. If not, then markup the page as normal. I’ll of course screw something up with my CSS here, but I’ll get to it at some point. I’m going to use the same logic to determine if an entry header should be output in a single template.

And! In reality, I’ll create a content-has-h-entry.php or something that I’ll use for this markup rather than having a bunch of if clauses making it all annoying to work with. 🙂

Okay, my theme is now wired up to handle what I want to do. Now, for some blocks!

My initial impression as I’m starting to plan this out is that WYSIWG is fun in theory, but it’s also nice to have an awareness of the structure of the document.

Gutenberg has a list view that shows you the outline of the current document. I’d kind of like this in a static place so that I don’t lose track of my nested nested group blocks. I imagine this will become an experience problem that is more and more obvious as we get closer to full site editing.

Having some contextual awareness during editing—which group is this block a part of?—will become more important in the future.

I started off the day with a couple custom blocks that implemented h-entry and e-content as wrapping containers of Gutenberg’s <InnerBlocks> component. I figured I could create block patterns that started with those groups and allowed someone to fill in the blanks.

Two problems:

• Discoverability. Adding one of my patterns means taking the mouse up to the + icon, clicking, clicking, clicking to find the right category and pattern that I want to use. It would be so great if I could insert a block pattern with the / command like I do with blocks.
• I could spend so much time trying to setup placeholder content that has the right microformat class names, but there’s nothing built into the pattern to keep that structure strict. An accidental keystroke removes the e-content section and then I have to start over.

So, I switched strategies and started building out a custom h-entry block that dictated the structure. This ends up being more opinionated, but we do have a general spec to follow.

Fast-forward as I started hacking away and stopped keeping notes. 🙂

I now have a repository setup for Microformat Blocks, a plugin for WordPress that provides an h-entry block along with a structure that supports a handful of other microformat properties:

• p-name
• p-summary
• e-content
• dt-published

I’m really close on having author implemented, hopefully in the next few days. I’ll also find an initial way of handling in-reply-to. And I’ll also get it up on the WordPress plugin repo.

But! The day is over and I’m really hungry.

Gutenberg aside: I want to implement in-reply-to on specific anchor tags rather than create a whole custom input control for it. Another case where it would be nice to register custom inline blocks.

Some leftover notes:

• Trying to think through the concept of authorship on a page of thoughts/notes. Will a microformat compatible reader infer authorship from a page level h-card or does u-author need to be included with each distinct entry?
• I wonder if I can implement indie-auth comments in a way where someone can write a comment or annotation on my site and have it published back to their site?
• How does the current WP webmention implementation handle my new block configuration?
• Once I have dt-published actually setup for multiple entries on my site, it would be cool to sort h-entries in a thought post by date, ASC or DESC

That’s that. I had an excellent time this weekend geeking out on IndieWeb. Big thanks to Chris Aldrich and David Shanske for organizing!