#microformats 2023-12-02

2023-12-02 UTC
#
[tantek] [snarfed]++ for really good points in https://github.com/microformats/microformats2-parsing/issues/75 and expressing your preference that you'd like to distinguish an item from metaformats (presumably backcompat) vs the rest of the document (or explicit mf2 metaformats)
#
[tantek] I will attempt a spec change accordingly, separating explicit mf2 metaformats from implied backcompat metaformats (likely giving them their own top level key)
#
[tantek] oops apparently I did create https://github.com/microformats/metaformats/issues
[aciccarello] joined the channel
#
[aciccarello] Migrate those other issues??
#
tantek edited /metaformats (+23) "split backcompat metaformats from explicit mf2 metaformats, per https://github.com/microformats/microformats2-parsing/issues/75 request from implementor, and in consideration of reducing chance of an unexpected (possibly worse) new first root microformat in parsed documents" (view diff)
#
[tantek] aciccarello yes I will migrate the issues
#
[tantek] ok heads-up [snarfed], angelo, [capjamesg], aciccarello ^ pretty major metaformats spec update, splitting explicit <meta class> parsing and backcompat <meta> parsing, added a top level "meta-item" hash for the latter consuming code can treat backcompat meta differently from explicit mf2 class based meta/microformats
#
[tantek] will migrate issues next
#
[tantek] metaformats issue transfers complete
#
[aciccarello] 👀 I'll take a look at that spec update before I publish my blog post about the node.js parser. Also will probably create some issues.
#
[tantek] thanks aciccarello. [snarfed]'s issue 75 above felt urgent enough that I thought it merited an immediate spec change before we end. up prototyping something that's not quite workable for consuming code. Please LMK what you think of this approach of putting the backcompat metaformats into a separate top level "meta-item" hash
#
[tantek] ^ also [snarfed] curious if that addresses your concerns in 75 since I didn't exactly do what you asked. My intuition is that web developers that use explicit mf2 root classes on html or head elements "know what they're doing" and thus want to / will use explicit mf2 class names on any meta elements they want parsed as properties
#
[aciccarello] I left a comment on the GitHub issue, but I'd prefer to not sideline things into a separate `meta-item` property to make it easier to passively consume metaformats.
#
[tantek] I think there may be enough of a trust difference in the quality of the information from explicit mf2 and implied metaformats that there will be consuming code that needs to know the difference (which is what I believe [snarfed] was saying in the issue description).
#
[tantek] if we find out from implementation experience that consuming code is always treating them the same, then it's easy enough to fold meta-item into being the last item in the items array
#
[tantek] I suspect we will know quickly from [snarfed] what he finds he has to do "special" to handle implied metaformats compared to explicit mf2, and then we can see if those "special" things can/should be folded into the metaformats spec
#
[tantek] if it turns out we learn from implementation experience that we're able to handle the quirks or trust issues with implied metaformats directly in the metaformats spec, then we can consider folding meta-item into items for passive consuming code convenience as you say
[0x3b0b], gRegorLove_, [James_Van_Dyne], [tantek], [pfefferle] and [snarfed] joined the channel
#
[snarfed] thanks all!
#
[snarfed] it doesn't have to be in a different list. it could still be in `items`, as `h-card`, and just have a new top-level property, eg `source: metaformats`. easy to ignore if you want
barnaby joined the channel
#
[aciccarello] +1 to a source property
dckc joined the channel
#
dckc I'm trying to mark up "Every first Saturday of the month at 20:00-22:00 ET" on https://fossandcrafts.org/hack-and-craft/ . I think I see how to do rrule, but I'm not sure about timezone.
#
dckc hm. interesting: jCal RFC https://www.rfc-editor.org/rfc/rfc7265
#
dckc I don't see much momentum, though
#
[tantek] hello dckc! yes RRULE is quite challenging
#
[tantek] source property seems like adding complexity to every other "normal" item just for the special case of metaformats and that seems like a bad idea/methodology (complexifying the common case to handle edge case)