#microformats 2018-01-14

2018-01-14 UTC
# 00:15 
@workforthem Microformats: What They Are and How To Use Them https://www.smashingmagazine.com/2007/05/microformats-what-they-are-and-how-to-use-them/ (twitter.com/_/status/952329617142112257)
[miklb], tantek, [kevinmarks], [joe]1, [chrisaldrich], [eddie], nitot, barpthewire, [colinwalker], ivc, randomstranger, gayboi, chrisaldrich, nitot_, [jeremycherfas], aaronpk_, aaronpk and chimo joined the channel
# 22:52 
aaronpk is the new implied name parsing rule going to fix this situation? https://david.shanske.com/2018/01/14/1774/
# 22:52 
Loqi [David Shanske] Skip to content
David Shanske 
The Definitive Location 
Menu
...
# 22:53 
Zegnat !mf https://david.shanske.com/2018/01/14/1774/
# 22:53 
Kaja https://php.microformats.io/?url=https%3A%2F%2Fdavid.shanske.com%2F2018%2F01%2F14%2F1774%2F
# 22:53 
Loqi [David Shanske] Skip to content
David Shanske 
The Definitive Location 
Menu
...
# 22:54 
Zegnat It should, in that the h-entry should not get a name at all
# 22:55 
KartikPrabhu eh! if h-entry gets no name at all then what does "implied name" even mean?
# 22:55 
Zegnat There is an h-entry with e-content, the fact e-content is explicit will be taken as a sign that the fact name is missing is also explicit.
# 22:55 
Zegnat So the parser should not add a name.
# 22:56 
KartikPrabhu so this will break consumers who use a comparison between name and content-value to figure out if it is a note?
# 22:56 
sknebel no
# 22:56 
Zegnat Oh, hmm, wait, I read the issue wrong.
# 22:57 
sknebel !mf-py https://david.shanske.com/2018/01/14/1774/
# 22:57 
Kaja https://python.microformats.io/?parser=html5lib&url=https%3A%2F%2Fdavid.shanske.com%2F2018%2F01%2F14%2F1774%2F
# 22:57 
Zegnat e-content will not make it skip name implication, but p-author should. Only other p- properties would suppress it, according to the issue.
# 22:57 
Loqi [David Shanske] Skip to content
David Shanske 
The Definitive Location 
Menu
...
# 22:58 
Zegnat KartikPrabhu: https://github.com/microformats/microformats2-parsing/issues/6
# 22:58 
Loqi [tantek] #6 reduce instances when p-name is implied
[kevinmarks] joined the channel
# 22:59 
KartikPrabhu so other p-* properties are skipped in name implication or is name implication itself skipped if there are other p-*
# 22:59 
KartikPrabhu that seems to have been undecided
# 23:00 
KartikPrabhu the latter will break note post-type discovery
# 23:00 
sknebel only if your notes rely on implied names
# 23:00 
Zegnat name implication is skipped when other explicit p- properties are defined (i.e. it is assumed p-name is explicitly left out thus should not be auto-filled)
# 23:00 
Zegnat at least that is how I understood the issue
# 23:00 
KartikPrabhu sknebel: that is what post-type-discovery says afaik
# 23:00 
sknebel if you know a site where that's the case, that'd be good to know
# 23:00 
Zegnat Also, “no "name" property” is a check in Post Type Discovery (https://www.w3.org/TR/post-type-discovery/) so consumers should correctly identify it as a note without needing to compare any name to content
# 23:00 
Loqi [Tantek Çelik] Post Type Discovery
# 23:01 
aaronpk The only reason we need that heuristic in the first place is because name appears in notes due to implied name
# 23:01 
aaronpk it would be so much better if it just didn't appear in the first place
# 23:01 
KartikPrabhu Zegnat: aah nice catch. I had missed that caveat
# 23:02 
aaronpk Actually the only reason we started doing class="e-content p-name" is because leaving off the name class results in an ugly implied name
# 23:02 
KartikPrabhu aaronpk: yes fair enough
# 23:02 
Zegnat I wonder if https://github.com/microformats/microformats2-parsing/issues/6 should extend to “any explicit properties” rather than “any explicit p-* properties”.
# 23:02 
Loqi [tantek] #6 reduce instances when p-name is implied
# 23:03 
[kevinmarks] also because other note systems did that too (eg twitter feeds when they had them)
# 23:03 
aaronpk That was only because Atom requires the name due to its blogging roots
# 23:03 
Zegnat E.g. I can totally have a post with e-content, dt-published, and u-author. But then it would still go and imply a name because I have no explicit p- property.
# 23:03 
Zegnat adds that to the issue
# 23:04 
KartikPrabhu Zegnat: so you are proposing that if there is no property found then imply the name?
# 23:04 
KartikPrabhu is there a use-case where such an implied name is useful?
# 23:05 
Zegnat <a href="example.com" class="h-card">name</a>
# 23:05 
aaronpk Implied name (and photo and url) are useful for the minimal h-cards and things
# 23:05 
Zegnat ^^^
# 23:05 
KartikPrabhu hmmm yeah
# 23:09 
Zegnat Cool, I was able to just use the HTML from my blog. The only p- property in my HTML is the p-name. https://github.com/microformats/microformats2-parsing/issues/6#issuecomment-357550670
# 23:09 
Loqi [Zegnat] Just a thought I just had in chat when I realised `e-content` wasn’t going to stop a `name` property to be implied per @tantek’s proposed new limitation:
> "p-name MUST NOT be implied if there are any explicit p-* properties or any nested micr...
# 23:09 
Zegnat wouldn’t mind severely cutting down on all implied properties
# 23:13 
gRegorLove Definitely in favor of blocking implied p-name if other p-* exist; it's on my mental roadmap for the near future in php-mf2.
# 23:14 
aaronpk Good cause I don't even know where to start with that change :-p
# 23:14 
KartikPrabhu ha!
[miklb] joined the channel
# 23:15 
KartikPrabhu Zegnat's new rule is easier to implement
# 23:15 
aaronpk I know surprisingly little about how the parser actually works
# 23:16 
Zegnat I realised the same limitation aaronpk. I actually sat down and started writing down the algo for VCP because I couldn’t keep it straight any more: https://wiki.zegnat.net/media/mf2dom.html
# 23:19 
gRegorLove php-mf2 keeps objects of properties it's parsed by prefix, so checking if other p- have been parsed is easy.
# 23:20 
Zegnat gRegorLove do you see any reason why we should limit it to p-?
# 23:22 
gRegorLove Longer-term, I don't know. Short-term, it seems like a smaller change that is less likely to cause unexpected results.
# 23:23 
gRegorLove I won't be implementing it too soon, so if the discussion goes that way (broadening it) I'm fine with that.
# 23:24 
gRegorLove I haven't looked over the earlier conversation on the mf wiki either
# 23:25 
Zegnat Note that tantek’s proposed limitation also adds nested h- as a thing that should stop implying a name. So not just p-
# 23:27 
Zegnat If the idea is to put a stop to parser output like that of GWG’s post, seeing any property is probably a sign of markup being nested within the h- and thus a valid reason to not imply name.
# 23:27 
Zegnat But I am off to bed. Will think about it some more. Have a good one all!
# 23:28 
[kevinmarks] hm. There was some value in assuming that a name would always be available, but implying unhelpful ones is less good (like the "a jpg" alt text)
# 23:29 
[kevinmarks] implied names having load of newlines in has always been annoying
# 23:32 
gRegorLove Definitely add examples to https://github.com/microformats/microformats2-parsing/issues/6 where stopping based on *any* other property would be helpful for implied name.
# 23:32 
Loqi [tantek] #6 reduce instances when p-name is implied
# 23:46 
Zegnat Just added Tantek’s home page HTML as another h-entry example that has no explicit p- properties (except for the currently necessary p-name)