[Recipe] shortcode: add additional microformats support (v1 and v2)

[chrisaldrich]

Steps to reproduce the issue

The current [recipe] shortcode appears to only support the 'hrecipe' class in microformats1

What I expected

I would have expected the additional dozen or so classes in hrecipe to be supported, or better yet, that it would have also supported the newer microformats2 h-recipe spec in parallel.

I'm anything but a github expert, but I took a crack at adding the additional classes (for both mf1 and mf2) on a forked branch, which also includes some additional detail: https://github.com/chrisaldrich/jetpack/pull/1/commits/f914ebe3bd573d1d6d42c5b7752bf26c41448a3b

I've got a copy of this patch running on a site with a recipe at: http://boffosocko.com/2016/07/17/chili-prep-for-dinner-tonight/

[jeherve]

We've opted to use Schema.org instead of microformats in other areas of Jetpack. It might be to follow a similar approach for the Recipe shortcode: https://schema.org/Recipe

Edit: I forgot we already added Schema.org markup to Recipes as well. :)

Do you think we should support both formats? Schema.org is used by search engines like Google, Bing, or Yahoo!, so it seems more relevant to me.

[chrisaldrich]

tl;dr: It's easy enough to support microformats v2 (and even backcompat for v1) and they don't/shouldn't create any conflicts so why not support them out of the box?

I think that a forward-looking platform like Automattic should definitely be supporting (and perhaps even iterating internally) on microformats2, particularly since they're simple added classes that give semantic meaning to the massive amounts of data that are put on the web via the platform. This makes them much more valuable to end users of the web (and doesn't mean they're simply a cut-and-dried SEO tool for Google's benefit.)

Though schema and microformats are meant for the same types of general functionality, their implementations and pros/cons are different. In part, Google controls the schema structure while microformats are more open and extensible, particularly if/when additional classes seem necessary in the wild. Additionally, Google, et al. certainly don't ding sites that use one or the other or even both.

I also know there were a few plugins in the repository that used to support microformats v1 that aren't actively supported anymore (see https://wordpress.org/plugins/hrecipe/ for example with an install base of 600+). Since a plugin really isn't required to add support, putting it into the canonical end-all shortcode for recipes on WordPress is probably the easiest thing for wide-based support.

Kevin Marks does a pretty good job of laying out microformats vs. schema here: http://www.kevinmarks.com/microformatschema.html. Because of the ease of use of microformats2, back in May Kevin was able to build a quick parser to inject mf2 into their site to attempt to save the BBC's Food & Recipe database (http://www.bbc.co.uk/food/recipes/) when they announced they might discontinue it and take it offline. (See: https://twitter.com/kevinmarks/status/732586363128664064; https://twitter.com/kevinmarks/status/733115448410116097)

Amy Guy, part of the W3C Team and co-staff contact for the Social Web working group, also has some useful thoughts on the benefits of microformats (and comparison with linked data) as well: http://rhiaro.co.uk/2015/08/extensibility

I'm doing some parsing related work on my suggested (pending) pull request to make sure that parsers will properly read the recipe data. It may require a tweak or two prior to pulling.

Additional References: http://tlks.io/talk/microformats-with-tantek-celik http://programmers.stackexchange.com/questions/166612/schema-org-vs-microformats

[kraftbj]

@chrisaldrich That all makes sense to me. I don't see a downside to doing both. I can't say if/when we'd get to it since it isn't high-priority, but I'd support inclusion of a PR on it.

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.