#microformats 2018-01-05

2018-01-05 UTC
webchat109, [eddie], tantek, chrisaldrich, webchat32, HiDeHo-tar, barpthewire, nitot, nitot_, [kevinmarks] and adactio joined the channel
#
Zegnat Some interesting mf on jkphl’s venue site: http://php.microformats.io/?url=https%3A%2F%2Ftollwerkstatt.de%2F
#
Zegnat name on the h-adr, url on the h-geo
KartikPrabhu, barpthewire, webchat16, [kevinmarks], nitot, [keithjgrant] and [miklb] joined the channel
#
@cswordpress @keith_goofball I'm using a theme that supports microformats 2, the Indieweb plugin and its recommended plugins, plus a free service called Bridgy to collect responses and publish. (twitter.com/_/status/949321474355159040)
nitot, KartikPrabhu, webchat106, tantek, gRegorLove, chrisaldrich, [colinwalker] and [cleverdevil] joined the channel; webchat106 left the channel
#
gRegorLove tantek, Is this the discussion you're referring to? https://github.com/microformats/microformats2-parsing/issues/6
#
Loqi [tantek] #6 reduce instances when p-name is implied
#
gRegorLove I wasn't aware of a resolution, but if there is one I'll gladly work on it for php-mf2
#
tantek ok mostly we need implementability feedback from parsers it looks like. I'll clarify a summary proposal
[xavierroy] joined the channel
#
tantek pretty sure this would eliminate all the noisy p-name cases found so far: https://github.com/microformats/microformats2-parsing/issues/6#issuecomment-355632808
#
Loqi [tantek] Restating for clarity, and adding children as another way to stop implying p-name "p-name MUST NOT be implied if there are any explicit p-* properties or any nested microformats"
#
gRegorLove Added the bridgy example
#
tantek my summary proposal should prevent that
#
gRegorLove Yep, that would stop implied p-name for the Bridgy example
#
gRegorLove Sounds good to me currently
#
aaronpk oh yeah I do think that would solve all the noise
#
tantek updated: https://github.com/microformats/microformats2-parsing/issues/6#issuecomment-355632808
#
Loqi [tantek] Restating for clarity, and adding children as another way to stop implying p-name "p-name MUST NOT be implied if there are any explicit p-* properties or any nested microformats" Need consensus positive feedback from parser developers and one p...
[keithjgrant] joined the channel
#
tantek gRegorLove: you're welcome to go ahead and prototype that in php-mf2 to show proof of concept
#
tantek then we just need one more parser developer who likes it
#
tantek and I'll edit the spec
schmarty, sebsel, [colinwalker] and [eddie] joined the channel
#
tantek Zegnat pointed out that <link> elements are not currently parsed for mf2 classes, either in parsers or in the spec
#
tantek which surprised me so I checked and he's right the spec only parses them for rels currently, which also sorta surprised me
#
tantek so I kept digging and found http://microformats.org/wiki/microformats2-parsing-issues#link_elements_and_u-_parsing
#
Loqi microformats2-parsing-issues
#
tantek which seems to indicate that we thought we were done editing the spec according to the resolution of that issue, but obviously the edits were incomplete / unsaved or something else happened
#
tantek so I'm fixing now
#
Zegnat (btw: +1 on not constantly implying p-name values, implied values give some of the hardest to explain edge cases in all of mf2.)
#
tantek Zegnat can you comment / thumbs-up on the GH issue? (or did you already?)
#
Zegnat Thumbed it up.
#
Zegnat Is there any reason we can’t start u- parsing with “if .u-x[href], then get the href attribute”? I.e. not limit to tag names at all?
#
Zegnat href is only on a, area, base, and link elements.
#
tantek yes because that will overmatch
#
tantek there is plenty of weird/crap markup out there
#
tantek and we don't want to match that on base
#
tantek base is special in how href works
#
tantek overmatching is a general category of antipatterns in parsers / parsing specs
#
tantek another example of that is the p-name noise
#
tantek is also caused by overmatching a condition
#
tantek beyond the use-cases it was intended to solve
#
tantek always better to limit your spec/code to the use-cases
#
Zegnat Might be true. I am not sure what href would do on elements that don’t support them anyway, so I am not sure I see the harm.
#
Zegnat But limiting to a, area, and link is fine too
#
tantek exactly, you don't know the potential harm, until it's too late
#
Zegnat (See https://github.com/Zegnat/php-linkextractor/blob/develop/src/LinkExtractor.php#L32-L51 for HTML attributes that accept URLs.)
#
tantek that's what happened with p-name
#
tantek also insufficient, as that's designing-by-plumbing (what some other spec has as a feature set) rather than designing-by-use-case
#
Zegnat Ha, I didn’t remember we were still accepting URLs from abbr[title]. That’s such a bad pattern.
#
tantek huh wat
#
Zegnat “else if abbr.u-x[title], then return the title attribute”
#
tantek by the way, authoring consistency is a good reason to keep a spec internally consistent though, so for example, adding link[href] support to u-* requires also adding link[title] support to p-* parsing
#
tantek as part of supporting mf2 parsing of <link> elements
#
Zegnat Makes sense, tantek
#
tantek Zegnat I'll have you double-check my edits to see what I'm talking about
#
tantek edited /microformats2-parsing (+63) "/* parse an element for properties */ actually incorporate 2015-01-20 resolution to link elements and u- parsing, equivalent link[title] for p-" (view diff)
#
tantek that one ^^^ :)
#
Zegnat Makes sense to me.
#
Zegnat Do we then need to extend implied parsing with <link> too? E.g. <link class="h-card" title="Tantek" href="http://tantek.com">. Not sure why anyone would want to do that, but it is an option for <a> elements...
#
Loqi Tantek Çelik
#
tantek Zegnat - possibly, if someone actually starts using <link> to link to other people
#
tantek e.g. using <link> rel with XFN
#
tantek which is already supported by the parser
#
tantek I'd rather ask to document examples of that first before considering it for the parser, especially since its an implied properties use-case
#
tantek still - go ahead and file a feature request issue for it
#
Zegnat Yeah, XFN was one of the usecases that came to mind. But I personally have no plans using it in that way. Just doesn’t feel like a real valid use-case.
#
tantek so we can track it
#
Zegnat Will file the issue. Will also add that I am personally ambivalent on the matter. Important to get it logged as a thing even if I am not pushing for a change :)
#
tantek at least to capture our thinking at the time
#
tantek and gives others a chance to add their data/experience
#
tantek Zegnat, ok now that the parsing spec is updated consistent with that <link> resolution - want to try it in a parser and if it doesn't work file a bug on the parser like mf2py or php-mf2?
#
gRegorLove Was just going to request that :)
#
Zegnat I will do that in about an hour or so. I actually have a page already that I could link.
#
tantek good catch regardless.
#
tantek Zegnat, if you like, since I think this was all discussed / resolved befre you got here, you could review http://microformats.org/wiki/microformats2-parsing-issues for anything else might "surprise" you either in terms of expectations or what the spec does vs does not
#
Loqi microformats2-parsing-issues
#
Zegnat That’s one. https://github.com/microformats/microformats2-parsing/issues/14
#
Loqi [Zegnat] #14 Should the specification imply properties for <link> elements?
webchat149 joined the channel; webchat149 left the channel
#
Zegnat I might go through the issues and compare those that are “resolved” to the spec, this weekend, tantek. In case anything else didn’t make it for whatever reason :)
#
tantek that would be very helpful, to start with the http://microformats.org/wiki/microformats2-parsing-issues#resolved set first then
#
Loqi microformats2-parsing-issues
#
tantek and then there's only 10 left that possibly have extra work, but could use a fresh perspective: http://microformats.org/wiki/microformats2-parsing-issues#issues
#
Loqi microformats2-parsing-issues
#
Zegnat I should have a moment this weekend. Unresolved issues should probably just be officially moved to the GitHub repo.
#
Loqi yea!
#
Zegnat If anyone wants to test parsers, https://vanderven.se/martijn/big5.html has a rel-canonical that is also u-url. PHP parser on php.microformats.io definitely doesn’t pick it up.
#
Loqi Big Five personality traits
#
Zegnat I have to finish another project first, I’ll do some more testing and then bug filing later tonight
[kevinmarks], chrisaldrich, KartikPrabhu and [eddie] joined the channel
#
aaronpk the first mention of microformats on twitter was from @biz http://ctrlq.org/first/69178-microformats/
#
aaronpk https://twitter.com/biz/status/29925
#
Loqi [@biz] Listening to a talk about microformats
KartikPrabhu joined the channel
#
tantek that was this talk! http://microformats.org/wiki/events/2006-09-13-future-of-web-apps-microformats
#
Loqi events/2006-09-13-future-of-web-apps-microformats
#
aaronpk should add @biz under "attending" :P
#
tantek totally doing that
#
aaronpk aw the mp3 is gone
#
tantek check archive.org
#
aaronpk wow you were doing full-screen JS HTML slides way before it was cool
#
aaronpk darn, the only references archive.org has is a redirect
#
tantek um, I kinda invented it at SXSW in 2003. I might have stayed up nearly all night the night before the talk
#
tantek edited /events/2006-09-13-future-of-web-apps-microformats (+51) "attending: Biz Stone" (view diff)
#
aaronpk omg they have it at the redirected url!
#
tantek ooh can you fix it?
#
tantek (on the wiki page)
#
aaronpk yep
#
aaronpk what's the copyright on that file?
#
tantek not sure who ended up buying FoWA but I thought I asked my talks to be CC
#
aaronpk edited /events/2006-09-13-future-of-web-apps-microformats (+108) "/* Details */ replace with archive.org link to play mp3" (view diff)
#
tantek ok I'm pretty happy that that HTML preso slide deck still works well
#
aaronpk i'd like to upload that mp3 directly to archive.org so it's not just buried in a wayback machine URL
#
tantek that seems legit
#
tantek pretty sure I gave that talk before I joined Twitter
#
tantek yes the slides are CC and usually when I do that I ask the organizer of the event to make any recordgings CC
#
aaronpk oh jeez it made an ugly URL based on the filename that I uploaded
Zegnat joined the channel
#
aaronpk trying again
#
aaronpk here we go https://archive.org/details/2006-09-13-microformats-best-practices-tantek
#
aaronpk edited /events/2006-09-13-future-of-web-apps-microformats (+46) "/* Details */ replace with version uploaded to archive.org" (view diff)
#
tantek amazing
#
[kevinmarks] Nice
#
[kevinmarks] S3 (which is what that slide tool became) ended up being the basis of Presently, that became Google Slides
#
tantek (easter-egg: you can hear me state I'm checking into dodgeball "let me send my dodgeball" at 00:25 and because I'm pretty sure I just txted "@FOWA" to the dodgeball SMS, I could/type it with one hand on my blackberry and put it right back in my pocket
#
[kevinmarks] Though that is now in some weird proprietary format
#
tantek why is Google Slides so bad now then?
#
[kevinmarks] Same reason as Google docs. They user tested it against ms Office with office users and so ended up with a cloned ui
#
[kevinmarks] We had a wiki to S3 tool at Technorati
gRegorLove, chrisaldrich and [eddie] joined the channel