#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
#
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!
#
tantek__
LOQI: Y U MEME THAT?
[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
#
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.
#
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
that for example, should not end with \n should it?
#
sknebel
yes, whitespace is stripped
#
ben_thatmustbeme
i'll start an issue and PR
#
Loqi
[willnorris] #100 trim space on e-* properties
[tantek] joined the channel
[Khurt], barpthewire and tantek joined the channel
#
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]
[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]
[aaronpk]++
#
Loqi
[aaronpk] has 14 karma in this channel over the last year (313 in all channels)
[jgmac1106] joined the channel
#
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.
#
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`?
#
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.
#
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