2020/Pop-ups/Microformats

 microformats2  was an IndieWebCamp Pop-up 2020 session.


 * Video:

Notes archived from: https://etherpad.indieweb.org/microformats-popup

IndieWebCamp Pop-ups 2020 Session: microformats2 When: 2020-09-12 9:30 AM (Pacific) / 12:30 PM (Eastern) URL: https://events.indieweb.org/2020/09/microformats-session-cay9SF07oNTY Etherpad: https://etherpad.indieweb.org/microformats-popup Video: https://archive.org/details/microformats-indiewebpopup2020 Streaming video/audio platform: Zoom

Interest
Add your +1 for interest in this topic:
 * undefined
 * undefined

Agenda
Let's discuss how we can close out some outstanding microformats2 questions. Come with a few items from the list to discuss.
 * https://github.com/microformats/microformats2-parsing/issues/
 * https://github.com/microformats/h-card/issues
 * https://github.com/microformats/h-entry/issues
 * https://github.com/microformats/h-feed/issues
 * https://github.com/microformats/h-event/issues

Parsing
microformats2 features are advanced by a 3 step process: Proposed, Draft, and Stable.


 * Proposed features must provide documentation of what specific real world use-cases they are solving, preferably with a link to a step-by-step user scenario.
 * Draft properties must in addition be published and consumed in the wild on the public web, demonstrate solving the use case for which they were proposed, and should provide citations of real world public web sites publishing and (other sites) consuming them, interoperably.
 * Stable properties must in addition be published and consumed in the wild on multiple sites by multiple implementations (3+ different sites and implementations for publishing and consuming). When a draft property reaches a critical mass of deployment by numerous sites and implementations (far beyond 3+), due to network effects and backward compatibility considerations it effectively becomes stable, since it becomes increasingly difficult to change it in any way and have so many sites and implementations also change.

We have several properties that could advance levels.


 * Parse Language Information - https://github.com/microformats/microformats2-parsing/issues/3
 * tabled this issue for lack of implementation movement
 * Should U-parsing Special Case srcset - https://github.com/microformats/microformats2-parsing/issues/7
 * question about conflicts with picture (which may be a separate issue)
 * new issue: how are microformats applied to picture elements at all today?
 * Separate picture element issue created 2022-03-08
 * resolution: try to urge for parser support; possible consumer lined up in Monocle.
 * Consider not including alt-text as part of surrounding text properties https://github.com/microformats/microformats2-parsing/issues/16
 * Only if the img has a microformats property, remove the alt-text
 * Figure out if this only applies when full img parsing has been done for src and alt (per http://microformats.org/wiki/microformats2-parsing#parse_an_img_element_for_src_and_alt) or also in other cases, e.g. when only alt is parsed in case of p- classes.
 * URLs with Fragments should only have the node identified by the fragment and its descendents parsed https://github.com/microformats/microformats2-parsing/issues/46
 * Parsers will have potential issues with h-cards, links, etc on the document, but not within the fragment, better that the parser covers the entirety of the page and let the consumer deal with the fragment portion.
 * Example of fragment link that breaks authorship algorithm in XRay: https://grapefruit.zegnat.net/2018/04.html#dt201804141608Z
 * closeable
 * Should we specify a mime-type for parsed mf2 json https://github.com/microformats/microformats2-parsing/issues/52
 * WordPress plugin publishes JSON with the mf2json mimetype, generates it by hand
 * Need a validator
 * Side note re: validating mf2 JSON, there is a schema as well as a vocabulary aware validator available see https://microformats.org/wiki/microformats2-json#See_Also
 * Update all sites that emit microformats 2 json to use the new mime-type once validator is available to test
 * specifically microformats.io mf2json output
 * Need to specify an mf2-json content-type (wire protocol) spec to discuss how to publish and consume it, e.g. over HTTP. Also: rel-alternate usage, http headers, etc.
 * this is what we cite in the IANA registration for application/mf2+json
 * this is what a validator that acepts a URL MUST support on the consuming side
 * Need to specify a mf2-json content spec, which has the various constraints about must ignore or must reject, additional keys etc.
 * Example of description of the mf2 JSON objects: https://microformats.org/wiki/microformats2-json (does not include information about ignoring properties)
 * this is what an mf2json validator MUST support, e.g. in a textarea input

h-card
(stub section) (please propose specific issues to discuss)
 * https://github.com/microformats/h-card/issues

h-entry
, unless there is a p-location h-card, which is still considered a "checkin" (i.e. with a photo). Otherwise the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo.
 * Properties waiting to move to Core
 * u-photo https://github.com/microformats/h-entry/issues/4
 * Definition of u-photo - one or more photos that is/are considered the primary content of the entry. We must open an issue to update the definition and  will do that shortly and #4 cannot be addressed.


 * Agreed upon definition? Not precise enough to become core
 * New issue to be opened to discuss e-content overlapping with u-photo, u-audio, u-video
 * link to previous discussion: https://github.com/aaronpk/XRay/issues/52
 * publishing examples of how people use u-photo vs. e-content:
 * u-photo(s) inside e-content e.g., undefined,
 * u-photo(s) as a sibling to e-content - with separate img tags for each
 * u-photo(s) as a sibling to e-content - only img tag for u-photo, no img tag in e-content e.g.
 * u-photo(s) mixing with an article (non-empty p-name) <-- we consider this an erroneous use of u-photo
 * wouldn't this be a photo with a name, e.g. like a flickr photo?
 * Definition needs to specify what is a multiphoto (multiple u-photo properties) and how to process it


 * Consuming applications to consider:
 * Bridgy consuming h-entry to POSSE to Twitter, including first four u-photo properties it finds
 * Monocle post-preview


 * Interaction with u-featured


 * u-video https://github.com/microformats/h-entry/issues/5 - Not Discussed
 * u-comment https://github.com/microformats/h-entry/issues/20 - Not Discussed


 * process questions
 * what are the requirements / is the process to iterate on a Proposed property?
 * undefined issue: how to update the definition of a proposed property? perhaps allow multiple definitions for a proposed property? don't change someone else's definition, rather, either work with them to iterate, or add your own as an alternative
 * what are the requirements / is the process to iterate on a Draft property?
 * undefined issue: update the definition of a draft property the new definition must resatisfy the entry conditions for a Draft property (2+ publishers and 2+ consuming applications consistent with that new definition) and gather consensus among publishers & consuming application developers using a GitHub issue — undefined will file this proposed process change as an issue
 * undefined issue: we should add "needs test cases" as a requirement for a Stable / Core property. agreed: Zegnat, Kartik, GWG (does not like writing tests lol), Chris
 * undefined issue: propose requiring an issue to take a proposed property to draft issue to collect the required publishing & consuming app citations (and verified by another)
 * guidance: explicit lists of steps to follow to add a proposed property (with example "what specific real world use-cases they are solving, preferably with a link to a step-by-step user scenario, e.g. demonstratable using existing non-standard / single-site / single-implementation tools"), and transition a property from proposed to draft to core


 * Properties Waiting to Move to Draft
 * u-audio https://github.com/microformats/h-entry/issues/6 - Not Discussed
 * huffduffer.com is an example
 * u-bookmark-of https://github.com/microformats/h-entry/issues/12 - Not Discussed
 * u-featured https://github.com/microformats/h-entry/issues/14 - Not Discussed
 * u-checkin https://github.com/microformats/h-entry/issues/15 - Not Discussed


 * Proposed Properties
 * u-listen-of https://github.com/microformats/h-entry/issues/11 - Not Discussed
 * u-read-of https://github.com/microformats/h-entry/issues/10 - Not Discussed
 * u-watch-of https://github.com/microformats/h-entry/issues/17 - Not Discussed
 * Status https://github.com/microformats/h-entry/issues/18 - Idea to use TODO elements from iCal - Not Discussed
 * needs-action
 * completed
 * in-process
 * cancelled

h-feed

 * Do Not Restrict H-Feed to contain only H-Entry https://github.com/microformats/h-entry/issues/16 - Not Discussed
 * Rules for Implied H-Feed https://github.com/microformats/h-feed/issues/1 - Also comes up as a parsing question https://github.com/microformats/microformats2-parsing/issues/47 - Not Discussed

h-event

 * Advance H-Event to Microformats Specification https://github.com/microformats/h-event/issues/2 - Not Discussed
 * Event Description should be replaced with Content Property https://github.com/microformats/h-event/issues/3 - Not Discussed
 * Format for Duration Should Be Specified https://github.com/microformats/h-event/issues/5 - Not Discussed
 * Adopt iCal Status for Events - https://github.com/microformats/h-event/issues/6 - Not Discussed
 * tentative
 * confirmed
 * cancelled