Built-in, optional support for microformats2?

[reinhart1010]

I'm forwarding this issue from WordPress/twentytwentytwo#78 which was closed 3 days ago. Here's what the original report says:

microformats and microformats2 have existed for such a long time (first in 2005), and some people are still using it to allow their sites to be (semantically) discoverable by anyone.

My idea here is to sidechain a set of microformats2 class markups into the current set of WordPress-specific or theme-specific classes, like .e-content alongside .entry-content (as in the Twenty Twenty One theme), .h-card with a[rel="author"], .p-category alongside a[rel="category"] and a[rel="tag"]and so on.

I know that this would be redundant for such a theme, and not all site authors want their site to be discovered this way (i.e. by using microformats2), so I think it could be better to leave this as an optional feature, opt-in from the Customize menu that people have been familiar with.

At least it's better than using a WordPress plugin which apparently breaks in some themes due to HTML string sanitation, including Twenty Twenty One.

[aristath]

My 2 cents (personal opinion):

Any schema (whether that's microformats, RDFa or JSON-LD) should be done taking the whole page into account, holistically. Doing it on a per-block basis and adding stuff left and right without knowing the final result can't possibly be a good thing. It would be better not to have anything than to have something potentially wrong.

WordPress themes were (in the past) printing a lot of microformats markup, and that has contributed to a lot of noise and sites using the wrong microformats (or at least not something actually meaningful). In the past things like that have done more harm than good in many cases, so if we do something it should be done properly and not using quick-fixes that may or may not be 100% correct.

[jonoalderson]

Seconded.

Whilst I love the idea of Gutenberg blocks providing rich, semantic metadata, this feels like it opens up a can of worms and comes with some risk.

Some additional considerations:

• microformats (and microformats2) have little adoption (across both publishers and consumers), and are somewhat outdated. If we're going to go down this route, we should bet on schema.org (via microdata, or better yet JSON-LD)
• In isolation, simple markup of content, sections and authors does very little. To describe the content meaningfully, you need a much richer graph of descriptors
• From our experience building a rich structured data solution into Yoast SEO, you quickly find that each individual block/element/entity needs the context of the whole page, and, the page needs the context of all the blocks it contains. It's not uncommon for the presence of a given block to transform page-level attributes and vice versa.