/irc-logs / freenode / #microformats / 2014-12-30 / end

Options:

Previous day, Next day

  1. # Session Start: Tue Dec 30 00:00:00 2014
  2. # Session Ident: #microformats
  3. # [00:07] * Quits: KartikPrabhu (~kartik@nsit-dhcp-205-208-056-199.uchicago.edu) (Ping timeout: 245 seconds)
  4. # [00:29] * Quits: @tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  5. # [01:32] * Joins: KartikPrabhu (~kartik@nsit-dhcp-205-208-056-199.uchicago.edu)
  6. # [01:40] * Quits: KartikPrabhu (~kartik@nsit-dhcp-205-208-056-199.uchicago.edu) (Ping timeout: 245 seconds)
  7. # [01:43] * Quits: gRegor` (~me@71.201.46.159) (Ping timeout: 255 seconds)
  8. # [02:05] * Joins: gRegor` (~me@71.201.46.159)
  9. # [02:30] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  10. # [02:39] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
  11. # [02:39] * ChanServ sets mode: +o tantek
  12. # [02:54] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  13. # [03:09] * Quits: elux (~peter@TOROON633VW-LP130-03-1088934044.dsl.bell.ca) (Quit: Bye!)
  14. # [03:11] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  15. # [03:43] <Loqi> [[microformats2-parsing-issues]] http://microformats.org/wiki/index.php?title=microformats2-parsing-issues&diff=64733&oldid=64587&rcid=101100 * Tantek * (+1066) /* issues */ resolve one implied property issue, and add another about implied properties on backcompat parsing unlikely to be intended
  16. # [03:49] <@tantek> !tell KartikPrabhu, kylewm, barnabywalters, tommorris I've added/resolved a couple of microformats2 parsing issues, please review and comment so I can close and update parsing spec accordingly: http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_on_backcompat_parsing_unlikely_to_be_intended
  17. # [03:49] <Loqi> Ok, I'll tell them that when I see them next
  18. # [03:51] <KartikPrabhu> tantek: examples of such unintended implied property parsing would be good, to see what we are dealing with
  19. # [03:51] <Loqi> KartikPrabhu: tantek left you a message 1 minute ago: I've added/resolved a couple of microformats2 parsing issues, please review and comment so I can close and update parsing spec accordingly: http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_on_backcompat_parsing_unlikely_to_be_intended
  20. # [03:51] <@tantek> KartikPrabhu: ah - I should link to the indiewebcamp h-entry page
  21. # [03:52] <Loqi> [[microformats2-parsing-issues]] http://microformats.org/wiki/index.php?title=microformats2-parsing-issues&diff=64734&oldid=64733&rcid=101101 * Tantek * (+90) /* implied properties on backcompat parsing unlikely to be intended */ add examples citation
  22. # [03:52] <@tantek> KartikPrabhu: done
  23. # [03:52] <@tantek> I presumed you were following the discussion in #indiewebcamp about aaronpk complaining about all the "fixing" his code has to do for bad h-entrys which turned out to be bad hentrys
  24. # [03:55] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  25. # [03:55] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  26. # [04:05] <@tantek> KartikPrabhu: ^^^
  27. # [04:06] <kylewm> I wonder if there is code out there that assume the implied properties are always available
  28. # [04:06] <Loqi> kylewm: tantek left you a message 17 minutes ago: I've added/resolved a couple of microformats2 parsing issues, please review and comment so I can close and update parsing spec accordingly: http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_on_backcompat_parsing_unlikely_to_be_intended
  29. # [04:06] <kylewm> I think I have written some actually
  30. # [04:07] <@tantek> that seems like an easy patch
  31. # [04:07] <kylewm> definitely, actually the implied properties make a lot more sense to me now
  32. # [04:07] <kylewm> they're there for the convenience of the publisher, not the consumer
  33. # [04:07] <@tantek> right
  34. # [04:07] <kylewm> i thought it was the other way around originally
  35. # [04:08] <kylewm> tantek: is it valuable to comment on the wiki if i am just +1'ing your proposal?
  36. # [04:09] <@tantek> it is absolutely. readings/reviews are greatly valuable.
  37. # [04:11] <KartikPrabhu> oh interesting the implied name seems to be the main culprit so far... would be interesting to tackle this
  38. # [04:13] <@tantek> precisely - and I'm not seeing any value from the implied URL or photo for classic microformats, and since such implying didn't originally exist for classic microformats, it seems the conservative (lease surprise) thing to do is to not imply anything for any classic microformats
  39. # [04:13] <@tantek> that is the burden of proof is demonstrate use-cases / real world examples of *existing* classic microformats markup that benefits from implying anything - as any *new* markup would simply be done with microformats2
  40. # [04:14] <@tantek> thus the default path (lack evidence either way) would be to drop implying for classic microformats
  41. # [04:20] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-yxshkwzjnqcsnqwm) (Ping timeout: 258 seconds)
  42. # [04:21] * Joins: Atamido_ (~atamido@2602:306:839b:7790:15a9:df09:9b06:e6b6)
  43. # [04:22] <Loqi> [[microformats2-parsing-issues]] http://microformats.org/wiki/index.php?title=microformats2-parsing-issues&diff=64735&oldid=64734&rcid=101102 * Kylewm * (+238) /* implied properties on backcompat parsing unlikely to be intended */
  44. # [04:22] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-pudafwdrmbdathbl)
  45. # [04:22] * Quits: Atamido (~atamido@2602:306:839b:7790:15a9:df09:9b06:e6b6) (Ping timeout: 258 seconds)
  46. # [04:22] * Atamido_ is now known as Atamido
  47. # [04:27] <@tantek> thanks kylewm. hoping for confirmation from at least one more parser developer and then I'm happy to make the change (but be open to others raising exceptions if they think of any)
  48. # [04:28] <KartikPrabhu> tantek: I am assuming it is better to have consumers not get an implied property and do their own fallbacks instead of giving "false positives"?
  49. # [04:29] <@tantek> rather, the occurance of implied property false positivies is likely to approach 100% for classic microformats
  50. # [04:33] <KartikPrabhu> yes
  51. # [04:33] <kylewm> the second proposal is a little more radical isn't it? http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_when_an_explicit_class_is_provided
  52. # [04:36] <kylewm> I'm thinking like <a class="h-card" href="http://example.com"><img class="u-photo" src="http://example.com/logo.png"/> Example User</a>
  53. # [04:37] <kylewm> oh wait, I get it
  54. # [04:42] <kylewm> tantek: could you change "elements that have explicit class property names" to "nested elements ..." so there is no confusion about e.g. <a class="p-author h-card" href="http://example.com">Example User</a>
  55. # [04:42] <@tantek> ah, would "child elements" be enough to cover this?
  56. # [04:46] <kylewm> oh, yes? I don't know the semantic difference between nested and child in this case
  57. # [04:46] <@tantek> child implies one level of depth
  58. # [04:47] <@tantek> either way it's going to be a summary of what the parsing algorithm specifically says
  59. # [04:47] <@tantek> which currently uses CSS selector syntax to illustrate how to find elements to imply properties from
  60. # [04:48] <@tantek> I plan to add to those some form of :not(.p-*,.u-*,.dt-*,.e-*) to indicate that none of those class name matches may occur on elements used to imply properties
  61. # [04:59] <Loqi> [[microformats2-parsing-issues]] http://microformats.org/wiki/index.php?title=microformats2-parsing-issues&diff=64736&oldid=64735&rcid=101103 * Tantek * (+56) /* implied properties when an explicit class is provided */ clarify inside root element
  62. # [07:09] * Quits: @KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
  63. # [07:54] * Quits: gRegor` (~me@71.201.46.159) (Ping timeout: 240 seconds)
  64. # [08:08] * Quits: reidab (~reidab@198.61.197.81) (Quit: "poof.")
  65. # [08:09] * Joins: reidab (~reidab@198.61.197.81)
  66. # [09:03] * Joins: kez_ (~quassel@inet2.evalesco.com)
  67. # [09:08] * Quits: kez_ (~quassel@inet2.evalesco.com) (Ping timeout: 244 seconds)
  68. # [09:08] * Joins: kez_ (~quassel@inet2.evalesco.com)
  69. # [09:15] * Quits: kez_ (~quassel@inet2.evalesco.com) (Ping timeout: 264 seconds)
  70. # [09:15] * Joins: kez_ (~quassel@inet2.evalesco.com)
  71. # [09:21] * Joins: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be)
  72. # [09:30] * Quits: kez_ (~quassel@inet2.evalesco.com) (Ping timeout: 272 seconds)
  73. # [09:30] * Joins: kez_ (~quassel@089144193188.atnat0002.highway.a1.net)
  74. # [09:38] * Joins: kez__ (~quassel@inet2.evalesco.com)
  75. # [09:39] * Quits: kez_ (~quassel@089144193188.atnat0002.highway.a1.net) (Ping timeout: 256 seconds)
  76. # [09:58] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  77. # [09:58] * ChanServ sets mode: +o KevinMarks_
  78. # [09:59] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  79. # [10:14] * Quits: @KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
  80. # [10:18] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  81. # [10:19] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  82. # [10:19] * ChanServ sets mode: +o KevinMarks_
  83. # [10:28] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  84. # [10:31] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  85. # [10:39] <Loqi> [@GulzarHedworth] hreview Rich Snippets for your WordPress theme - Yoast (http://twtr.io/uZjG6uzpps)
  86. # [10:39] * Quits: myfreeweb (~myfreeweb@gateway/tor-sasl/floatboth) (Ping timeout: 250 seconds)
  87. # [10:45] * Quits: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be) (Ping timeout: 255 seconds)
  88. # [10:47] * Joins: myfreeweb (~myfreeweb@gateway/tor-sasl/floatboth)
  89. # [11:39] * Quits: kez__ (~quassel@inet2.evalesco.com) (Ping timeout: 245 seconds)
  90. # [11:41] * Joins: kez_ (~quassel@inet2.evalesco.com)
  91. # [11:48] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  92. # [11:50] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  93. # [12:22] * Joins: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be)
  94. # [14:02] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: No route to host)
  95. # [14:03] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  96. # [14:45] * Joins: kez__ (~quassel@inet2.evalesco.com)
  97. # [14:46] * Quits: kez_ (~quassel@inet2.evalesco.com) (Ping timeout: 244 seconds)
  98. # [14:56] * Quits: Erkan_Yilmaz (~Erkan_Yil@wikimedia/Erkan-Yilmaz) (Quit: Verlassend)
  99. # [15:17] * Quits: myfreeweb (~myfreeweb@gateway/tor-sasl/floatboth) (Remote host closed the connection)
  100. # [15:18] * Joins: myfreeweb (~myfreeweb@gateway/tor-sasl/floatboth)
  101. # [15:36] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  102. # [15:37] * Joins: TallTed (~Thud@63.119.36.36)
  103. # [15:55] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  104. # [16:08] * Quits: prtksxna (~prtksxna@116.74.73.132) (Quit: My Mac has gone to sleep. ZZZzzz…)
  105. # [16:09] * Joins: gRegor` (~me@71.201.46.159)
  106. # [17:08] * Quits: kez__ (~quassel@inet2.evalesco.com) (Remote host closed the connection)
  107. # [17:12] <Loqi> [@Xclusive_pikin] Add Google Rich Snippets to WordPress with Author hReview http://kevineze.com/add-google-rich-snippets-wordpress-author-hreview/?utm_source=ReviveOldPost (http://twtr.io/u_KaybAMWf)
  108. # [17:44] <Phyks> how should I consume a h-feed with missing properties ?
  109. # [17:44] <Phyks> for instance if it has no title, is it correct to assume the feed's title is the page title ?
  110. # [17:45] <Phyks> generally speaking, is their an "algorithm" to parse h-feeds / h-entries with not all the properties filled ?
  111. # [17:46] <Phyks> tantek: for instance, your h-feed has an empty p-name on this page http://tantek.com
  112. # [17:47] <@tantek> phyks I thought I'd fixed that
  113. # [17:48] * Quits: @KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
  114. # [17:48] <@tantek> oh right - empty - deliberately
  115. # [17:48] <@tantek> <span class="p-name"></span>
  116. # [17:48] <Phyks> why ?
  117. # [17:48] <@tantek> because I didn't think it needed one
  118. # [17:49] <Phyks> but in this case, if I import your feed in a reader, it won't have any title associated
  119. # [17:49] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  120. # [17:49] <Phyks> then, the user will have to manually add one
  121. # [17:49] <Phyks> am I wrong ?
  122. # [17:49] <@tantek> don't know - depends on the reader
  123. # [17:50] <@tantek> so many legacy readers are so broken in so many ways that I've mostly given up on them
  124. # [17:50] <@tantek> these days people's actual "feeds" that people "use" have no feed name
  125. # [17:50] <@tantek> e.g. your Twitter profile has no feed name
  126. # [17:50] <@tantek> your Facebook profile has no feed name
  127. # [17:50] <@tantek> the whole notion of "requiring" a feed name is obsolete
  128. # [17:50] <@tantek> and antiquated
  129. # [17:50] <Phyks> but a standard RSS / ATOM feed has one
  130. # [17:51] <@tantek> right, antiquated legacy
  131. # [17:51] <Phyks> I'm thinking of h-feeds more like rss feeds than new silos' feeds
  132. # [17:51] <@tantek> popular "feeds" from a UI perspective no longer have any name
  133. # [17:51] <@tantek> new silo UI matters more than old plumbing requirements
  134. # [17:51] <Phyks> in fact, I'm wondering how to consume properly feeds in my reader
  135. # [17:51] <@tantek> people certainly care more about new silo UI than old plumbing
  136. # [17:52] <@tantek> by their usage patterns
  137. # [17:52] <Phyks> the user should be able to identify which entry comes from which feed, no ?
  138. # [17:52] <@tantek> no - because the notion of a "feed" is now irrelevant. it's just people.
  139. # [17:52] <@tantek> from the UI perspective, the separate notion of a "feed" is dead
  140. # [17:52] <@tantek> you follow people, not feeds
  141. # [17:52] <Phyks> true…
  142. # [17:52] <@tantek> hence drop the RSS / Atom assumptions
  143. # [17:52] <@tantek> they're obsolete
  144. # [17:53] <Phyks> so you think I should present the feed via an associated author and not an associated title ?
  145. # [17:53] <@tantek> right
  146. # [17:53] <Phyks> but same thing for author, it is not always associated to feed, I think
  147. # [17:53] <@tantek> that would be following the successful UI model that silos have paved
  148. # [17:53] <Phyks> (because AFAIK no properties are mandatory in h-feeds)
  149. # [17:54] <@tantek> correct - no properties are mandatory
  150. # [17:55] <@tantek> by design
  151. # [17:55] <@tantek> you can't require publishers to publish something they don't want to
  152. # [17:55] <@tantek> the entire methodology of requiring any properties is flawed
  153. # [17:56] <Phyks> but one should be able to rely on some properties for consumption, no ?
  154. # [18:06] <@tantek> no - it's an unreasonable expectation of a publisher to *rely* on any property.
  155. # [18:06] <@tantek> corrolary - consuming code MUST handle any missing property in some intelligent way for its user interface.
  156. # [18:07] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  157. # [18:57] * Quits: TallTed (~Thud@63.119.36.36)
  158. # [19:23] * Quits: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be) (Ping timeout: 272 seconds)
  159. # [19:44] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Read error: Connection reset by peer)
  160. # [19:44] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  161. # [19:44] * ChanServ sets mode: +o KevinMarks_
  162. # [20:02] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  163. # [20:50] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Quit: Leaving.)
  164. # [20:51] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  165. # [21:27] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Quit: Leaving.)
  166. # [22:03] * Joins: Erkan_Yilmaz (~Erkan_Yil@wikimedia/Erkan-Yilmaz)
  167. # [22:16] * Joins: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net)
  168. # [22:19] * Joins: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be)
  169. # [22:19] * Joins: TallTed (~Thud@63.119.36.36)
  170. # [22:32] * Quits: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be) (Ping timeout: 244 seconds)
  171. # [22:40] * Quits: KartikPrabhu (~kartik@108-69-72-147.lightspeed.cicril.sbcglobal.net) (Ping timeout: 240 seconds)
  172. # [22:50] * Quits: TallTed (~Thud@63.119.36.36)
  173. # [22:57] * Joins: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be)
  174. # [23:00] * Joins: KartikPrabhu (~kartik@nsit-dhcp-205-208-056-199.uchicago.edu)
  175. # [23:34] * Quits: eschnou (~eschnou@185.172-65-87.adsl-dyn.isp.belgacom.be) (Ping timeout: 258 seconds)
  176. # [23:40] * Quits: @tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  177. # Session Close: Wed Dec 31 00:00:00 2014

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn