HFeed should Only Appear on Archive Pages

[dshanske]

See _s Automattic/_s#743

HFeed indicates a page where multiple hentrys exist. It should not appear on any single page.

[karmatosed]

This hasn't been merged into _s yet. I'm not totally sure we should merge this here.

[dshanske]

I'm still unsure what stopped it.

[karmatosed]

I'm going to flag this for discussion in this week's meeting. I feel we shoudn't bring this in yet, but that's not to say we won't. I think it's something we need to get opinions on.

[karmatosed]

Noting this is flagged for discussion in the next meeting: Friday 16:00 UTC in #core-themes.

[karmatosed]

In order to give this proper consideration we really need to know why this is a good idea and why in the way it's been done. We're not saying either way as a call, we just need to know all the facts.

[dshanske]

Basically, a feed is multiple items. Therefore it would not apply on single pages. In the context of the microformats specification an hfeed is a page with multiple hentrys.

[dshanske]

To put it another way, on a single post, hentry is the top level element. On an index/archive page, hfeed would be.

[ihorvorotnov]

I'm not good in microformats, so I did some research to learn it. According to spec, @dshanske is correct.

h-feed is a microformats2 draft for marking up a stream or feed of h-entry posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts.

h-feed is the microformats2 update to hAtom's "hfeed".

While I couldn't find similar statement for hfeed (not h-feed), if you check code examples, they follow the same concept. Same is explained by those working on specs in many discussions over the internet. As for microformats2, it's exactly "h-feed containing h-entry * X".

[ianstewart]

My two cents on microformats changes:

• Does it appear to meet the spec? If yes: Great!
• Does a validator validate it? If yes: Great! http://microformats.org/wiki/validators
• Does it break anything to make a change? If no: Great! (People use them for styling hooks so tough in old themes.)

[dshanske]

Wonder if I should propose adding microformats2 to the theme.

[karmatosed]

This was discussed in this week's chat. We have a merge window and the PR is now out of date. Thanks for all your input and lets focus efforts on _s for now.

[mtomas7]

@dshanske Perhaps you have a code example how to implement microformats v2 via theme's functions.php? Thank you!

[dshanske]

http://microformats.org/wiki/h-entry

Add h-feed and h-entry where you have hfeed and hentry.

The rest would be in the static markup. I could see about a Pull Request.

[mtomas7]

Thank you!

I also found this good example:

https://github.com/pfefferle/SemPress/blob/master/sempress/inc/semantics.php

I like it because it would not change static theme files in case formats would change.

[dshanske]

I'm familiar with @pfefferle. I've contributed to a bunch of things he's done. But using functions would work for formats that go on comment_class, post_class, or body_class. But we don't have anything like content-class or such, so it isn't possible at that level.

[mtomas7]

I see, I will try to insert it via custom function how I did with schema.org for article, then everything could be in functions.php, or is it not very good way?

<article id="post-<?php the_ID(); ?>" <?php post_class(); ?> <?php tinyframework_article_tag_schema(); ?>>

[dshanske]

https://github.com/dshanske/wp-semantics

I was experimenting with this idea a while back as well.

[mtomas7]

Right! I started working on it when I got client to build auto sales related site, then I understood that I will have manually change many schema.org tags, then I started to move everything to functions.php :)

[dshanske]

https://core.trac.wordpress.org/ticket/32326

I had proposed this be something in core, so that any arbitrary markup could be added by plugin, and just supported by the theme.

[dshanske]

Specifically about Microformats, Microformats implementation in WordPress was improperly done by many themes, and that was copied over and over so it spread around a large percentage of sites. At the least, twentysixteen will now fix that.

The question about Microformats2 is that it is a refinement of the original markup. For example, class microformats used entry-title to indicate the title of an hentry. Microformats2 uses p-name, which is also used as the name in an h-card, h-event, or other microformat structures. There was no need to have another property. More like that.

[mtomas7]

I will try to combine @pfefferle and your approaches into functions.php, but I do not expect anything similar landing in Underscores, as it is pretty stagnant in this area.

I just do not understand why @pfefferle uses this declaration, does it change anything in real life?

  /**
   * Draw attention to supported WebSemantics
   */
  add_theme_support( 'microformats2' );
  add_theme_support( 'microformats' );
  add_theme_support( 'microdata' );

Default WP themes do not declare it.

[dshanske]

It was my suggestion. The idea being an arbitrary way to tell a plugin you were compliant with a markup standard.

[mtomas7]

It would be good if these things would be standardized by WP community, so many could use the support for features that are not included in the core yet.

[dshanske]

Feel free to throw your support behind https://core.trac.wordpress.org/ticket/30783.