#microformats 2018-09-12

2018-09-12 UTC
[keithjgrant] and [jgmac1106] joined the channel
#
@onasusweb Pourquoi les microformats sont importants pour la SEO #ecommerce #prestashop #seo #php #webdev #symfony #vuejs #css #javascript #git #woocommerce #opencart #magento https://www.onasus.com/pourquoi-les-microformats-sont-importants-pour-la-seo/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost (twitter.com/_/status/1039697517884198914)
[schmarty], [iambismark], [tantek], gRegorLove, [mrkrndvs], nitinkhanna, hober2, nitot_, indy, [kevinmarks], astilla, [jgmac1106], barpthewire, jgmac1106, jgmac1106_, ben_thatmustbeme, tantek__, dougbeal|mb1, jackjamieson, [keithjgrant], vulpixies and nitot joined the channel
#
sknebel wades through backcompat parsing code
#
KartikPrabhu sknebel: this is for mf2py 127 bug?
#
sknebel yeah
#
KartikPrabhu I'm looking at that too
#
sknebel got a plan to fix it yet?
#
KartikPrabhu no but have an idea why u-url stays https://github.com/microformats/mf2py/blob/master/mf2py/backcompat.py#L157
#
KartikPrabhu since geo is a mf1 root class (at least in the mf2py thing) the u-url does not get removed
#
KartikPrabhu then since a h-geo is added I think it gets parsed as mf2
#
KartikPrabhu and gets the implied name
#
sknebel yeah
#
KartikPrabhu one possible solution to try is to remove "h-geo" from here https://github.com/microformats/mf2py/blob/master/mf2py/backcompat-rules/vcard.json#L84
#
KartikPrabhu which might be added back due to https://github.com/microformats/mf2py/blob/master/mf2py/backcompat-rules/geo.json#L3
#
sknebel I just tried changing the "h-geo" to "geo"
#
sknebel that at first glance works
#
KartikPrabhu since "geo" is never removed, you can probably just delete the "h-geo" and it should work
#
KartikPrabhu this backcompat stuff is very non-local and mf2py is trying to do it in a local way without knowing the whole DOM structure
#
sknebel true, that works too
#
KartikPrabhu I suppose that can be used as a fix unless some other bug comes up
#
sknebel currently thinking if I can come up with something were that'd break
#
KartikPrabhu possibly try some backcompat where "geo" is only replaced by "p-geo" but I don't think that exists
#
KartikPrabhu might want to change and test vevent too https://github.com/microformats/mf2py/blob/master/mf2py/backcompat-rules/vevent.json#L22
#
sknebel yeah, there's a few
#
sknebel review has a bunch
#
KartikPrabhu hmm now I am not sure why the vevent and vcard geo replacements have different formats :P
#
KartikPrabhu vevent has a single string but vcard has two
#
KartikPrabhu I wrote that so I am confused :P
#
sknebel I assumed that was just a mistake
#
KartikPrabhu possibly. they both work exactly the same. so feel free to change around
#
sknebel KartikPrabhu: did you base those json files on those from another parser?
#
KartikPrabhu no basically moved the previously existing built-in rules from mf2py to json and added/edited from spec
#
sknebel ok
#
sknebel e.g. there's rules for latitude/longitude on hentry, wondering where those are from
#
sknebel will check old source then
#
tantek__ spec problems/conflicts or implementation problems/conflicts?
#
KartikPrabhu right now it is implementation I think
#
sknebel okay, longitude/latitude backcompat on hentry was added to php-mf2 long ago ago, in 2014 it was ported to mf2py
#
sknebel gRegorLove removed it from php-mf2 last year
[jgmac1106] joined the channel
#
gRegorLove reads back
#
sknebel (without any special note as far as I can tell)
#
sknebel since it's also not on the wiki, I'd count it as "probably a bug that propagated, should be removed from mf2py"
#
sknebel ah ok, initially it *was* a backcompat rule
#
sknebel but it got removed, and that change wasn't tracked into the parser at the time
#
sknebel http://microformats.org/wiki/index.php?title=h-entry&diff=next&oldid=60791
#
Loqi h-entry
#
KartikPrabhu sknebel: aah ok. I think I didn't go 100% by spec at the time
#
sknebel the commit says it copied the structure from php-mf2, which makes sense
#
KartikPrabhu yeah the initial rules were from php-mf2 but were built into the backcompat.py file. I moved them to the JSON
#
KartikPrabhu the idea being that we have a common set of rules that all parsers could probably use and share
#
KartikPrabhu https://github.com/kartikprabhu/backcompat-rules
#
Loqi [kartikprabhu] backcompat-rules: A set of backwards compatibility rules for parsing microformats.
#
gRegorLove Did I remove something incorrectly?
[eddie] joined the channel
#
sknebel no
#
tantek__ there's a lot of work to do to figure out proper use of geo / lat / long
#
tantek__ and no established consensus (publishing or consuming code) on how
#
tantek__ AFAIK
#
Zegnat The backcompat rules exist, so I assume those came from some sort of need
#
tantek__ sorta. they're a subset of old rules
#
tantek__ I took a best guess based on anecdata - please consider them open to reduction/expansion based on *actual* data
#
tantek__ (I'm especially interested in simplifying / reducing backcompat where we don't need it)
#
gRegorLove Likewise for h-review-aggregate that I'm working on; I reviewed still-published hReview-aggregate examples as a starting point for backcompat
#
tantek__ gRegorLove++ that's the way to do it!
#
Loqi gRegorLove has 27 karma in this channel over the last year (102 in all channels)
#
sknebel oh hm, the hReview backcompat works differently
#
sknebel okay, one fix at a time
#
sknebel hReview might even be worth going back from the json to special-case code...
[jgmac1106] and [eddie] joined the channel
#
KartikPrabhu sknebel: see https://github.com/kartikprabhu/backcompat-rules/issues/1
#
Loqi [kartikprabhu] #1 hreview backcompat
#
KartikPrabhu I don't think there are any publishing cases for the "special" stuff in hReview backcompat unless gRegorLove actually found some
#
gRegorLove hReview or hReview-aggregate?
#
KartikPrabhu hReview. you commented on that issue that you were looking at the examples :P
#
KartikPrabhu long time ago though
#
gRegorLove which issue?
#
gRegorLove ah
#
sknebel KartikPrabhu: thx, excluded that for now
#
sknebel there's few other conditionals too that aren't covered
#
sknebel or maybe not
iwaim joined the channel
#
sknebel not sure about http://microformats.org/wiki/h-entry#Parser_Compatibility "author" right now
#
Loqi [Tantek Çelik] h-entry is a simple, open format for episodic or datestamped content on the web. h-entry is often used with content intended to be syndicated, e.g. blog posts. h-entry is one of several open microformat standards suitable for embedding data in HTML. ...
#
sknebel > "author - including compat root vcard in the absence of h-card"
#
KartikPrabhu right. so "author" -> "p-author h-card"
#
sknebel but that fails on "author vcard"
#
KartikPrabhu yeah. It is a bit strangely worded since all mf2 properties are ignored. So "absence of h-card" part is weird
#
sknebel and if I always insert a "vcard", it fails if it is a plain string
#
KartikPrabhu there is a "vcard" -> "h-card" too so I don't think it breaks anything
#
sknebel or it's at least somewhat ugly -> it produces an empty nested h-card with "value":name
#
sknebel since the name isn't implied in backcompat
#
sknebel so just a plain name string would be the better result
#
sknebel or imply the name in this case (which the php parser does), but I thought was explcitily not a thing in backcompat
#
KartikPrabhu yeah no implied name in backcompat
#
tantek__ correct, not a thing in backcompat
#
tantek__ because it never worked that way for hCard, and if it suddently did it would likely result in a bunch of noise
#
KartikPrabhu right^
#
tantek__ from unexpecting publishers
#
KartikPrabhu might be better to not put the "h-card" in the "author" for hentry backcompat if there are uses-cases which fail
#
sknebel so what's the correct result from https://github.com/microformats/mf2py/blob/master/test/examples/backcompat/hentry.html ?
#
KartikPrabhu sknebel: "correct" according to "spec" or expected?
#
sknebel both?
#
KartikPrabhu I am sure mf2py is doing the spec on this one
#
KartikPrabhu as for "Expected" I have no idea
#
KartikPrabhu though a "p-author" without an additional "h-card" seems better for this case
#
KartikPrabhu but I don't consume a lot of mf1 stuff so <shrug>
#
sknebel but mf2py does imply a name here for the h-card it return
#
sknebel s
#
sknebel since it has the same problem as in #127
#
KartikPrabhu sknebel: yes that is related to the 127 issue
#
sknebel so it doesn't do what the spec says
#
KartikPrabhu right
#
KartikPrabhu one way to "fix" that would be to replace "h-card" here https://github.com/microformats/mf2py/blob/master/mf2py/backcompat-rules/hentry.json#L26 with a "vcard" and then let the "vcard" backcompat do its thing
#
sknebel yes, then you get the empty h-card with only the nested-object "value" containing anything useful
#
gRegorLove Looks like Go parser doesn't add the h-card in that mf2py test linked above
#
sknebel Go doesn't do backcompat at all I thought?
#
KartikPrabhu sknebel: sure. but these are separate issues
#
gRegorLove Ahh
#
gRegorLove That would explain it :)
#
KartikPrabhu issue 1: mf2py is not doing nested backcompat due to these rules. issue 2: is "author" -> "p-author h-card" the expected thing to do
#
gRegorLove Well, it does some... gets h-entry with author, content, and name properties
nitot_ joined the channel
#
sknebel I feel bad adding a fix that produces a worse result in some cases, but true
#
KartikPrabhu sknebel: maybe start an issue on https://github.com/microformats/microformats2-parsing with that example
#
Loqi [microformats] microformats2-parsing: For collecting and handling issues with the microformats2 parsing specification: http://microformats.org/wiki/microformats2-parsing
#
KartikPrabhu mf2py can be easily fixed if it changes
#
sknebel yeah, will open issues tomorrow
[schmarty], tantek__, [jgmac1106] and nitot joined the channel