2023-08-25 UTC
eitilt, angelo, Loqi, GWG, ehmry, plantroon, gRegor, btrem and [jacky] joined the channel
[tantek], btrem, SigmundurM, [david], barnaby and eitilt joined the channel
# 22:07 [jacky] gets into the plumbing of implying a name for an item # 22:14 jkingweb By the way I wrote a bunch of tests for that, if it helps. # 22:15 [jacky] nice! I did see your PR about that (gregorLove brought them up) # 22:15 [jacky] I've been using the main branch but I'm down to flip over the Rust library to experiment with this once the current suite is fixed 🎉 # 22:16 jkingweb (I also have even more tests in another branch) # 22:27 [jacky] Is "Mon May 16 20:41:45 2022" a valid timestamp to use in MF2 parsing?! # 22:27 [jacky] this has been tripping up the parser as it thinks it's not a timestamp and uses it as its _name_ 😆 # 22:28 barnaby it’s pretty much the only part of the spec where you have to care exactly what the values you’re dealing with are # 22:28 [jacky] I'm tempted to do a little hack and check if the potential name matches an associated dt name value 😆 # 22:29 [jacky] I _can_ do something to catch this format, which isn't a big deal but I'd want to put it behind a parsing flag # 22:30 [jacky] okay it's not but the parser's using the inner text of the element _as_ the name (great) # 22:33 gRegor Ah. yeah it should use the `datetime` attribute on that, not the innertext # 22:38 [jacky] For some reason, it's not skipping the `time` element when extracting the text 🤔 # 22:43 [jacky] Guessing I should ignore any children that have a property class name in its name as well # 22:44 jkingweb Is this for implied name, or something else? # 22:45 barnaby I haven’t looked at the parsing spec for a while, but last I remember names are not implied for items which have explicit properties # 22:45 jkingweb That microformat should have no implied name, because it has an e-content property. # 22:46 [jacky] 🔔 then that means this is doing this too early like vika mentioned earlier # 22:46 jkingweb > if no explicit "name" property, and no other p-* or e-* properties, and no nested microformats, # 22:46 barnaby probably, yep. last time I worked on the PHP parser, deriving implied properties were one of the last stages # 22:48 barnaby hmm that’s true. I’m not sure if that’s just a parsing spec oversight, or if we ever made a specific decision about it. I’d err on the side of leaving the text content of child dt-* elements in, as the name will probably make more sense with them than without # 22:49 barnaby I wonder what use cases there are for implied name on items with explicit dates # 22:49 [jacky] I can see the case of `<div class="h-entry">soon it will be <time datetime="$TOMORROW_DATE" class="dt-published">tomorrow</time></div>` needing to be parsed as "soon it will be tomorrow" # 22:50 [jacky] hm okay this is an order issue thing, that I can shift # 22:50 barnaby true, it could be useful for minimal event markup # 22:53 [jacky] (the names match the files used in `microformats/tests` for ease of discovery
jkingweb By the way I wrote a bunch of tests for that, if it helps.
[jacky] because this doesn't comply with https://microformats.org/wiki/datetime-design-pattern#Code
gRegor Yeah, that minimal case should get the text inside <time> as part of textContent: http://php.microformats.io/?id=20230825232021587