#microformats 2017-10-16

2017-10-16 UTC
[miklb], KartikPrabhu, rodolfojcj, [eddie], Phae, bigbluehat, twisted`, nitot, tantek and nitot_ joined the channel
#
@babie microformats…… (twitter.com/_/status/919896649236750336)
nitot, hs0ucy, tantek and [manton] joined the channel
#
@ruhanirabin What are microformats? http://j.mp/2ympBwu https://pbs.twimg.com/media/DMRMHTBUEAAGpYU.jpg (twitter.com/_/status/919943916673105921)
[eddie], KartikPrabhu, tantek, hs0ucy, nitot and [keithjgrant] joined the channel
#
[keithjgrant] Must the h-entry class go on the <body> of the page at the canonical URL? What are the downsides of putting it on an outer <div> instead?
#
aaronpk it can definitely go on any tag you want
#
[keithjgrant] Ok, cool. Thought I had read somewhere it should be on <body>. I'm trying to incorporate some animated page transitions into my redesign. It's easier if I don't have to add/remove classes on the body
#
tantek why?
#
[keithjgrant] ...as I swap out content
#
tantek the body tag is nice because it's singular, and thus maps quite well to "the thing this page is about or represents"
#
tantek as in *the* thing
#
tantek since there is *the* body tag
#
tantek it's a sensible 1:1 mapping
#
aaronpk seems like an insignificant thing to worry about
#
tantek you can use a nested div of course
#
aaronpk since it has no effect on parsing
#
tantek aaronpk - it's close to all the metacrap at the top
#
tantek close(r)
#
tantek so if people are putting a bunch of stuff in their meta, then putting something related on body is nearer and thus more likely to be in sync
#
[keithjgrant] Maybe I'll use a <main>. That implies a singular thing
#
tantek than something deep in a div somewhere
#
aaronpk I'd say that depends on how the HTML is created
#
aaronpk for hand-authored pages that makes sense
#
aaronpk downside of having h-entry on the body is you'll almost never get an implied p-name that makes sense
#
aaronpk so you'll have to always set p-name explicitly
#
[keithjgrant] That makes sense
#
tantek aaronpk - most of the "never get an implied p-name that makes sense" stuff today is due to parsers not keeping up with parsing fixes
#
tantek parsing *spec fixes
#
aaronpk i didn't think any of those fixes would account for that. like if the page has a bunch of navigation or footer stuff, wouldn't that still be included in the implied name?
#
[keithjgrant] Semi-related question: I've noticed Telegraph lists a lot of extraneous links as potential WM targets (like my own home page & avatar URL). Is this b/c it simply lists everything inside my h-entry—currently the <body>
#
tantek aaronpk - there have been a bunch of fixes like if there are any other p-* properties etc.
#
tantek that parsers have not yet implemented
#
tantek a lot of those "mega big implied p-name" cases are fixed in the spec / issues
#
aaronpk [keithjgrant]: Telegraph will look for any microformat value that is a URL, then also parses the content and looks for URLs inside that
#
tantek and if not, we need to file or update an issue and resolve it
#
aaronpk so it's likely finding your author URL from your author h-card
#
sknebel implied name is primarily a long list of "only-child" cases, not sure how those could apply on complex pages
#
tantek exactly
#
sknebel so it'll always fall back to "full text content of .h-x"
#
aaronpk so is this case a parser bug or intentional implied name? https://pin13.net/mf2/?id=20171016195348456
#
sknebel (although with the special rules all scoped to img/area/abbr, they won't apply to a h-entry on a deeper tag either in most cases. but if you leave out author info or tolerate that in the implied name that might be what you want)
#
sknebel I see https://github.com/microformats/microformats2-parsing/issues/6 has the proposal to not include nested microformats, that would help with the author info issue I just mentioned
#
Loqi [tantek] #6 reduce instances when p-name is implied
#
sknebel http://pin13.net/mf2/?id=20171016200102491 (example with added author info and h-entry on div)
#
sknebel forgot author property, so it's a child, but same principle
#
aaronpk even the proposal of omitting child h- objects from the implied name wouldn't solve that since the word "by" is outside the h-card
#
sknebel true
#
sknebel but it's better than with the menu in front at least, I assumed you meant that when you said "downside of having h-entry on the body is you'll almost never get an implied p-name that makes sense"
#
sknebel otherwise I'd say you almost never get one, full stop.
#
aaronpk yeah now that you mention it i dont see how an implied name would ever make sense if you have any nav/footer stuff on the page.
[eddie], rodolfojcj, KartikPrabhu, [kevinmarks], hs0ucy and [miklb] joined the channel