Closed dshanske closed 8 years ago
This hasn't been merged into _s yet. I'm not totally sure we should merge this here.
I'm still unsure what stopped it.
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.
Noting this is flagged for discussion in the next meeting: Friday 16:00 UTC in #core-themes.
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.
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.
To put it another way, on a single post, hentry is the top level element. On an index/archive page, hfeed would be.
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".
My two cents on microformats changes:
Wonder if I should propose adding microformats2 to the theme.
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.
@dshanske Perhaps you have a code example how to implement microformats v2 via theme's functions.php? Thank you!
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.
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.
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.
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(); ?>>
https://github.com/dshanske/wp-semantics
I was experimenting with this idea a while back as well.
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 :)
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.
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.
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.
It was my suggestion. The idea being an arbitrary way to tell a plugin you were compliant with a markup standard.
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.
Feel free to throw your support behind https://core.trac.wordpress.org/ticket/30783.
See _s https://github.com/Automattic/_s/pull/743
HFeed indicates a page where multiple hentrys exist. It should not appear on any single page.