I was recently playing around with this again. I noticed that in bookmarks (and possibly some other types) that including an author URL doesn't wrap the author(s) names with an <code>`&lt;a class="microformats here" href="authorwebsite.com">Author name&lt;/a>`</code> as one might expect as a part of their h-card.

Was this a conscious choice (in case there were multiple authors)? Or just overlooked?

@cosenalgo @michael_nielsen If I remember, @kevinmarks did some work last year on BBC recipe collection w/ microformats semantic markup too

@keithjgrant That seems like the type of thing that your book "promises" and could help differentiate it from the host of others. I'd love to see a book on CSS cover things like microformats for the future.

@keithjgrant That's a well worded synopsis. Welcome to the IndieWeb!

I'm curious if, as a CSS expert--which I am assuredly not, your book has a section that differentiates "semantic" and "styling" classes? One of the quirks I've run into while playing in the Indieweb is that some designers use microformat classes (like hentry/h-entry, e-content, etc.) to style their pages rather than simply allowing them to be used for semantic mark up and instead relying on secondary classes for styling. I've seen many instances, particularly within the WordPress and Drupal communities, where themes (including heavily used template themes--_s, I'm looking at you!) rely on styling using microformats or other semantic classes and this tends to cause problems with decentralization to opening up the web to movements like Indieweb. I have a feeling if more developers were educated about this "quirk" that large swaths of the internet (WordPress apparently runs 25% of the web) would be more easily/automatically converted/upgraded to support the decentralized web. Thoughts?

@Chronotope I'd be curious about ones which also (or separately) support microformats v1 or v2. #indieweb

As a supplementary note, JetPack v4.5 now includes a Gravatar widget which functions a lot like the H-card Widget and pulls in data from the user's profile as well as their Gravatar account. Now, if only it had microformats...

Since the code and UI may be worth looking at: https://github.com/Automattic/jetpack/tree/master/modules/widgets

Announcement: https://jetpack.com/2017/01/17/jetpack-4-5-monetize-your-site-brand-new-videopress-and-many-many-new-shortcodes/

Jeremy, Like you, I had some of the same issues and questions when I first started. I'd had a primary website for a while that was a bit more blog-ish on WordPress with a few other subsidiary sites for work related things. When I got into IndieWeb, WithKnown had a great plug-and play set up for almost everything, so for me, it made a nice easy place to start. I also wanted to play with Known and use it to get my feet wet. I was particularly interested in owning a lot of the shorter form posting/microblogging like Twitter without overwhelming my prior subscribers on my WordPress blog with a lot of shorter "fluff". Once I'd gotten a few things working, Known was also incredibly good at quick short posts using bookmarklets (or this mobile solution I'd come up with: http://stream.boffosocko.com/2016/sharing-from-the-indieweb-on-mobile-android-with-apps-and ). Initially the big difference between my sites was where I stored longer form content and shorter form.

Slowly over time, as I've been adding bits and pieces here and there to my WordPress set up, it has been owning more and more while somewhat less lives on my Known Install. There's also been a huge amount of community development on the WordPress side, so that it's tremendously better now than it was when I started and continues to grow. I think I hit a bigger turning point after IndieWebCamp LA when I was able to work out a bit more about how I want to own and syndicate things from my primary hub (on WordPress). (See also: http://boffosocko.com/2016/12/18/rss-feeds-a-follow-up-on-my-indieweb-commitment-2017/ which has some thoughts about adding RSS feeds from one site to cover multiple other sites). The nice part about owning your own site is that you get to figure out what to do with it and you can literally do almost anything. For example, very shortly I'm about to attempt to own all of my checkins on my WordPress site instead of on Known as I've got almost all the moving pieces to do it in a way I like.

Ultimately, I'd recommend doing what works best for you at the moment as there are literally hundreds/thousands of ways to pull it off. Do things one at a time in small bite-sized chunks until you have it the way you want it. There's no reason to do everything all at once. Sometimes I've found that creating posts literally by hand in raw html has been a great way to start to see both how it looks/works, and then use that experience to figure out how to best/most easily automate it going forward.

I'll also note that my coding skills were old and rusty and have been slowly getting better over time as each piece evolves. Another nice part of the process is that you'll have a chance to see how others are doing things with examples from the wiki to help you figure out what might work best for you. Over the process I've also seen others stop, change gears, and even platforms, and try out something totally different. The key seems to be to start with something you know and begin working from there based on your particular "itches" and needs [http://indieweb.org/itches]. Document in the wiki pages what works for you and what doesn't and why to help others along the way. What works for you won't necessarily be the best solution for others and vice-versa, but there's lots of examples out there to work off of.

Your post was certainly a good start for taking stock of what you've got and where you might like to go. Now just make a list of your itches and do things a step at a time. I know there's an IndieWeb Cat [https://indiewebcat.com/] and an IndieWeb Library [http://boffosocko.com/2016/07/16/the-indieweb-ified-library/], so I'm glad to think that there might be some IndieWeb bread out there soon too. (This reminds me that I want to get back to microformats for recipes again in relation to JetPack's shortcode work: https://jetpack.com/support/shortcode-embeds/).

Good luck!

I am using uf2 to add microformats, so I thought it could be the case that that is causing a parsing issue (potentially with Jetpack's "Related" plugin, which could be the source for content from another post), but this doesn't seem to be the cause from what I can tell.

Any other particular guesses?

You're probably correct and it generally won't cause too many issues. Except for when I figure out how to break things in new and creative ways... ;)

But for most themes, it also means that there's a lot of additional cruft that could accidentally be sucked in by parsers: header images, menu items, etc. as well as additional body elements below the content, including the comments, footer, widgets, other plugins, etc. Having it canonically further into the structure narrows down the scope of things that could potentially go wrong, particularly as it gets tested in a growing circle of themes that will eventually use it.

Some of it comes down to what one should expect h-entry to contain versus what one should expect e-content to contain just after it. Where do most themes put author information for the author h-card? You'd want h-entry to contain that as well as the publish time and other meta data too.

The other issue to possibly consider in terms of conflicts is how non-compliant themes which style on the older hentry (or other microformats) may behave/misbehave going forward. These may be lost causes, but could they potentially be "fixed" by injecting h-entry further down? If newer parsers look for mf2 over mf1, then not including hentry (presumably a second time) and injecting h-entry into the correct spot would override the potential error.

I ultimately defer to your better judgment...

Thanks everyone for taking a look and for the help!

Apologies if I offended anyone -- without having read through any of the brid.gy code, I wasn't quite sure what was going on. My suspicion for a while has been that using the [uf2 plugin](https://github.com/pfefferle/wordpress-uf2/) for WordPress certainly isn't quite always the best, though it's fairly impressive what it **will** allow. I've been hacking around at a new/different theme that adds microformats directly rather than programmatically to have greater control of exactly where they're put, but it's also a one-off solution rather than a solution for the masses. Better microformats injection into themes is certainly a small stumbling block for coming generations.

I was previously aware that the entry-content div on my theme overextended itself (https://github.com/WordPress/twentysixteen/issues/470), but didn't realize that the hentry/h-entry was being injected too early via uf2.

I saw some of the resulting discussion in the #indieweb-dev channel, so I'm glad my beastly banging on and breaking of things may help improve things for coming generations. ;)

@dshanske We should remember to ping the Independent Publisher theme if you decide to make changes, as I suspect it'll have the same issue(s). It's been a while since I looked at the code for it, but I recall he created a mf2.php in the theme to inject microformats similarly to uf2 or one of your recent blogposts.

Sounds like a reasonable solution. I'd imagine that in most cases (to be safe) that if there's not a featured image, then posts to twitter would generally be just the text update as that's how most people typically use twitter.

Is it looking for photo related microformats with regard to identifying/pulling photos? I actually thought it was interesting/relatively nice that it automatically pulled the three photos and laid them out that way, but in that case I'd have done higher res photos for better clarity. The "indieweb mini-logo" is a really small icon way down in the footer of my page and I was most shocked that it popped up on the post.

I typically have been using SNAP for POSSE, but as I've been watching your work recently, I felt compelled to test out Bridgy Publish to give you some feedback about UX/UI as well as bang on things for bugs in general.

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 Auttomatic 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

[Recipe] shortcode: add additional microformats support (v1 and v2) · Issue #4470 · Automattic/jetpack https://github.com/Automattic/jetpack/issues/4470

#### Steps to reproduce the issue
The current [recipe] shortcode appears to _only_ support the '[hrecipe](http://microformats.org/wiki/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](http://microformats.org/wiki/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/