#microformats 2026-08-28

2026-08-28 UTC
#
[tantek] Where did we get stuck on status? Or rather what problem it is trying to solve?
#
[tantek] Do we have a brainstorming / feature request issue on the confirmed/tentative/cancelled property of an h-event in its repo?
#
gRegor yes, though it's minimal. It's the tentative/cancelled/confirmed status in iCalendar
#
gRegor https://github.com/microformats/h-event/issues/6
#
Loqi [preview] [dshanske] #6 Adopt iCal Status
#
gRegor Meetable shows those statuses with a badge and, I think, when an event is cancelled it prefixes "CANCELLED" to the event name as a workaround if you're subscribed to the ICS
#
gRegor Not sure "stuck", just not a lot of use-cases so far other than that. There might have been some hesitance about the property name being so generic "status"
#
[tantek] I'm wondering if we can pick a more specific word than "status" which can be so many different things across different contexts and generally we have tried to NOT do that with microformats properties names. We have tried to name microformats properties generically when the same generic meaning can and will be re-used across contexts (different microformats).
#
[tantek] e.g. "status" is something that to-do or reading microformats could use for "not started", "started", "partial", "finish"
#
[tantek] "completed" as it were
#
[tantek] in the event context, a property name like "confirmation" could work, even if "confirmation: canceled" reads a bit funny
thatoddshade, pimeille, [Murray], barnaby, [Ana_R], espen, wturrell, ZodiacalComet, morganwebdev, jeremycherfas and [Sophia] joined the channel
#
gRegor iCalendar uses status for todos as well
#
gRegor Agree, it's pretty generic and could lead to confusing use across microformats. But it also feels weird to use a different name. I don't really have any suggestions currently.
#
gRegor I don't think an alternative has really come up when it comes to reading, watching, etc. statuses
#
gRegor Also to be clear, whatever the mf2 property is called, the result in the ICS will be in the form "STATUS:CANCELLED"
thatoddshade, rMdes, ZodiacalComet and barnaby joined the channel
#
[tantek] sure, there are other mf2 properties where we did some simplification/convergence or renaming to get something more specific
#
[tantek] e.g. h-card has job-title which gets turned into VCARD TITLE
#
[tantek] h-event is proposed to re-use e-content (rather than its own p-description) from h-entry, which will still get converted into ICS DESCRIPTION
#
[tantek] https://github.com/microformats/h-event/issues/3
#
Loqi [preview] [tantek] #3 Replace h-event 'description' with 'content' property
#
[tantek] iCal "status" being too generic has closest "prior art/discussion" of vCard "title" being too generic.
#
[tantek] we've already learned our lesson (it was a really annoying to explain to folks that "title" mean specifically "job title" back in the hCard days) so we should use that learning to avoid repeating this pain with h-event and the too generically named "status"
#
gRegor Makes sense
#
gRegor It's a tough decision, partly why after 8 years indiebookclub still uses "read-status"
#
gRegor Which isn't a great option, don't want a bunch of `*-status` properties
#
[tantek] maybe not a "bunch", but maybe a small few would be ok and actually good so they don't overload/confuse people
#
[tantek] there's some precedence for this in the old hAtom where we had entry-title, entry-summary, and entry-content
#
[tantek] gRegor, I think indiebookclub use of read-status was a very wise and prescient decision
#
[tantek] I would be much more comfortable with using "event-status" in h-event than unprefixed "status"
#
[tantek] my guess is that that the values are mostly disjoint between read-status and event-status properties
#
[tantek] I could see *some* more overlap between read-status and say "task-status" in the context of to-do or projects
#
[tantek] reading a book is kind of a to-do or project 🙂
#
[tantek] another alternative for the event-specific status as it is used on Meetable today is its really a form of "planning-status"
#
[tantek] then the specific values make a lot more sense with that additional context
#
gRegor Yeah, I did write a while back how "Want to read" is more of a /want post than a status of a read post, so floated the idea of changing what IBC did for those. The other two "currently reading" and "finished reading" still make sense as a read-status
#
[tantek] confirmed, tentative, postponed, cancelled [sic] are all planning related
#
gRegor also some older thoughts here: https://indieweb.org/read#on_the_read-status_property
#
[tantek] like actual event-status might be more things like "before, doors/zoom-open, started, in-progress, program-finished, zoom/doors-closed"
#
[tantek] which feels more similar to read-status values to-read, reading, finished
rMdes and barnaby joined the channel