2022-02-03 UTC
sarahd[d], ur5us, jacky, Seirdy, KartikPrabhu, [tonz], [fluffy], hans63us[d], Seb[d], aspenmayer[d], [tw2113_Slack_], [Aaron_Klemm], Jeremiah[d], darkkirb, balupton[d], sknebel, [jgmac1106], IWSlackGateway, [KevinMarks], rattroupe[d], Zegnat, JSharp, gRegor, SemihCebraiL[d] and SemihCebraiL4853 joined the channel
# 13:35 sknebel I think the "for each property in the list" bit could be clearer, even sticking to spec-lang, but I've also not found a good phrasing yet [manton] and jacky joined the channel
# 17:06 jacky (if a URL with a path component that's just "/" should be kept or removed) # 17:07 [tantek] you mean independent of microformats? depends on the context IMO # 17:07 [tantek] if you're displaying it, like for web sign-in, then no need to have a dangling slash on the end of the domain # 17:09 jacky I'm guessing that I should not do any particular massaging there # 17:10 jacky it's happening because anything that happens to be a string and parsed as a `u-` gets represented as a URL internally # 17:11 sknebel I'd argue "do whatever your environment does for URL normalization" and I suspect it'll keep the / # 17:12 sknebel the url normalization in all cases is "new" (i.e. less tan 5 years old) # 17:13 sknebel yes-ish. we dont define what URL normalization means # 17:13 [tantek] "normalized absolute URL of the gotten value, following the containing document's language's rules for resolving relative URLs" # 17:14 jacky the JSON doesn't use a trailing slash at ".items[0].properties.in-reply-to[0].properties.author[0].properties.url[0]" # 17:14 jacky and I should not add a slash (or have my parser avoid adding a slash?) # 17:14 jacky I was confused there for a bit and thought the opposite # 17:15 sknebel what does your environment do for URL normalization? # 17:15 sknebel if you dont add any extra handling, what does happen? # 17:15 sknebel (I assume you're not implementing URL normalization yourself) # 17:16 sknebel but if yours does something different it'd be worth a second look # 17:17 jacky because the standard is saying "A URL’s path is either an ASCII string or a list of zero or more ASCII strings, usually identifying a location." # 17:18 jacky the Rust library for parsing URLs (which is used by Servo) # 17:18 jacky it's adding a trailing / when it's not needed (or provided) # 17:19 sknebel so we and the spec and the lib agree, have the slash # 17:19 jacky okay lol my fault i was confused as to what part of this is wrong lol # 17:20 jacky then in that case, I'll update the JSON file for microformats/tests # 17:20 jacky (unless you mean the test case I'm writing that's incorrect) # 17:22 jacky going to try to run this across more of the tests so I can make this one larger PR versus a bunch of bite size ones jacky joined the channel
# 17:51 [tantek] would normatively referencing the URL spec help make this more clear? cygnoir[d] joined the channel
zachburau[d], gRegor and jacky joined the channel
KartikPrabhu, ben_thatmustbeme, ur5us, jacky and Jack[d] joined the channel
# 21:02 jacky value class datetime parsing is a hell of a trip # 21:31 jacky hm I'm wondering if I should do this with regexes or just convert some of these to be handled by the datetime parser # 21:32 jacky hm well I'd only know what part of it to parse it as if it matches one of those formats # 21:33 jacky prob easier to have regex define what part it's in, combind it in the order of ISO 8601 / RFC 2282 and parse it as that unified strng # 21:41 jacky got some free time to finish up a PR I had # 21:54 [tantek] jacky++ "hell of a trip" yeah, that's basically the result of years of analyzing existing content publishing practices and coming up with markup patterns to match them as well as reduce chances for introducing errors by providing as much ability to stay DRY as possible # 21:55 [tantek] VCP is a good example of something that clearly was not designed theoretically, because it doesn't have a simple clean "look" to it that ultimately fails to actually match real world needs 😉 # 21:57 jacky that's def clear from the examples and the format styles # 21:58 jacky I switched over to rel parsing b/c it was easier # 21:58 jacky wanted to leave the 'hardest' one for last # 23:01 jacky dang, is value-title parsing necessary? (lol) # 23:04 jacky this all kind of sniffs at a need/want to use something like data-* # 23:09 jacky [heh that wasn't that hard to support, lol] # 23:25 [tantek] and yes, for the most part value-title should not be necessary for publishers using HTML5 # 23:25 [tantek] it would be good to go back through all value-title use-cases and redo them using <data> just to present that as a tutorial for folks # 23:25 [tantek] eventually it would be good to deprecate value-title as only being necessary for backcompat # 23:28 [tantek] for the moment we could add some publishing warnings to use <data> instead # 23:29 sknebel I wonder if we have it documented anywhere outside the parsing spec for mf2 # 23:30 sknebel (people always tell me I can't assume that publishers read the parsing spec ... :P) # 23:35 [tantek] less documentation of value-title is ok, if our intent is to deprecate it # 23:39 sknebel right. and yes, the question was if there is documentation where people might stumble over it that needs warnings, or if its "contained" :D gRegorLove_ joined the channel
sknebel actually the json is newer :D https://github.com/microformats/tests/blob/master/tests/microformats-v2/h-entry/impliedvalue-nested.json
[KevinMarks] It is tricky, and easier to use a time element now
jacky what is `YYYY-DDD` supposed to be from https://microformats.org/wiki/value-class-pattern#Date_and_time_parsing
gRegor php-mf2 uses regex, then normalizes it with PHP's datetime lib: https://github.com/microformats/php-mf2/blob/master/Mf2/Parser.php#L241
[tantek] looks like I already added a warning in 2016: https://microformats.org/wiki/value-class-pattern#Parsing_value_from_a_title_attribute