2020/Pop-ups/Microformats

From IndieWeb

microformats2 was an IndieWebCamp Pop-up 2020 session.

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:

Participants

Agenda

Let's discuss how we can close out some outstanding microformats2 questions. Come with a few items from the list to discuss.

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.

h-card

(stub section)

(please propose specific issues to discuss)


h-entry

  • Properties waiting to move to Core

, 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.

      • 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. Kartik Prabhu, Tantek Çelik,
        • 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. David Shanske
        • 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
    • process questions
      • what are the requirements / is the process to iterate on a Proposed property?
        • Tantek Çelik 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?
        • Tantek Çelik 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 — Tantek Çelik will file this proposed process change as an issue
      • Tantek Çelik 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
      • Tantek Çelik 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



h-feed


h-event

Retrieved from "https://indieweb.org/wiki/index.php?title=2020/Pop-ups/Microformats&oldid=88408"