Nineteen years ago last Saturday, @KevinMarks.com & I introduced^1 #microformats @OReillyMedia ETech 2004, building on “semantic (x)html”. We’ve come a long way since, from methodologies to #microformats2, from publishing to peer-to-peer #IndieWeb use-cases. We named #microformats only after we had established a pattern of real world examples; even our talk proposal was named RealWorldSemantics^2, and provided examples in that broader theme. This exemplified important implicit values in ordering our efforts: 1. get real world things working first, not just theory 2. name them after a pattern emerges, not just solo efforts 3. grow the pattern with proposals, prototypes, iteration, evolution The examples at that point in time: * XFN — using rel-values for blogroll semantics, and the technology that defined rel=me in v1.1^3, now the standard for decentralized social media verification on Mastodon^4, GitHub^5, elsewhere, and the basis of RelMeAuth^6 * XMDP — XHTML MetaData Profiles, notably using an HTML class^7 with a particular value 'profile' to indicate presence of a specific semantic structure * XOXO — XHTML Outlines, formalizing existing usage of (X)HTML elements for outlines, also using an HTML class with a particular value 'xoxo' to express a semantic Growing the pattern: * rel=license — solved page licensing better than before, since widespread adopted * VoteLinks — new rel values, prototyped, only one consuming implementation (since defunct) And further brainstorming: * recommendations — initial rel="recommendation" idea eventually evolved to hReview, and today’s h-review * syndication — helped motivate HTML5 <time> element, eventually led to hAtom, and today’s h-entry * playlists — led to various ideas, proposals, & demos^8, still not really solved today The mid-2000s were a time of eager experimentation, when we were learning that very small bits of markup (yes, hence the name) could be used to build some very useful capabilities on top of the open web platform. A few observations with the benefit of years of experience since we proposed “microformats”: One: Many microformats succeeded because we solved an existing problem, with existing *complex* solutions, by providing a drastically *simpler* solution. XFN instead of FOAF. rel=license instead of Creative Commons RDF in HTML comments. By doing so, we skipped the often harder problem of defining & refining a problem worth solving, a use-case, or user scenario. Two: A few microformats succeeded because they solved existing problems, re-using *existing established* open solutions in other formats, reformatted into native HTML. hCard from vCard. hCalendar from iCalendar. This methodology leveraged years of prior hard open standards work by numerous others across numerous organizations, and deliberately avoided the bikeshedding trap of renaming things (or any other kind of non-trivial “clean-up”) while reformatting, thus making it easy for developers of one technology to see the 1:1 mapping and use the other. The primary downside with this approach was formats that were larger than perhaps necessary for HTML-specific use-cases. Eventually for microformats2 vocabularies, we adopted a subset approach, looking for web publishing use-cases for each feature, making h-card smaller than hCard, and h-event smaller than hCalendar. Three: Success in a search engine was not enough, and sometimes attracted more bad actors than good. @KevinMarks.com, myself, and others at Technorati built search engine indexing and use of rel-tag and hReview, which helped evolve their specifications. A few other small search engines indexed rel=tag markup, however none remain today. hReview was adopted by Google which led to it being heavily spammed. This pattern repeated itself with other microformats, and eventually we shifted from: → of course search is the first obvious use-case → search is one use-case among others → we need primary use-cases outside of search for longterm ecosystem success Which leads to the fourth observation. Four: Publishing alone is not a use-case. There must be multiple consuming code use-cases (beyond search) for a microformat to succeed longterm. From individual features to whole microformats vocabularies, we learned that not only did there need to be sufficient content being published already, without microformats, that could benefit, but there needed to be good enough consuming code use-cases that benefited users (not just developers). The #IndieWeb community has been exceptionally helpful in both defining such use-cases and iterating on them with implementations. We still get questions of the form: What’s the best way to mark this up? I used to very much believe that if you could mark something up more semantically, you should spend the time & effort to do so. This drove a lot of early experiments with markup, and did provide some eventual benefits, most notably when semantic HTML elements provided good hooks for accessibility tools such as screen readers. Now we know the answer to the question of “How should I mark-up this content?” must be accompanied by specific use-cases for consuming code of that markup. If there is no consuming code use-case, it is not worth the time to add the mark-up (never mind the maintenance effort over time). Sometimes one single consuming code use-case is sufficient to justify the time & effort to add more semantic mark-up. If that markup helps screenreaders, then it’s worth it. More often than not however, there must be multiple (again, beyond search) consuming code use-cases for it to be worth adding semantic markup, and certainly for developing new markup, whether microformats features or new microformats. This focus on and repeated asking of questions like: * What is the (consuming code) use-case? * Or how does it benefit readers of this content? has helped focus our modern microformats efforts on actual benefits to humans first, and machines second (if at all). If you think of IndieWeb use-cases for existing or new microformats, come join us in the developers chat: * https://chat.indieweb.org/dev If you think of other use-cases or want to chat about modern microformats methodologies in general, join us in the microformats chat: * https://chat.indieweb.org/microformats This is day 32 of #100DaysOfIndieWeb #100Days ← Day 31: https://tantek.com/2023/044/t1/unified-sent-box-universal-outbox → Day 33: https://tantek.com/2023/051/t1/five-years-ago-w3c-social-web Post glossary: h-card https://microformats.org/wiki/h-card h-entry https://microformats.org/wiki/h-entry h-event https://microformats.org/wiki/h-event h-review https://microformats.org/wiki/h-review hAtom https://microformats.org/wiki/hatom hCalendar https://microformats.org/wiki/hcalendar hCard https://microformats.org/wiki/hcard hReview https://microformats.org/wiki/hreview rel-license https://microformats.org/wiki/rel-license rel-tag https://microformats.org/wiki/rel-tag rel-values https://microformats.org/wiki/existing-rel-values XFN https://gmpg.org/xfn/ XMDP http://gmpg.org/xmdp/description XOXO https://microformats.org/wiki/xoxo Previously, previously, previously: * https://tantek.com/2019/044/t1/15-years-ago-introduced-microformats * https://tantek.com/2014/042/t2/ten-years-ago-introduced-microformats-etech * https://tantek.com/2011/042/t2/years-ago-presented-microformats-etech * https://twitter.com/t/status/701095802 References: ^1 https://tantek.com/presentations/2004etech/realworldsemanticspres.html ^2 https://tantek.com/log/2004/02.html#d04t1311 ^3 https://gmpg.org/xfn/11#me ^4 https://docs.joinmastodon.org/user/profile/#verification ^5 https://web.archive.org/web/20230314223136/https://hachyderm.io/@nova/109790530971147702 ^6 https://tantek.com/2023/032/t1/years-relmeauth-replace-openid ^7 https://tantek.com/2012/353/b1/why-html-classes-css-class-selectors ^8 http://microformats.org/wiki/events/2007-12-11-open-media-web

Nineteen years ago last Saturday, @KevinMarks.com & I introduced¹ #microformats @OReillyMedia ETech 2004, building on “semantic (x)html”.

We’ve come a long way since, from methodologies to #microformats2, from publishing to peer-to-peer #IndieWeb use-cases.

We named #microformats only after we had established a pattern of real world examples; even our talk proposal was named RealWorldSemantics², and provided examples in that broader theme.

This exemplified important implicit values in ordering our efforts:
1. get real world things working first, not just theory
2. name them after a pattern emerges, not just solo efforts
3. grow the pattern with proposals, prototypes, iteration, evolution

The examples at that point in time:
* XFN — using rel-values for blogroll semantics, and the technology that defined rel=me in v1.1³, now the standard for decentralized social media verification on Mastodon⁴, GitHub⁵, elsewhere, and the basis of RelMeAuth⁶
* XMDP — XHTML MetaData Profiles, notably using an HTML class⁷ with a particular value 'profile' to indicate presence of a specific semantic structure
* XOXO — XHTML Outlines, formalizing existing usage of (X)HTML elements for outlines, also using an HTML class with a particular value 'xoxo' to express a semantic

Growing the pattern:
* rel=license — solved page licensing better than before, since widespread adopted
* VoteLinks — new rel values, prototyped, only one consuming implementation (since defunct)

And further brainstorming:
* recommendations — initial rel="recommendation" idea eventually evolved to hReview, and today’s h-review
* syndication — helped motivate HTML5 <time> element, eventually led to hAtom, and today’s h-entry
* playlists — led to various ideas, proposals, & demos⁸, still not really solved today

The mid-2000s were a time of eager experimentation, when we were learning that very small bits of markup (yes, hence the name) could be used to build some very useful capabilities on top of the open web platform.

A few observations with the benefit of years of experience since we proposed “microformats”:

One: Many microformats succeeded because we solved an existing problem, with existing *complex* solutions, by providing a drastically *simpler* solution.

XFN instead of FOAF. rel=license instead of Creative Commons RDF in HTML comments.

By doing so, we skipped the often harder problem of defining & refining a problem worth solving, a use-case, or user scenario.

Two: A few microformats succeeded because they solved existing problems, re-using *existing established* open solutions in other formats, reformatted into native HTML.

hCard from vCard. hCalendar from iCalendar.

This methodology leveraged years of prior hard open standards work by numerous others across numerous organizations, and deliberately avoided the bikeshedding trap of renaming things (or any other kind of non-trivial “clean-up”) while reformatting, thus making it easy for developers of one technology to see the 1:1 mapping and use the other.

The primary downside with this approach was formats that were larger than perhaps necessary for HTML-specific use-cases.

Eventually for microformats2 vocabularies, we adopted a subset approach, looking for web publishing use-cases for each feature, making h-card smaller than hCard, and h-event smaller than hCalendar.

Three: Success in a search engine was not enough, and sometimes attracted more bad actors than good. @KevinMarks.com, myself, and others at Technorati built search engine indexing and use of rel-tag and hReview, which helped evolve their specifications. A few other small search engines indexed rel=tag markup, however none remain today. hReview was adopted by Google which led to it being heavily spammed.

This pattern repeated itself with other microformats, and eventually we shifted from:
→ of course search is the first obvious use-case
→ search is one use-case among others
→ we need primary use-cases outside of search for longterm ecosystem success
Which leads to the fourth observation.

Four: Publishing alone is not a use-case. There must be multiple consuming code use-cases (beyond search) for a microformat to succeed longterm.

From individual features to whole microformats vocabularies, we learned that not only did there need to be sufficient content being published already, without microformats, that could benefit, but there needed to be good enough consuming code use-cases that benefited users (not just developers). The #IndieWeb community has been exceptionally helpful in both defining such use-cases and iterating on them with implementations.

We still get questions of the form: What’s the best way to mark this up?

I used to very much believe that if you could mark something up more semantically, you should spend the time & effort to do so. This drove a lot of early experiments with markup, and did provide some eventual benefits, most notably when semantic HTML elements provided good hooks for accessibility tools such as screen readers.

Now we know the answer to the question of “How should I mark-up this content?” must be accompanied by specific use-cases for consuming code of that markup.

If there is no consuming code use-case, it is not worth the time to add the mark-up (never mind the maintenance effort over time).

Sometimes one single consuming code use-case is sufficient to justify the time & effort to add more semantic mark-up. If that markup helps screenreaders, then it’s worth it. More often than not however, there must be multiple (again, beyond search) consuming code use-cases for it to be worth adding semantic markup, and certainly for developing new markup, whether microformats features or new microformats.

This focus on and repeated asking of questions like:
* What is the (consuming code) use-case?
* Or how does it benefit readers of this content?
has helped focus our modern microformats efforts on actual benefits to humans first, and machines second (if at all).

If you think of IndieWeb use-cases for existing or new microformats, come join us in the developers chat:
* https://chat.indieweb.org/dev

If you think of other use-cases or want to chat about modern microformats methodologies in general, join us in the microformats chat:
* https://chat.indieweb.org/microformats

This is day 32 of #100DaysOfIndieWeb #100Days

← Day 31: https://tantek.com/2023/044/t1/unified-sent-box-universal-outbox
→ Day 33: https://tantek.com/2023/051/t1/five-years-ago-w3c-social-web

Post glossary:

h-card
https://microformats.org/wiki/h-card
h-entry
https://microformats.org/wiki/h-entry
h-event
https://microformats.org/wiki/h-event
h-review
https://microformats.org/wiki/h-review
hAtom
https://microformats.org/wiki/hatom
hCalendar
https://microformats.org/wiki/hcalendar
hCard
https://microformats.org/wiki/hcard
hReview
https://microformats.org/wiki/hreview
rel-license
https://microformats.org/wiki/rel-license
rel-tag
https://microformats.org/wiki/rel-tag
rel-values
https://microformats.org/wiki/existing-rel-values
XFN
https://gmpg.org/xfn/
XMDP
http://gmpg.org/xmdp/description
XOXO
https://microformats.org/wiki/xoxo

Previously, previously, previously:
* https://tantek.com/2019/044/t1/15-years-ago-introduced-microformats
* https://tantek.com/2014/042/t2/ten-years-ago-introduced-microformats-etech
* https://tantek.com/2011/042/t2/years-ago-presented-microformats-etech
* https://twitter.com/t/status/701095802

References:
¹ https://tantek.com/presentations/2004etech/realworldsemanticspres.html
² https://tantek.com/log/2004/02.html#d04t1311
³ https://gmpg.org/xfn/11#me
⁴ https://docs.joinmastodon.org/user/profile/#verification
⁵ https://web.archive.org/web/20230314223136/https://hachyderm.io/@nova/109790530971147702
⁶ https://tantek.com/2023/032/t1/years-relmeauth-replace-openid
⁷ https://tantek.com/2012/353/b1/why-html-classes-css-class-selectors
⁸ http://microformats.org/wiki/events/2007-12-11-open-media-web