#microformats 2026-11-07

2026-11-07 UTC
rMdes, GWG, barnaby, rMdes-bnc and [burgeonlab] joined the channel
#
trwnh i generally know what the prefixes mean, but the behavior is confusing when it comes to embedded h- nodes. > +GWG: u- vs p-
#
trwnh also in #indieweb-dev use cases some apps seem to require one over the other. for example i was using an h-feed tester that wouldn't accept .u-author.h-card and would only accept .p-author.h-card
#
trwnh (the html was an a element)
#
trwnh in theory something like .p-author.u-author.h-card should capture all possibilities but that could also in practice cause more problems
[trovster] and jtojnar joined the channel
#
jtojnar gRegor do you want me to extract the mockserver from the chain?
[snarfed], [pcarrier_com], [artlung], jone42, barnaby and vriska joined the channel
#
gRegor trwnh which h-feed tester, I'm not familiar?
#
trwnh i don't remember which one exactly, it was a while ago :/ the larger point is that microformats2 could be more clear on recommending a specific pattern when it comes to embedded h-nodes since the p- vs u- difference could bite people in practice
#
gRegor For nested microformats, this section describes what the different prefixes will do with the `value` of the nested mf2 https://microformats.org/wiki/microformats2-parsing#implementations:~:text=if%20that%20child%20element%20itself%20has%20a%20microformat
#
Loqi [preview] Tantek Çelik
#
gRegor p-author h-card will have the h-card.value be the name
#
gRegor u-author h-card will have the h-card.value be the URL
#
trwnh and .p-author.u-author.h-card i assume is a headache :p
#
gRegor the u-author is redundant there
#
trwnh or i guess strictly reading the algo here it uses p- first
#
gRegor I don't think there's a one size fits all approach, it depends what the intended use case is. We do try to document the most common one though
#
gRegor The nested `value` is a convenient shorthand, but (I think) a consumer should ideally be looking into the nested object to find the properties it wants
#
trwnh well there's a practical difference between p-foo and u-foo here, right? say for parsing an h-feed author or an h-entry author. you get multiple possible different representations that all have to be accounted for
#
trwnh which is maybe not a problem in microformats2 itself but it is a problem in the various h- formats
#
gRegor If the consumer only wants to look at the e.g. `author.value` property and expects it to always be either a string, or a URL, then yeah it's an issue.
#
gRegor But what I'm suggesting is a more robust consumer should look at the author property, see it's an h-card, then look for h-card.name, h-card.url, etc.
#
gRegor In the latter case, it doesn't matter if they published u-author h-card or p-author h-card
#
gRegor Contrived example: http://php.microformats.io/?id=20261107232214003
#
trwnh right -- looking at the h-card if it's used should sidestep the issue. but otherwise it's at least 3 cases to account for. step 1 try the h-card, else try the p-author or u-author, else try the other one
#
Loqi right has -1 karma over the last year
#
trwnh oops
#
gRegor The resulting property is always `author` regardless of the prefix
#
trwnh did not know loqi would do that with a space in between
#
gRegor right++
#
Loqi right has 0 karma over the last year
#
trwnh :)
#
gRegor so it's two cases I think. you can either look in the nested h-* for the property, or try the nested `value`. I don't think you'd ever do both.
#
trwnh oh for using the parsed jf2 i guess yeah. just that you don't know if it's a url or not
#
gRegor I guess there are more cases, no guarantee there's a nested h-card. `author` could come back as just a string
#
trwnh ah right, the string-only case is what i was thinking of
#
trwnh either it's an object and you parse the h-card stuff, or it's an object and you parse the value without knowing if it's a url or not, or it's a string and you parse the string without knowing if it's a url or not
#
gRegor yeah
#
trwnh not ideal, but i don't know what can be done to improve it really -- simple parsing of p- or u- doesn't include a "type" or some other indicator
#
gRegor Partially why (outside of microformats), things like the authorship spec came about: https://indieweb.org/authorship-spec
#
gRegor Flexibility for publishers, bit more work for consumers
#
trwnh ok i think i might have figured out what went wrong initially while poking around at intentionally breaking my site a bit
#
trwnh https://go.microformats.io/?url=https%3A%2F%2Ftrwnh.com%2Fa is showing that when i use .u-author.h-card that the "url" property isn't getting parsed from the h-card?
#
trwnh i can't remember if that was the original issue i was having a month ago
#
trwnh http://php.microformats.io/?id=20261107234419253
#
trwnh it looks like if you put properties of the embedded h-card, it no longer picks up the implicit url? but it picks up an implicit name still
#
trwnh yeah, i have to explicitly include a child a.u-url element for it to pick up the .h-card .u-url
#
trwnh not sure if that's a bug in mf2 parsing algo or bug in specific implementations of it
#
gRegor will check in just a moment
#
gRegor Right, with that specific markup, since there is a u-* inside the h-card, it will not run implied parsing to get the URL. An example with implied URL parsing working is `<a href="/a" class="h-card">Author</a>`
#
gRegor If you start adding more properties inside the h-card, it probably (usually) makes sense to change the wrapping element from an `a` to something else, like a `div`
#
trwnh it's a clickable name and avatar, so i don't think a div makes sense there
#
trwnh i see the "and no other explicit u-*" part now but it doesn't match my intuition >_<
#
gRegor Something like this http://php.microformats.io/?id=20261107235725648
#
gRegor You can still have the link wrap around the avatar, parsed before I saw that
#
gRegor The main advantage of an `h-card` class on the link itself is if you're doing the minimal parsing with implied properties. When you start publishing more properties inside like the photo, another wrapping element probably makes sense