#30783 closed enhancement (wontfix)
Support Microformats 2
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | |
| Component: | Themes | Keywords: | has-patch close |
| Focuses: | Cc: |
Description
Microformats 2 is an updated, simplified version of Version 1. It's now stable and recommended for live sites and projects.
http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2
http://microformats.org/wiki/microformats2
mf2 is designed to make parsing of information more efficient, and could allow for improved behaviors without breaking backward compatibility, by making no changes to the microformats 1 implementation.
Attachments (1)
Change History (29)
#2
in reply to:
↑ 1
@
10 years ago
Replying to peterwilsoncc:
µFormats are mainly theme related. Some rough thoughts:
- enable with
add_theme_support( 'microformats2' );- enabling µF2 support indicates µF1 should be disabled by default
- enabling both could be desired as big-search currently only supports µF1
There is a repo showing default HTML classes that need to be targeted on Github.
You are correct it is mostly theme related, however, this is specifically about those areas generated by WordPress itself, which is a prerequisite for theme support adoption.
This ticket was mentioned in Slack in #core by nvartolomei. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by dshanske. View the logs.
9 years ago
#7
@
9 years ago
Since this is not something that is getting much buy-in, from what I can see, I'm thinking I will just do it myself.
Namely, I want to adopt the suggestion of an add_theme_support('microformats2') option which would add markup to all built-in WordPress functions that currently have mf1 markup, and possibly a few extra locations.
This ticket was mentioned in Slack in #core by dshanske. View the logs.
9 years ago
#11
follow-ups:
↓ 12
↓ 14
↓ 16
@
9 years ago
I'm cool with doing this, but I do have some questions, mostly around my lack of familiarity with microformats.
- How does microformats discovery work? Do we need to put something in the header?
- Is there a down side to ceasing microformats 1 support?
- Can we support microformats 1 and 2 simultaneously?
If we can get away without adding yet another theme option, I think that would be the vastly more preferable method.
#12
in reply to:
↑ 11
@
9 years ago
I guess main reason to keep everything in v2 format (except body) is the simplicity of the code:
<span class="vcard"><a class="fn n url" href="http://waterpigs.co.uk">Barnaby Walters</a></span>
With microformats 2 this all becomes much simpler:
<a class="h-card" href="http://waterpigs.co.uk">Barnaby Walters</a>
#13
follow-up:
↓ 15
@
9 years ago
Microformats creators say this:
Upgrading to microformats2
Upgrade sites
Second, if you publish any kind of semantic information, start upgrading your web pages to microformats2 across the board.
If you’re concerned about what search engines claim to support, there are two approaches to choose from:
Know that search engines are a trailing indicator, and as microformats2 usage grows, they’ll index it as well.
Or: Use one classic microformat (supported by all major search engines) at top of your page, e.g. on the <body>, in addition to your microformats2 markup throughout your pages. Search engines only really care to summarize the primary topic or purpose of a web page in their “rich snippets” or “cards”, and thus that’s sufficient.
Check out the latest validators which now include some microformats2 support as well!
#14
in reply to:
↑ 11
@
9 years ago
Replying to pento:
I'm cool with doing this, but I do have some questions, mostly around my lack of familiarity with microformats.
- How does microformats discovery work? Do we need to put something in the header?
- Is there a down side to ceasing microformats 1 support?
- Can we support microformats 1 and 2 simultaneously?
If we can get away without adding yet another theme option, I think that would be the vastly more preferable method.
Microformats don't require a header. We already have microformats 1 in WordPress, but the implementation has some issues. The proposed patch has both the classic and the newer formatting in it.
I'd prefer to deprecate the older standard, but we go back to the legacy of the original inclusion. Too many things depend on the microformats classes as a styling element, which is what necessitated the theme option flag.
Whether we want to go as far as to remove all of the older microformats in favor of the new ones if the flag is set is certainly a question. But, a lot of plugins and themes style the output of certain fields based on the classic microformats classes, therefore it would cause some chaos.
#15
in reply to:
↑ 13
@
9 years ago
Replying to TomasM:
Microformats creators say this:
Upgrading to microformats2
Upgrade sites
Second, if you publish any kind of semantic information, start upgrading your web pages to microformats2 across the board.
If you’re concerned about what search engines claim to support, there are two approaches to choose from:
Know that search engines are a trailing indicator, and as microformats2 usage grows, they’ll index it as well.
Or: Use one classic microformat (supported by all major search engines) at top of your page, e.g. on the <body>, in addition to your microformats2 markup throughout your pages. Search engines only really care to summarize the primary topic or purpose of a web page in their “rich snippets” or “cards”, and thus that’s sufficient.
Check out the latest validators which now include some microformats2 support as well!
I'd personally love it, but I am only skeptical about it because of the backward compatibility issues that come with deprecating it fully. Maybe, like other deprecations, it should come in stages.
#16
in reply to:
↑ 11
;
follow-up:
↓ 17
@
9 years ago
Replying to pento:
- Is there a down side to ceasing microformats 1 support?
Neither Bing or Google list support of microformats 2 (mf2) officially, only microformats 1 (mf1). As mf2 provides a richer data set than mf1, I'd be surprised if they ignored it completely. Perhaps other will have more insight.
I've included both mf1 & 2 on my site for some time without any apparent ill-effect, webmaster tools rich snippets tester still parses everything correctly.
#17
in reply to:
↑ 16
@
9 years ago
Replying to peterwilsoncc:
Replying to pento:
- Is there a down side to ceasing microformats 1 support?
Neither Bing or Google list support of microformats 2 (mf2) officially, only microformats 1 (mf1). As mf2 provides a richer data set than mf1, I'd be surprised if they ignored it completely. Perhaps other will have more insight.
Bing and Google built there proprietary formats based of the original Microformats, no doubt in no small part because of the integration of these in WordPress, WordPress doesn't need to follow Bing or Google ;)
W3G Related Things: Microdata http://www.w3.org/TR/microdata/ and JSON-LD http://www.w3.org/TR/json-ld/
#18
@
9 years ago
Speaking as someone who is partial to microformats, I've always found them much simpler than any of the other standards. Usability is a great criteria. WordPress also has a history of Microformat integration that we can continue to iterate on.
#19
@
9 years ago
Thanks for the feedback, everyone!
It sounds like there's no real downside to supporting mf1 and 2 simultaneously, which would remove the need for adding a theme option.
@dshanske, could you take a pass at reworking the patch to do it that way?
Also, I'd like to see some unit tests to make sure we don't accidentally break them in the future.
#20
@
9 years ago
I'll work on the patch changes, and check them against a parser. I usually use http://pin13.net/mf2/ which I believe uses the project https://github.com/indieweb/php-mf2/
I really need to learn how to write unit tests.
#21
@
9 years ago
The only problem I need to solve is the hentry issue I started out with. If the mf2 and the mf1 are on the same elements, this isn't an issue. The current WordPress code puts hentry on everything, which isn't exactly correct. If hentry stays for compatability and the newer h-entry is not always there, it might be an issue.
Will have to think carefully.
#22
follow-up:
↓ 23
@
9 years ago
@dshanske Do you predict what parts will have to be implemented in the themes? Or this WP patch will take care of everything?
#23
in reply to:
↑ 22
@
9 years ago
Replying to TomasM:
@dshanske Do you predict what parts will have to be implemented in the themes? Or this WP patch will take care of everything?
Regrettably it can't. It can only fix the markup that WordPress itself generates. The theme handles marking up a lot.
#24
@
9 years ago
I have been revisiting this. And aside from the hentry/hfeed issue, all the others can be addressed without a theme support tag. But the inability to change the behavior of hentry due backcompat issues is a breaker. It only works if classic and microformats 2 are on the same elements.
Ideas?
This ticket was mentioned in Slack in #core by dshanske. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by dshanske. View the logs.
9 years ago
#27
@
9 years ago
- Keywords close added
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Closing after chatting with @dshanske. As h-entry isn't a one for one replacement of hentry, I can't see how the change could be made without breaking a majority of WordPress sites.
The only option is a theme option, and at the point it's just as easy to remove the classes with filters on post_class and body_class.
µFormats are mainly theme related. Some rough thoughts:
add_theme_support( 'microformats2' );There is a repo showing default HTML classes that need to be targeted on Github.