#microformats 2022-06-28

2022-06-28 UTC
Alec, tommorris, Seirdy, sebbu, yukinu[m], gRegor, [snarfed], nathan[m]12345, sebbu2, hpfr, BELGRADIORS[m], jeremycherfas, jacky, angelo, jamietanna, HughRawlinson[m], nathan[m], BELGRADIOSTREAM[, hacdias, [fluffy], [schmarty] and [aciccarello] joined the channel
#
jacky gregorLove++ for merging that PR in
#
Loqi gregorLove has 3 karma in this channel over the last year (5 in all channels)
#
gRegor ended up being no merge, hah. I thought microformats/tests needed updating, but it already had been, we just needed to do that vcp spec update to match :)
jacky joined the channel
#
jacky ahhh
#
jacky okay updating the rust impl to match this (had it open on the personal already)
#
gRegor nice
#
jacky wait so after running that
#
jacky I have https://github.com/microformats/tests/blob/master/tests/microformats-v2/h-event/dates.json failed for me
#
jacky *failing
[Scott_Jack] joined the channel
#
jacky goes to mention on PR
#
gRegor ahh
#
gRegor wait... might not be vcp
#
jacky oh wait
#
jacky oof yeah, it's not
#
jacky heh looks like I might be overloading my date processing
#
gRegor Yeah, that's this comment: https://github.com/microformats/tests/issues/29#issuecomment-406905485
#
Loqi [gRegorLove] Parsing for `h-event/dates.html` test doesn't use VCP, so it's expected to return the `datetime` attribute without normalization. There's a discussion about changing that (https://github.com/microformats/microformats2-parsing/issues/12), ~~but until ...
#
gRegor And the broader discussion about applying VCP to all date-time parsing, which I think is a good idea: https://github.com/microformats/microformats2-parsing/issues/12
#
Loqi [tantek] #12 should dt-* parsing do date and time parsing for all values?
#
jacky (strongly agrees)
#
jacky okay thanks for clearing that up
jacky, Alec, [aciccarello], IWDiscordGateway, IWSlackGateway, [snarfed], [LewisCowles], [tantek], [Scott_Jack], [schmarty], [KevinMarks], [fluffy], [chrisaldrich], strugee, petermolnar, [tw2113_Slack_], gRegor, Harzilein, GWG, cjw6k, phae, JSharp, Kaja, sknebel, ccx, klez, ben_thatmustbeme, saptaks, voxpelli, willnorris and ur5us joined the channel
#
[tantek] sounds like we should shift that issue from being a "should ... ?" to being a proposed change
#
[tantek] so we can at least document that the Rust parser implements the proposed change successfully (having an implementation is one of the requirements for advancing a proposal)
#
[tantek] can we move forward on #4 and/or #8 as preconditions for #12?
#
[tantek] on #4, I'm trying to figure out how to put this in the issue, however I disagree with the line of thinking from Zegnat
#
[tantek] that is, our parsing rules need to be independent of end/start vocabulary
#
[tantek] e.g. should work just as well for updated/published
#
[tantek] and any others that may come up with future
#
gRegor Agreed. I was going to try to implement parsing #12 in php-mf2 as well.
#
gRegor I need to dig into 4 and 8 more still.
#
[tantek] basically we need more (current) parser developers to weigh in on #4 and #8 to give those the thumbs up and/or proof of implementability
#
gRegor php-mf2 does your original proposal from #4, but not Zegnat's later suggestion.
#
[tantek] that would be good to clarify in a follow-up comment