h-entry is currently on body instead of <article>

[chrisaldrich]

See discussion at https://github.com/snarfed/bridgy/issues/691 for details

[dshanske]

As far as I can tell, there is nothing inherently wrong with it being on body, depending on the structure of the page

[chrisaldrich]

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

[dshanske]

I would say, the best argument so far is that WordPress puts hentry on post_class, and to ensure consistency, h-entry should always be on post_class, not in body_class.

[pfefferle]

With h-entry and hentry on the post_class you limit the flexibility of the plugin. You will not be able to do something as reply-context or similar things, that have to be inside the h-card container.

[voxpelli]

To avoid both the mf1 and the mf2 entries to be parsed the two classes should be on the same tag. The microformats 2 parsing algorithm then dictates that the mf2 class will replace the mf1 class: http://microformats.org/wiki/microformats2-parsing#parse_an_element_for_class_microformats

So always applying the mf2 h-* class to its mf1 equivalent is needed if one wants to replace the mf1 equivalent from a semantic/mf2 point of view, and not removing the mf1 class from the theme is needed to not break any CSS or JS that relies of the mf1 class.

[dshanske]

But they can't if it applies hentry improperly.

[voxpelli]

@dshanske My impression is that they don't apply it improperly, but rather sub-optimally? So that a better markup with more features can be had if the h-entry is added elsewhere, but that maximum compatibility can be achieved if it's added in the same place so that the hentry doesn't need to be removed. Or am I missing something? To me it looks like the existing hentry is valid, just outdated?

[dshanske]

My proposal was that we add a theme support flag to address.

[voxpelli]

I was thinking maybe a plugin option, if one wants to support both a compatibility mode and a feature rich mode, and have the module scale down or up accordingly.

[pfefferle]

The problem is, that I add both, the h-entry and the hentry, to the body instead of the article, to be more flexible with other IndieWeb techs, like reply-context. But moving the hentry to the body element breaks some themes.

[pfefferle]

I like the idea to make that feature configurable via a filter and/or const...