#dev 2017-08-23

2017-08-23 UTC
snarfed, KartikPrabhu, [miklb], ben_thatmustbeme, sknebel, Kaja, Jeena, voxpelli, cweiske, barpthewire, loicm and Zegnat joined the channel
#
Zegnat Really most of the IndieWeb libraries expect HTML with some form of mf to be returned. Not putting an accept header with text/html in there is on us, we should probably encourage people to put that in.
#
Zegnat Most implementations will only ever parse 1 type of response and nothing else, so including */* in the Accept (which is the default if no others are given) is just wrong.
#
Zegnat See https://github.com/indieweb/indieauth-client-php/commit/913fecbb7231d64b59d50ef77b5ad326962ae884
#
snarfed Zegnat: i think the Accept default if unset actually 'text/html, text/plain' or something similar
#
snarfed https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3
#
sknebel https://tools.ietf.org/html/rfc7231#section-5.3.2
#
sknebel "A request without any Accept header field implies that the user agent will accept any media type in response."
#
snarfed right. and from the w3c page: "If no Accept: field is present, then it is assumed that text/plain and text/html are accepted."
#
snarfed which i guess is wrong, since the RFC is the authority. silly w3c.
#
sknebel I think that's an archival page at W3C?
#
snarfed evidently
#
Zegnat Yeah, that doesn't match with what I have seen in practice.
#
Zegnat */* is the default I have noticed
#
cweiske text/plain and text/html are of course in */*
#
cweiske which is why ""If no Accept: field is present, then it is assumed that text/plain and text/html are accepted." is correct
#
rhiaro !tell snarfed: fell asleep mid conversation last night. If implementations are giving up without checking headers they're violating the spec. That's not really my problem
#
Loqi Ok, I'll tell them that when I see them next
#
cweiske.de edited /Tumblr (+18) (view diff)
mblaney joined the channel
#
mblaney except it looks like curl adds the Accept header if not set?
#
mblaney https://github.com/curl/curl/blob/5d9fc28fa760e1b0b7f68fce7ae845f4e659e0fd/lib/http.c#L1725
j12t, [kevinmarks], loicm and tommorris joined the channel
#
cweiske mblaney, after clicking on the "quill" buttons in the "settings" on your site, nothing happens. when I reload, the "like", share and reply buttons appear
#
cweiske they should be there instantly after clicking on "quill"
#
mblaney cweiske yeah I've noticed that too, it's a bug I need to look into. It currently works as you describe in firefox.
j12t, j4y_funabashi, [colinwalker] and barpthewire joined the channel
#
j4y_funabashi what is heroku
#
Loqi Heroku is a platform as a service (PaaS) that supports Ruby, Java, Node.js, Scala, Clojure, Python, PHP and others https://indieweb.org/Heroku
jeremycherfas, j12t, eli_oat and loicm joined the channel
#
cweiske is there a tool that generates an OPML file from /irc-people?
#
cweiske.de edited /OPML (+81) "/* IndieWeb Examples */" (view diff)
#
cweiske.de edited /Tiny_Tiny_RSS (+29) "/* Features */" (view diff)
j12t, [kevinmarks], singpolyma, [barryf], snarfed, jeremycherfas_, gRegorLove, eli_oat and KartikPrabhu joined the channel
#
jeremycherfas.net uploaded /File:vhwc-23-august-2017.png "vHWC meeting, CEST, 23 August 2017 with {{aaronpk}}, {{chrisaldrich}}, {{jeremycherfas}}, {{sketchess}}, {{sknebel}} and {{zegnat}}, https://indieweb.org/File:vhwc-23-august-2017.png"
#
jeremycherfas.net edited /File:vhwc-23-august-2017.png (+0) (view diff)
calumryan, tantek, snarfed and [barryf] joined the channel
#
aaronpk interesting mf2-parsing related issue
#
aaronpk Zegnat has a web page that has a <data> element with u-in-reply-to and a URL
#
aaronpk webmention verification of that fails because there is no link, since data elements aren't links
#
aaronpk but an mf2 parser sees the "in-reply-to" property with a valid URL
#
Zegnat Oooh, is that the reason, webmention requires an actual link. Duh. *facepalm*
#
tantek for good reason! if you're not linking to the thing in a way that is user-activatable, you're doing something weird / not fully visible/usable and your webmention should not be trusted
#
aaronpk yeah that's why telegraph has that extra check. It knows a webmention would fail so it doesn't let you send it
#
Zegnat can’t surpress a smile when someone starts “Zegnat has a web page that …”
#
aaronpk but, the problem is the way telegraph finds potential links to send to is it runst he page through the mf2 parser
#
aaronpk and includes any properties that are URLs
#
Zegnat Interesting problem. The microformats are right, yet I can’t send a webmention to notify someone of the post. Hmm
#
tantek the microformats being "right" just means you're making some data parseable, that's it
[jeremycherfas] joined the channel
#
tantek you can't send a webmention because you don't actually have a link
#
tantek link here meaning *user* concept of a link
#
tantek not just plumbing concept (rando URL in text or elsewhere)
#
aaronpk So my question is should the parser not have returned that property since it's not in a link?
#
aaronpk Once it's parsed I have no way of knowing what element it came from
#
tantek no the parser is following the parsing spec, which says how to extract microformats data in a variety of elements
#
Zegnat Except I think an unfocusable and empty A element would qualify, right? So there is no difference between that and my DATA element.
#
Zegnat You probably shouldn’t be using the mf2 parser at all for a webmention sender?
#
tantek zegnat huge difference - you can read HTML5 spec for details if you like
#
tantek just one for example, all such a href elements are still accessible by screenreading tools
#
tantek for more examples, literally go read the HTML5 spec sections on both elements. VERY different
#
Zegnat Not if I add display:none; most screenreaders will remove that from the tree.
#
Zegnat But HTML parsers are still going to accept them
#
tantek right, per spec
#
Zegnat Still, I find it interesting something will be a mf2 reply but not be accepted for Webmentions. I’ll have to rethink how I post them.
cweiske joined the channel
#
tantek Zegnat: why are you surprised? anything you post should be for human readers first anyway, and machine-reading/parsing second
#
Zegnat Not really. They aren’t in my feed. I post them so they will be parsed by receivers and included in comment threads on the receiver’s end.
#
tantek purely machine-readable (but useless to humans) HTML or mf2 or whatever is no better than all the made up XML from 10+ years ago, or the made-up JSON now.
#
Zegnat And for that purpose, I do not want a clickable link to that post in there.
#
tantek they should be in *some* feed
#
Zegnat They aren’t. Up to the comment displayer if they want feeds for comments. I don’t put all comments I make in my own feed.
#
tantek if you don't have something worth displaying, then it makes no sense for the receiver to link to you
#
tantek one of the biggest points of webmention was to actually specify display and interaction guidelines that provided something useful to users like things that look like comments, instead of the crap UI from trackback/pingback http://indieweb.org/comments-presentation#Previous_specifications_for_display
#
www.boffosocko.com edited /Getting_Started (+2432) "selection of introductory articles and videos for those just getting started" (view diff)
#
Zegnat Hmm, aaronpk, what are the “other similar links” that should be looked for in HTML5 documents? https://www.w3.org/TR/webmention/#webmention-verification
#
Zegnat tantek, I don’t think a reaction like https://licit.li/59982039b97e6 is worth displaying on my site at all. So I don’t include it in my feed. But it still shows up as a comment on someone else’s post and they get notified of it. Which was all I wanted it to do.
#
cweiske tantek, https://www.w3.org/TR/webmention/ requires *nothing* about display of received webmentions
#
Loqi [Aaron Parecki] Webmention
#
tantek cweiske, yes, hence I said *guidelines* not *requirements*
[chrisaldrich] joined the channel
#
cweiske "At this point, the receiver MAY publish content from the source page on the target page or other pages, along with any other data it picks up from the source. For example, the receiver may display the contents of the source as a comment on the post, or may display the author's profile photo in a list of others who have sent similar Webmentions, e.g. showing a list of people who have all "liked" a post."
#
tantek exactly. normative and informative guidelines.
#
cweiske the required parts of the spec itself are the same as pingback, just with www-form-urlencoded instead of xml-rpc
#
cweiske nothing more, nothing less
#
tantek https://chat.indieweb.org/dev/2017-08-23/1503515047441000
#
Loqi [tantek] cweiske, yes, hence I said *guidelines* not *requirements*
#
cweiske and informal parts are non-normative and thus useless
#
tantek https://chat.indieweb.org/dev/2017-08-23/1503514643323000
#
Loqi [tantek] one of the biggest points of webmention was to actually specify display and interaction guidelines that provided something useful to users like things that look like comments, instead of the crap UI from trackback/pingback http://indieweb.org/comment...
#
tantek cweiske, you're assertion "thus useless" is false.
#
tantek s/you're/your
#
cweiske that's maybe your opinion
#
tantek no it's evidence from implementer behavior for decades
#
tantek implementers of W3C specs often code what is for example or informative, and iterations of specs often codify formerly non-normative text when adopted by implementations as normative
#
tantek knowing this, good spec editors / authors will include more subtle points that may be forward looking as informative (non-normative) text, allowing implementers to consider them, and implement (or not) accordingly
#
tantek thereby prompting spec evolution accordingly, guided by implementations over time
#
Zegnat There we go https://github.com/aaronpk/Telegraph/issues/20#issuecomment-324434543
#
Loqi [Zegnat] Upon reading the Webmention spec again, specifically [verification](https://www.w3.org/TR/webmention/#webmention-verification), I agree that my implementation might be wrong. I think Telegraph shouldn’t be using the mf2 parser at all if it only imp...
snarfed and rvid joined the channel
#
vanderven.se martijn edited /Homebrew_Website_Club (+0) "We are true regulars now, thank you to everyone who has made this possible by showing up week after week!" (view diff)
snarfed and arush joined the channel
#
tantek Zegnat++ way to make Virtual EU regular!
#
Loqi zegnat has 28 karma in this channel (129 overall)
#
www.boffosocko.com created /w3schools (+1131) "stub; recommendations for better resources" (view diff)
#
vanderven.se martijn edited /w3schools (+193) "/* See Also */ Historical context: a 2013 version of w3fools.com" (view diff)
snarfed, loicm and KartikPrabhu joined the channel
#
aaronpk i don't know how to reconcile this
#
aaronpk should I just never use an mf2 parser to find outgoing links of a page?
#
snarfed aaronpk: you could make php-mf2/xray optionally return extra data (tag name) in parsed mf2
#
Loqi snarfed: rhiaro left you a message 14 hours, 15 minutes ago: fell asleep mid conversation last night. If implementations are giving up without checking headers they're violating the spec. That's not really my problem
#
snarfed or optionally ignore certain tags
#
aaronpk that seems like something that should be in the microformats spec if so
#
snarfed could be but not necessary if these parser features are opt in
#
aaronpk the reason i wanted to use the mf2 parser to find the links in the first place is i wanted an easy way to not include the footer/header/nav links of a page, just the ones inside a post
#
aaronpk so using the parsed mf2 made sense
snarfed and tantek joined the channel
#
loqi.me edited /Instagram (+77) "aaronpk added "https://www.theatlantic.com/technology/archive/2017/08/link-in-bio/537624/" to "See Also"" (view diff)
#
gRegorLove reads back
#
gRegorLove So Telegraph is only using mf2 to find links to send wm to?
#
aaronpk yeah
#
aaronpk it's actually a feature of mention-client-php
#
gRegorLove Ah, yeah just caught up to the gh issues
snarfed, barpthewire and jjuran joined the channel
#
tantek.com edited /SMS (+924) "make this its own page since there's now much more documentation about how bad SMS is to use with any sort of auth" (view diff)
#
tantek.com edited /messaging (+13) "main SMS" (view diff)
[miklb] and [kevinmarks] joined the channel