#microformats 2018-08-20

2018-08-20 UTC
#
willnorris Never bothered to support backcompat until this weekend. Always worried it'd be really complicated, but turned out pretty straightforward
#
tantek__ *phew*
#
willnorris I can't imagine the parsing rules dictating something like closing tags. The encoding thing is super annoying bc it changes the author's original markup, which we shouldn't be doing
#
tantek__ that was the hope willnorris, that we simplified backcompat *enough* make it "pretty straightforward" for a proper mf2 parser
tantek, strugee, loppy2, bradenslen, KartikPrabhu, Skunky9, tantek__, Razesdark and tasse9 joined the channel
#
ben_thatmustbeme wow, i guess the mf2-tester has definitely been useful then :)
#
ben_thatmustbeme just re-ran with the latest go-updates
#
ben_thatmustbeme with my latest branch on the ruby parser i'm at 102 currently (i believe)
#
aaronpk wow that's over 100!
#
Loqi http://meme.loqi.me/m/4w3UnNr7.jpg
#
tantek__ LOQI: Y U MEME THAT?
#
aaronpk :D
[eddie] joined the channel
#
willnorris ben_thatmustbeme: yeah, mf2-tester has most definitely been useful!
#
willnorris ben_thatmustbeme++
#
Loqi ben_thatmustbeme has 2 karma in this channel over the last year (12 in all channels)
#
willnorris mf2-tester++
#
Loqi mf2-tester has 1 karma over the last year
myth0d25, Gizmokid200523, [eddie], barpthewire, n-st10, [pfefferle], Guest81764 and Platonides15 joined the channel
#
Zegnat That output normalisation issue opened by willnorris is interesting. The addition of / on self closing (ie. void) elements for instance is actually a bug: according to the HTML fragment serialization algorithm linked to by the parsing spec those shouldn't be there.
#
Zegnat And there are only 5 symbols that should be &…; encoded: https://html.spec.whatwg.org/multipage/parsing.html#escapingString
#
willnorris Zegnat: you're absolutely right, I hadn't read the fragment serialization algorithm closely enough to catch that. That actually simplifies matters, since it's now clear what the canonical form should be
#
Zegnat It simplifies some things, at least. While we have a strict canonical form, I think people have previously said it isn't always workable simply because the html libs they depend on don't support it.
#
willnorris as for the apostrophe encoding, that's a weird go thing: https://github.com/golang/net/blob/master/html/escape.go#L209
#
Zegnat I'll have to look up previous discussions when I get back in about an hour. About to head out on my daily quest to fetch the post.
#
Zegnat Interesting, willnorris. I wonder why they do that.
[metbril], [pfefferle], [kevinmarks] and barpthewire1 joined the channel
#
Zegnat I made a spec proposal for resolving relative URLs in the HTML value from e-* parsing: https://github.com/microformats/microformats2-parsing/issues/38#issuecomment-414262178
#
Loqi [Zegnat] Because these issues tend to grow stale if there is no concrete proposal, here is one. I propose replacing this line in [the parsing specification for `e-*`](http://microformats.org/wiki/microformats2-parsing#parsing_an_e-_property): > * `html`...
#
sknebel you thought of the attribute list, very good
#
sknebel (noticed yesterday that the parsers that already normalize only handle some cases)
#
Zegnat Yeah, I covered the obvious ambiguity. Who would have thought ;)
#
Zegnat Mostly thanks to my earlier discussion re webmentions and the link extracter that I even cared to think!
adactio, [kevinmarks], [jgmac1106] and [jgarber] joined the channel
#
[jgarber] Good morning! I’m taking a swing at https://github.com/microformats/tests/issues/96 this morning (unless someone else has claimed it already).
#
Loqi [gRegorLove] #96 type and rels arrays must be sorted alphabetically
#
Zegnat I don’t think any of the current PRs do that, so feel free!
#
Zegnat Also, [jgarber], this might interest you as an additional test for the webmention endpoint discovery lib: https://github.com/Zegnat/php-webmention-endpoint-discovery/commit/ebd8f04617503fdc8e9e43133556ac01d4542c52
adactio joined the channel
#
[jgarber] Zegnat: Thanks for the link! Will take a look at that.
#
Zegnat Hi adactio! Tip: you may want to deop yourself (-o) for the time being! Loqi is doing a good job of keeping spam away, but channel operators may still see the first lines of spam before spam bots get kicked.
#
[jgarber] Re: microformats/tests #96, I’ve got the “type” arrays sorted properly. Not sure if it’s too early / pre-coffee, but I’m having trouble wrapping my head around the “rel” component of the updated spec.
#
[jgarber] The examples on micfroformats-2-parsing contain markup that’s properly alphabetized which doesn’t reflect how/what a parser should alpha-sort in the output.
#
Zegnat [jgarber], in rel-urls there will be an object for every link on the page. Those objects contain "rels" properties. Those properties contain an array.
#
Zegnat Those arrays should be alphabetically sorted.
#
Zegnat http://microformats.org/wiki/microformats2-json#rel-urls_Object - "The value object will always contain a member with the name rels. That member’s value will be an array of alphabeticall sorted link relationships applicable to the URL."
#
Zegnat Does that answer your question?
#
[jgarber] Ah, got it!
#
[jgarber] So the change of the spec _does not_ impact the order of items in the top-level “rels” or “rel-urls” objects?
#
sknebel dicts/objects don't have ordering, so no
#
Zegnat Background: the change in the spec was only because JSON doesn’t have a concept of “unordered list”. So we choose to make every unordered list specifically alphabetically ordered. That way all parsers should result in the same thing.
#
Zegnat So top objects are left untouched, just the nested rels arrays get ordered (because they are supposed to be unordered)
[stefp] joined the channel
#
[jgarber] https://github.com/microformats/tests/pull/102
#
Loqi [jgarber623] #102 Sort types arrays alphabetically
#
[jgarber] That _should_ make the requisite updates to the test files to meet the updated spec.
#
Zegnat No rels were out of place?
#
[jgarber] Not that I could find.
#
[jgarber] I’ll check again, but if I’m looking at the right things, most everything was single value.
#
[jgarber] Double-checked in “microformats-mixed” and “microformats-2" and all looks good to me.
#
Zegnat Ah. We might just need extra tests then. Which very well can be the case
KartikPrabhu, [manton], [aaronpk], [tantek], [eddie], [pfefferle], [kevinmarks] and [jgmac1106] joined the channel
#
ben_thatmustbeme just looking back at this... must be sorted alphabetically?!
#
ben_thatmustbeme that seems odd since depending on the library you use to write out, this can be a really annoying requirement that I don't really see any gain to
#
Zegnat In JSON, all arrays are always ordered lists. For most arrays the spec already specified order (order must follow document order the values are discovered in). But there were a few arrays, some based on unordered lists from the HTML spec, that did not specify any expected order.
#
Zegnat https://github.com/microformats/microformats2-parsing/issues/29
#
Loqi [Zegnat] #29 Define the order of items any time an array is used in the parsed output.
jackjamieson and [manton] joined the channel
#
sknebel yeah, that one surprised me too
[jgarber] joined the channel
#
[jgarber] ben_thatmustbeme: Just posted a slew of comments on your microformats-ruby PR. It’s a solid refactoring overall. :thumbsup::skin-tone-2:
#
ben_thatmustbeme there is a bunch more coming if you look at the other branch i'm working on
#
[jgarber] yesssssssss
#
[jgarber] I posted a bunch of comments on that PR and can pitch in on any of the change recommendations if you’d like the assistance.
#
@qubyte ↩️ And if you're a web dev like me, it's extremely satisfying to roll a little static site generator and play with things like microformats and webmentions. (twitter.com/_/status/1031553113583493122)
#
@shadowcat_mst ↩️ With the new microformats stuff for pingbacks that @jmacdotorg has been playing with, I think the idea would be that you'd just post to your own site and then a sufficiently sane client could weave threads together from the feeds. (twitter.com/_/status/1031562305333538822)
tantek, tantek__, jackjamieson, [asuh], KartikPrabhu, [cleverdevil], [deeden], [jgmac1106], [eddie], [Khurt], [manton], [pfefferle], barpthewire, [iambismark], gRegorLove, vivus, [grantcodes], vivus_ and globbot joined the channel
#
ben_thatmustbeme need to start looking at the whitespace in test results
#
ben_thatmustbeme https://github.com/microformats/tests/blob/master/tests/microformats-mixed/h-entry/mixedroots.json#L19
#
ben_thatmustbeme that for example, should not end with \n should it?
#
sknebel yes, whitespace is stripped
#
ben_thatmustbeme i'll start an issue and PR
#
sknebel check https://github.com/microformats/tests/pull/100
#
Loqi [willnorris] #100 trim space on e-* properties
[tantek] joined the channel
#
ben_thatmustbeme oh hah
[Khurt], barpthewire and tantek joined the channel
#
KartikPrabhu ben_thatmustbeme: also see https://github.com/aaronpk/microformats-whitespace-tests
#
ben_thatmustbeme https://ben.thatmustbe.me/mf2tests/ is serving pretty much that purpose for me
#
tantek kinda surprised that's not tests.thatmustbe.me/mf2
#
ben_thatmustbeme i could, just was doing it fast
[eso], tantek__ and [jgarber] joined the channel
#
[jgarber] ben_thatmustbeme++ for cranking on some Ruby library improvements!
#
Loqi ben_thatmustbeme has 3 karma in this channel over the last year (13 in all channels)
[shaners] joined the channel
#
[shaners] See also: https://github.com/microformats/microformats.io/issues/11
#
[shaners] [ben_thatmustbeme] Would you like to put https://ben.thatmustbe.me/mf2tests at test.microformats.io or compare.microformats.io?
#
Loqi [veganstraightedge] #11 Add /compare
#
[shaners] Also, it makes me very happy that other people are contributing to the language specific parser sites. https://github.com/microformats/microformats-parser-website-go/commits/master and https://github.com/microformats/microformats-parser-website-php/commits/master
#
[shaners] [aaronpk]++
#
Loqi [aaronpk] has 14 karma in this channel over the last year (313 in all channels)
[jgmac1106] joined the channel
#
[shaners] @willnorris++
#
Loqi @willnorris has 3 karma in this channel over the last year (4 in all channels)
[chrisaldrich] joined the channel
#
[shaners] If anyone who knows their way around Node wants to work with me on getting node.microformants.io up and working, I’ll happily do the Heroku / Github setup and auto-deploy part. But I need someone else to do the Node part. I know next to nothing about Node Land.
#
[shaners] https://github.com/microformats/microformats.io/issues/18
#
Loqi [gRegorLove] #18 node.microformats.io down
#
[jgarber] If it’s at all helpful, Express is _supposed_ to be akin to Sinatra on the Ruby side and Flask on the Python side… https://expressjs.com
#
[shaners] I know that much. But like, I have zero mental bandwidth for spelunking into another language / framework right now. I’m sure someone who already knows their way around Node could get this up and running much much faster than I could.
#
[shaners] Thanks though [jgarber]
#
Zegnat I am going to do some nodejs stuff (including express) tomorrow. If that turns out well, maybe I can take some time the day after to check out a node site
#
gRegorLove is going through microformats/tests PRs
#
gRegorLove ben_thatmustbeme, What's the h-review-aggregate.value you're expecting for the v1/hproduct/aggregate test? https://github.com/microformats/tests/issues/71#issuecomment-406910238
#
Loqi [gRegorLove] I believe the backcompat for `review hreview-aggregate` should be `p-review h-review h-review-aggregate`. What's the expected `h-review-aggregate.value`?
#
@growdigital @thomasguest microformats for @IndiegoHugo templates are here: https://github.com/growdigital/indiego/tree/master/themes/starter/layouts/partials (twitter.com/_/status/1031661761500512256)
#
@growdigital ↩️ @thomasguest @IndiegoHugo oops, nearly forgot h-entry http://microformats.org/wiki/h-entry (twitter.com/_/status/1031662826597822464)
#
gRegorLove tantek, I'm going to work on expanding /h-review-aggregate from the todo list there. Should I list you as the editor, like on /h-review, or the /hReview-aggregate editors?
#
tantek takes a quick look
#
[shaners] @zegnat Cool. 👍 But to be clear, I’m not suggesting that someone need to make a node site from scratch (if that’s what you meant). I’m suggesting that someone get @glennjones’ existing Node + MF site working (again). And i’ll help Heroku-ize it.
#
[shaners] https://github.com/glennjones/microformat-node
#
Loqi [glennjones] microformat-node: Microformats parser for node.js
#
tantek__ shaners++
#
Loqi shaners has 1 karma in this channel over the last year (5 in all channels)
#
tantek__ gRegorLove: I took a look. Want to list yourself as editor?
#
gRegorLove What responsibilities does that entail? :)
#
gRegorLove tantek: I don't mind, if that's appropriate. I'm intending to copy over previous pages and update with mf2 properties / basic backcompat.
[pfefferle] joined the channel
#
tantek gRegorLove: if anything you'll have to be more conservative with what you bring over, because we are stricter with mf2 properties
#
tantek in particular we may drop properties, and should, when we can't find any document consumers of either the mf1 or mf2 versions
#
gRegorLove Ok. h-review-aggregate is Draft Specification status, right?
#
tantek or at best list them as "proposed" with zero known publishers / consumers
#
tantek yeah we'd start it with draft status
#
gregorlove edited /h-review-aggregate (+4128) "update introduction, draft status, stub sections, copy change control from /h-entry" (view diff)
#
gregorlove edited /h-review-aggregate (+30) "/* Validating */ {{h-spec-section-validating}}" (view diff)
#
tantek gRegorLove: h-review-aggregate is not as mature as h-entry
#
tantek may be better to use change control (if any) in h-review to start with
#
tantek and then we can iterate those two together
#
tantek since they'll likely be used by similar people / sites / consuming apps
#
gRegorLove Ah. yeah /h-review doesn't have a change control section yet
[eddie] joined the channel
#
gregorlove edited /h-review-aggregate () "(-2886) /* Change control */ rm section" (view diff)
#
gregorlove edited /h-review (+2881) "/* See Also */ add change control section" (view diff)
[kevinmarks] joined the channel
#
tantek gRegorLove: point is, neither h-review nor h-review-aggregate (nor most others) are implemented enough to require that level of change control
#
tantek we really want to be more quickly / easily move / drop properties until we see some actual publisher / consuming code uptake *for each property*
#
tantek be more *able to* quickly
#
tantek edited /h-review () "(-2881) change control is for more mature drafts, no need for this much change control for h-review yet - Undo revision 66913 by [[Special:Contributions/GRegorLove|GRegorLove]] ([[User talk:GRegorLove|Talk]])" (view diff)
#
gRegorLove I'm still not super clear on the change control process from our last discussion about experimental `read-of` and `read-status` on h-entry a while back.
KevinMarks joined the channel
#
tantek good reason to limit that change control process to h-entry
#
gRegorLove Sounds good
#
tantek point being, we have more liberty (as editors) to change drafts without explicit change control
#
tantek obviously we should be doing so with the intent/interest of the community
#
tantek just means less bookkeeping of it all
#
tantek the problem with read-of and read-status was not one of change control per se, but more a risk of premature standardization when something hasn't been incubated / reviewed enough
#
tantek and that's a general standardization concern, not specific to our change control process
#
tantek our change control helps us make more well thought out changes, that doesn't mean it is the end all be all of common sense or thinking through larger challenges (vocabulary proliferation)
#
gRegorLove I meant the discussion of those properties led me to review /process and raised some questions. I'll have to go back to the logs; don't remember exactly.
jackjamieson joined the channel
#
gregorlove edited /h-review-aggregate (+1203) "/* Properties */ proposed properties from hReview-aggregate awaiting citations of publishing and consuming examples" (view diff)
davidmead joined the channel