IRC Log for #microformats on 2008-06-24

Timestamps are in UTC.

  1. [00:04:56] <mfbot> [[events/2008-06-23-weekly-meetup-dinner]] * Tantek * (+171) add Pownce and Upcoming URLs and venue to details
  2. [00:05:57] <mfbot> [[events/2008-06-23-weekly-meetup-dinner]] M * Tantek * (+0) fix dates
  3. [00:06:43] <mfbot> [[events/2008-06-23-weekly-meetup-dinner]] * Tantek * (+4414) events/2008-06-23-weekly-meetup-dinner moved to events/2008-06-24-weekly-meetup-dinner
  4. [00:08:54] <mfbot> [[events]] * Tantek * (+39) fix date, add Pownce url to weekly dinner meetup
  5. [00:12:22] * singpolyma ( Quit ("Lost terminal")
  6. [00:15:31] * vbgunz (n=vbgunz@ Quit (Remote closed the connection)
  7. [00:24:51] * charlenopires (n=charleno@ Quit (Read error: 104 (Connection reset by peer))
  8. [00:26:57] * jonnys1234 ( Quit (Read error: 110 (Connection timed out))
  9. [00:38:45] * purp (n=jmeyer@ has joined #microformats
  10. [00:40:58] * pjkix (n=pkhalil@ Quit (Read error: 110 (Connection timed out))
  11. [00:41:32] * purp__ ( has joined #microformats
  12. [00:43:55] * purp__ ( Quit (Read error: 104 (Connection reset by peer))
  13. [00:44:00] * cygri (n=cygri@ Quit ()
  14. [00:44:08] * purp__ (n=jmeyer@ has joined #microformats
  15. [00:44:33] * purp (n=jmeyer@ Quit (Read error: 104 (Connection reset by peer))
  16. [00:46:04] * shigeta (n=shigeta@ has joined #microformats
  17. [00:54:16] * purp_ (n=jmeyer@ Quit (Read error: 110 (Connection timed out))
  18. [01:07:59] <mfbot> [[user/AngeloGladding]] N * AngeloGladding * (+64)
  19. [01:08:10] <mfbot> [[user/AngeloGladding]] * AngeloGladding * (+4)
  20. [01:08:21] <mfbot> [[user/AngeloGladding]] * AngeloGladding * (-2)
  21. [01:21:18] * danja ( has joined #microformats
  22. [01:21:18] <jibot> danja is Danny Ayers,
  23. [01:23:59] * danja ( has left #microformats
  24. [01:43:50] * dw (n=dw@unaffiliated/dw) Quit ("*click*")
  25. [01:43:54] * dw ( has joined #microformats
  26. [01:51:31] * KevinMarks (n=KevinMar@nat/google/x-91f0732d283c0198) Quit ("The computer fell asleep")
  27. [01:53:46] * ianloic ( has joined #microformats
  28. [02:32:02] * danja ( has joined #microformats
  29. [02:32:02] <jibot> danja is Danny Ayers,
  30. [02:57:56] * SunWuKung ( Quit ()
  31. [03:08:08] * Danny_B (n=Danny_B@wikimedia/Danny-B.) Quit ("Did anybody see myself? Who opened door to nowhere?")
  32. [03:16:14] * Danny_B (n=Danny_B@wikimedia/Danny-B.) has joined #microformats
  33. [03:23:36] * pat-in-wv ( has joined #microformats
  34. [03:24:00] * pat-in-wv ( has left #microformats
  35. [03:25:58] * danja ( Quit ()
  36. [03:57:29] <mfbot> [[events/2008-06-24-weekly-meetup-dinner]] M * Tantek * (+0) attending
  37. [04:14:09] * purp__ (n=jmeyer@ Quit ()
  38. [05:08:32] * csarven ( Quit ("")
  39. [05:28:13] * veeliam (n=veeliam@ has joined #microformats
  40. [06:19:36] * bergie ( has joined #microformats
  41. [06:19:36] <jibot> bergie is lives in Finland and blogs at and Midgard CMS developer
  42. [06:27:06] * dw (n=dw@unaffiliated/dw) Quit (Read error: 110 (Connection timed out))
  43. [06:52:35] * dw ( has joined #microformats
  44. [06:55:26] <mfbot> [[blog-quote-examples]] * TobyInk * (+1489) Additional Thoughts / Improvements - "wrote" is bad link text
  45. [07:03:39] * dw (n=dw@unaffiliated/dw) Quit ("*click*")
  46. [07:09:27] * rmarkwhite (i=rmarkwhi@gateway/tor/x-a04011433d30a251) has left #microformats
  47. [07:16:08] * bogdanlazarsb ( has joined #microformats
  48. [07:17:27] * drewinthehead ( Quit (Read error: 110 (Connection timed out))
  49. [07:20:59] * SunWuKung ( has joined #microformats
  50. [07:33:13] * dw ( has joined #microformats
  51. [07:35:01] * OsRo ( has joined #microformats
  52. [07:37:41] * NatBat (i=568eef7c@gateway/web/ajax/ Quit (" ajax IRC Client")
  53. [07:48:29] * drewinthehead ( has joined #microformats
  54. [07:48:29] <jibot> drewinthehead is the author of hKit and a developer at
  55. [07:48:29] * ChanServ sets mode +o drewinthehead
  56. [07:49:53] * bogdanlazarsb ( has left #microformats
  57. [07:49:58] * levitation[A] ( Quit (Excess Flood)
  58. [07:56:15] * levitation[A] ( has joined #microformats
  59. [08:01:25] * trovster ( has joined #microformats
  60. [08:01:25] <jibot> trovster is a web developer from the UK who writes on and helps with
  61. [08:01:55] * MrTopf ( has joined #microformats
  62. [08:03:17] * MrTopf ( Quit (Read error: 104 (Connection reset by peer))
  63. [08:03:23] * MrTopf ( has joined #microformats
  64. [08:09:41] <mfbot> [[hcalendar-examples-in-wild]] * Tantek * (+285) added Squid List specific event pages.
  65. [08:11:03] * jonnys1234 ( has joined #microformats
  66. [08:16:17] <mfbot> [[hcalendar-examples-in-wild]] * Sadtuna * (+9) suboptimal date end tag fixed
  67. [08:28:01] * NatBat (i=568eef7c@gateway/web/ajax/ has joined #microformats
  68. [08:28:01] <jibot> NatBat is Natalie Downe and can be found online at
  69. [08:33:02] * Phae ( has joined #microformats
  70. [08:33:02] <jibot> Phae is Frances Berriman of
  71. [08:33:23] * ChanServ sets mode +o Phae
  72. [08:35:49] <mfbot> [[events/2008-06-24-weekly-meetup-dinner]] M * Tantek * (+0) fix postal-code
  73. [08:38:55] <mfbot> [[events]] M * Tantek * (+0)
  74. [08:54:07] * BenWard (n=BenWard@nat/yahoo/x-b6f1dab782d3d7da) has joined #microformats
  75. [08:54:07] <jibot> BenWard is a Web Developer at Yahoo! Europe and an admin at and based in the UK and better defined at
  76. [08:54:07] * ChanServ sets mode +o BenWard
  77. [09:02:11] * emrojo (n=emrojo@ has joined #microformats
  78. [09:17:35] * KevinMarks ( has joined #microformats
  79. [09:20:54] * NatBat (i=568eef7c@gateway/web/ajax/ Quit (" ajax IRC Client")
  80. [09:35:10] * julianstahnke ( has joined #microformats
  81. [09:35:10] <jibot> julianstahnke is a German front-end dev for and lives in London and wants a play button next to every mentioning of an audio track on the internet
  82. [09:53:22] * CloCkWeR1 ( has joined #microformats
  83. [10:42:56] * riffraff ( has joined #microformats
  84. [10:43:18] * myakura ( has joined #microformats
  85. [10:44:36] <riffraff> hi everyone
  86. [10:45:51] * mn_francis (n=mn_franc@nat/yahoo/x-95cc89936f0a91f5) has joined #microformats
  87. [10:45:51] <jibot> mn_francis is a web developer for Yahoo! Europe; is his personal site
  88. [10:46:40] * cygri (n=cygri@ has joined #microformats
  89. [11:06:44] * bogdanlazarsb ( has joined #microformats
  90. [11:11:16] * bogdanlazarsb ( has left #microformats
  91. [11:40:52] * pat-in-wv ( has joined #microformats
  92. [11:40:52] * pat-in-wv ( Quit (Remote closed the connection)
  93. [11:56:03] * NatBat (i=568eef7c@gateway/web/ajax/ has joined #microformats
  94. [11:56:03] <jibot> NatBat is Natalie Downe and can be found online at
  95. [12:01:13] * cygri (n=cygri@ Quit ()
  96. [12:07:35] * bogdanlazarsb ( has joined #microformats
  97. [12:10:12] * vbgunz (n=vbgunz@ has joined #microformats
  98. [12:11:13] * bogdanlazarsb ( has left #microformats
  99. [12:11:35] * OsRo ( Quit ()
  100. [12:16:34] * shigeta (n=shigeta@ Quit ("Leaving...")
  101. [12:21:29] * cygri (n=cygri@ has joined #microformats
  102. [12:31:30] <Phae> Did anyone read this yet?
  103. [12:32:39] <drewinthehead> yup
  104. [12:34:33] <Phae> just heads up
  105. [12:34:51] <Phae> we need to keep an eye on this stuff. we have a great opportunity here.
  106. [12:35:03] <drewinthehead> I get most frustrated when the ISO date time format is referred to as 'gibberish' when in fact it's quite the opposite.
  107. [12:35:12] <Phae> sure
  108. [12:35:23] * pat-in-wv ( has joined #microformats
  109. [12:35:28] * pat-in-wv ( has left #microformats
  110. [12:37:14] <drewinthehead> The irony of the whole thing is that the ISO format is the most accessible way of publishing date information that I can think of.
  111. [12:37:29] <drewinthehead> It's international and completely unambiguous.
  112. [12:38:05] <drewinthehead> Yet people shy away from publishing it in the name of 'accessibility'.
  113. [12:38:19] <Phae> indeed.
  114. [12:38:33] <drewinthehead> BUT
  115. [12:38:39] <Phae> uhoh
  116. [12:38:48] <drewinthehead> I think we should just completely scrap the ABBR pattern
  117. [12:38:57] <Phae> agree.
  118. [12:38:59] <drewinthehead> despite the fact there's very little wrong with it
  119. [12:39:11] <drewinthehead> it's too much of a distraction
  120. [12:39:28] <Phae> i was startign to say last night, that i'm most in favour of freeing things up. if the abbr is the right job for the task, go ahead, use it.. but if a publisher doesn't think it is, we should offer them another way
  121. [12:39:41] <drewinthehead> it's holding everything else back and preventing progress.
  122. [12:39:45] <Phae> agree
  123. [12:40:17] <Phae> also mike put a post on teh general bbc blog:
  124. [12:40:24] <Phae> not sure that's that wise. most readers don't know about mfs
  125. [12:40:54] <Phae> anyway. distraction.
  126. [12:40:55] <drewinthehead> I don't know Michael, but from the post it doesn't sound like he really understands the issue.
  127. [12:41:56] <drewinthehead> there's no compulsion to use abbr-pattern - it's not require for hCalendar. removing hCalendar because you don't want to use abbr-pattern is - well - weird.
  128. [12:41:57] <mfbot> [[datetime-design-pattern]] * AshSearle * (+309) Machine-data in class -
  129. [12:42:30] <drewinthehead> anyway.
  130. [12:43:55] <drewinthehead> my reservation with using a data- class name is that the data is hidden .. which is contrary to our core design principals
  131. [12:44:08] <Phae> yeah, i've been talking to some people about that
  132. [12:44:12] <Phae> i can uderstand the concern
  133. [12:44:22] <Phae> but also appreciate the need for the data and not displaying it
  134. [12:45:48] <drewinthehead> i wonder if we can approach this from the other angle, and specify a more acceptable date format that people would be more willing to use in their pages
  135. [12:45:48] <mfbot> [[datetime-design-pattern]] * Phae * (+94) Machine-data in class -
  136. [12:45:58] <Phae> oops. didn't sign off properly.
  137. [12:46:19] <mfbot> [[datetime-design-pattern]] M * Phae * (+12) Machine-data in class -
  138. [12:46:37] <Phae> but then we risk changing publishing behaviour too much
  139. [12:46:49] <Phae> it shouldn't be up to us to dictate what they want to display, necessarily
  140. [12:46:52] <drewinthehead> we embrace difficult data problems (like names) in other places ... why not dates and times?
  141. [12:47:19] <Phae> suppose
  142. [12:48:25] <mfbot> [[datetime-design-pattern]] M * Phae * (+78) Machine-data in class -
  143. [12:49:32] <drewinthehead> <span class="dtstart"><span class="day">1</span>st <span class="month" lang="en">March</span> <span class="year">2008</span></span>
  144. [12:50:23] <Phae> i can hear the cries of code bloat already.
  145. [12:50:28] <Phae> altho it has it's merits.
  146. [12:50:39] <Phae> (i liek the lang)
  147. [12:50:41] <drewinthehead> month names are the tricky bit
  148. [12:51:19] <drewinthehead> i'm not sure how much of an issue that really is for a parser
  149. [12:51:40] * andr3 (n=andr3@ has joined #microformats
  150. [12:51:43] <Phae> so, what would you do if someone just writes "Tuesday 9th" - no year etc.?
  151. [12:51:46] <Phae> expand that?
  152. [12:53:44] <drewinthehead> i wonder if the same rules as authorship could be applied
  153. [12:53:51] <drewinthehead> bubble up to find context
  154. [12:54:48] <drewinthehead> i'm trying to think if it's even reasonable to assume that if there's no year it means the current year ... in the context of a web page.
  155. [12:55:20] <drewinthehead> or if we coupled that with a microformat for expressing the date of a document
  156. [12:56:26] <drewinthehead> really just brainstorming here (and I'm not the best person for this sort of stuff) but just thinking about tackling the problem from the other direction, rather than assuming ISO date format is a must.
  157. [12:57:35] <Phae> nono, i can see what you're saying.
  158. [12:57:43] <Phae> it's tricky though.
  159. [12:58:40] <Phae> if i publish "on tuesday 9th, I'm going to Drew's house" you can probably guess, because it's natural language, that I probably mean the 9th of this month, unless I'd previously mentioned "during August".
  160. [12:59:51] <Phae> right. gotta run to team meeting. i'll probably spend the hour chewing on this though.
  161. [12:59:54] <Phae> bbs
  162. [13:02:41] <drewinthehead> yeah it's tricky.
  163. [13:05:08] * bogdanlazarsb ( has joined #microformats
  164. [13:05:16] * bogdanlazarsb ( Quit (Client Quit)
  165. [13:05:36] * bogdanlazarsb ( has joined #microformats
  166. [13:06:51] * bogdanlazarsb ( has left #microformats
  167. [13:08:24] * andr3 (n=andr3@ Quit ()
  168. [13:13:20] <drewinthehead> as ever, i think we need to go back to in-the-wild examples of use to determine how that might be best tackled.
  169. [13:14:19] <drewinthehead> the answer to code bloat, of course, is to use an ISO date. can't have our cake and eat it.
  170. [13:18:27] * DanWrong (i=fwuser@ has joined #microformats
  171. [13:18:42] <drewinthehead> we'd need to look at the cases where hcalendar appears and see which of those both are likely to use natural language syntax and are outside of a dateable context.
  172. [13:18:58] * DanWrong (i=fwuser@ Quit (Client Quit)
  173. [13:19:05] * DanWrong (i=fwuser@ has joined #microformats
  174. [13:21:34] <drewinthehead> something like "I'm having an open house on Saturday" in the context of a blog post could be put in context of an absolute date, but we still don't know if that's past or future, even though it's a relative date.
  175. [13:22:19] <drewinthehead> it's not an easy problem, which is why associating an ISO datetime with everything was a much simpler option
  176. [13:25:23] <drewinthehead> interesting side-thought. hcalendar items posted inside an hAtom post give us an interesting insight as to whether the event was future or past at the time of posting. nice.
  177. [13:51:53] * andr3 (n=andr3@ has joined #microformats
  178. [13:53:20] <mfbot> [[datetime-design-pattern]] * TobyInk * (+153) Machine-data in class -
  179. [14:11:36] <BenWard> drewinthehead: Month names do cause issue; what does someone do when writing French? We end up with the same broken problem we have with ‘cell’ and ‘mobile’ in US and GB English
  180. [14:12:21] <drewinthehead> BenWard: I don't argue it's sticky :)
  181. [14:13:05] <BenWard> Whilst I'm not too fussed about whether we go the class-based or hidden-element-title based solutions currently proposed, I do rather think that the root problem to be solved is that of having to embed machine-data for parsers.
  182. [14:14:01] <BenWard> The accessibility of dates is a distraction, caused from machine data that shouldn't have been exposed to users in the first place.
  183. [14:15:11] * csarven ( has joined #microformats
  184. [14:15:11] <jibot> csarven is Sarven Capadisli
  185. [14:16:10] <drewinthehead> I'm not sure how much of a problem converting month names would actually be ... it's easy to conclude it's hard but it would be worth looking into. building a parser with support for english, french, spanish, german etc built in would be trivial. Also reaching out to a web service for translation of a month string is also trivial if the @lang was a lang I didn't have built-in
  186. [14:17:14] <drewinthehead> BenWard: the converse is that we hide things, which is against a core design principal
  187. [14:17:43] <andr3> how about portuguese? how about dialects? my point being... how will you control which languages should be supported? one parser supports X, Y and Z, while other only X...
  188. [14:17:55] <andr3> (sorry for intruding :) )
  189. [14:18:34] <drewinthehead> andr3: i'm talking about including some languages for performance and using translation services for anything else.
  190. [14:18:48] <drewinthehead> (as an example, in a brainstorm)
  191. [14:19:18] * drewinthehead is finding to be responding *very* slowly at the moment.
  192. [14:19:34] <andr3> drewinthehead: just so I understand... where would these strings end up? title=""?
  193. [14:20:05] * Phae is back
  194. [14:20:07] <drewinthehead> andr3: no, in the text of the page
  195. [14:20:22] <drewinthehead> my example was <span class="dtstart"><span class="day">1</span>st <span class="month" lang="en">March</span> <span class="year">2008</span></span>
  196. [14:20:56] <andr3> thanks for providing that.
  197. [14:20:58] <andr3> i see..
  198. [14:23:46] <andr3> to me, this feels weird. you're helping the parsers by putting those spans around the values but then you leave it up to them to make sense of the real value...
  199. [14:24:04] <BenWard> Sorry, had to duck out for a sec there. The other part of this debate I find frustrating is the described internationalisation benefit of ISO dates over localised ones drives me mad. It seems to be a complete red herring in the issue.
  200. [14:24:14] * azazul (n=azazul@ Quit ("Leaving")
  201. [14:26:07] <andr3> i fail to see the benefit of this, as well. i actually like the ability of providing an alternative rendering of my date... this doesn't help me making it in an accessible way...
  202. [14:26:09] <mfbot> [[datetime-design-pattern]] * DrewMcLellan * (+711) Machine-data in class - - objections to removing 'data-' prefix.
  203. [14:27:33] <BenWard> I mean, yes 2008-07-01 is decipherable the world over, but no-one publishes like that and no-one's going to start. We are interested in what people do publish, so why is an internationalisation benefit of changing their behaviour relevant to us? I don't get it.
  204. [14:28:29] <csarven> BenWard Localised convention is only compromised in the case of machine-readable-data no?
  205. [14:29:12] <andr3> If you're gonna start supporting free language representations of months, you're going to have to support abbreviations, since many people publish months that way... Jan. Feb. etc. So for each language you have lots of variations...
  206. [14:29:19] <csarven> and partially in @title
  207. [14:29:29] <BenWard> Oh, you mean the machine readable data itself? Ah well, that makes sense to be a universal pattern, yes.
  208. [14:29:59] * andr3 is confused... lol
  209. [14:30:28] <drewinthehead> I'm just keen to explore alternatives to using ISO date so that dates can be used without the author feeling they need to hide it.
  210. [14:30:52] <BenWard> But it depends which debate we're having. If we're talking ‘how do we mark up dates without negatively impact pages, users, etc.’, then the internationalisation thing is irrelevant, because we don't want to change what is visibly published.
  211. [14:30:53] <drewinthehead> rather than looking for new ways to hide data - especially when hiding data is evil.
  212. [14:30:56] <andr3> that reminds me of what does...
  213. [14:31:44] <BenWard> If we're talking about techniques for embedding all machine-data in microformats — which is a problem that extends beyond dates and times — then I supposed internationalisation is relevant to what those formats are, but not to how they are embedded.
  214. [14:32:21] <BenWard> I have a feeling that different people are debating both issues in the same space, which is probably the cause of some of the problem here
  215. [14:32:40] <drewinthehead> I wasn't aware that there was a problem here :)
  216. [14:33:30] <BenWard> Well, both the existing proposals (invisible title [moar lol, etc.], and data- prefix class) solve data embedding generically.
  217. [14:33:56] <BenWard> Be that dates and times, or fixed enumerations
  218. [14:33:58] <andr3> BenWard agreed
  219. [14:34:17] <BenWard> But, that is getting mixed in with talk of how to just fix dates
  220. [14:34:18] <drewinthehead> Using easily parsable dates has failed because a) authors don't want to show their readers unambiguous dates and b) we don't want to hide data because it violates a core microformats design principal.
  221. [14:34:39] <drewinthehead> Therefore we need to find a way to parse dates people DO publush
  222. [14:34:42] <drewinthehead> publish :)
  223. [14:34:59] <andr3> ok drewinthehead , i can see the motivation behind the effort. :)
  224. [14:35:34] <andr3> i just can't see any "easy" solution out of this.
  225. [14:35:42] <BenWard> I'm not sure we are violating that principal. We're duplicating data for machines because they require a specified format (be they dates, or decimal co-ordinates, or keywords like ‘cell’)
  226. [14:35:51] <BenWard> And it's an exceptional case.
  227. [14:36:13] <BenWard> That's not to say I disagree with better representing dates so that data doesn't have to be included for human and machine separately
  228. [14:36:15] <andr3> for example, I can see people starting to try to hide dates in english, while presenting dates in ______ (insert language) because 90% of parsers don't support their language
  229. [14:36:34] <BenWard> But that's how we do it now, and we misuse ABBR for much of it.
  230. [14:36:40] <drewinthehead> andr3: it's certainly not easy, but that doesn't mean we shouldn't explore it. not all problems are easy to solve.
  231. [14:37:06] <andr3> drewinthehead: you're right. :)
  232. [14:37:30] <Phae> i'm agreeing it's an idea worth exploring, however, this looks like a very significant piece of research and development time, and we're now in a sticky situation where we're over a year from hAccessibility and still haven't "solved" or eradicated the basic abbr accessibility issue
  233. [14:37:50] <Phae> and i'm kind of inclined to aim for the quicker win NOW
  234. [14:37:55] <Phae> and work on better expressing dates after
  235. [14:38:08] <Phae> because I don't feel we should let this sit any longer
  236. [14:38:46] <andr3> agreed. this issue alone hinders discussions on microformats as general, unfortunately.
  237. [14:38:53] * Phae mumbles and complains.
  238. [14:38:55] * cygri (n=cygri@ Quit ()
  239. [14:39:02] <Phae> yeah. it's a massive hurdle at the moment
  240. [14:39:18] <Phae> and i've got practical implementors on my back (sorry boss) begging for a solution.
  241. [14:39:33] <andr3> people are starting to look at rdfa to solve problems we set ourselves to solve.
  242. [14:39:42] <Phae> yeah.
  243. [14:40:10] <andr3> Phae, yea, I'm preparing to give a training session early July and I can feel the embarrassment when the slides on datetime DP show up
  244. [14:40:13] <Phae> i hate to be sensationalist, but this one thing.. this abbr business.. is giving us a bad rep, and it's undeserved, but it's resolvable
  245. [14:40:38] <andr3> though drews' effort is more than valid. :) is needed, even.
  246. [14:40:47] <Phae> so i'd really like us to put our efforts into a non-abbr solution
  247. [14:40:52] <Phae> get that out the door
  248. [14:40:55] <BenWard> I'm nervous to be motivated by ‘doing it quickly’
  249. [14:41:01] <Phae> then we can put effort into making dates, specifically, easier to parse
  250. [14:41:07] <Phae> i know, i know. i appreciate that
  251. [14:41:07] <andr3> picking up what I said earlier... have you seen what does with dates?
  252. [14:41:15] <Phae> i mean "as quickly as possible, but maintaining quality"
  253. [14:41:17] <drewinthehead> from a parsing point of view, nothing is quick
  254. [14:41:24] <Phae> i don't want us to have another abbr on our hands
  255. [14:41:25] <BenWard> Fact is, as I've found just trying to do the parsing rules for the value-excerption-pattern —without invisible embedding — it still takes time and shouldn't be rushed
  256. [14:41:32] <Phae> i know.
  257. [14:41:36] <BenWard> BUT
  258. [14:41:40] <Phae> i just don't want to be here having this conversation this time next year
  259. [14:41:43] <Phae> which we're liable to
  260. [14:41:44] <BenWard> A ‘datetime’ microformat is a separate effort
  261. [14:41:50] <Phae> yes
  262. [14:41:51] <BenWard> I think
  263. [14:42:11] <andr3> yes, i wasn't pushing for a resolution before date X... we need to think about this and have research done to avoid further complications
  264. [14:42:17] <Phae> quite.
  265. [14:42:31] <BenWard> Whereas what we have at the moment is our existing behaviour — ISO dates, decimal co-ords, etc. — which isn't supported by the ABBR pattern that some people intended it to be.
  266. [14:43:02] <BenWard> So longer term, having a proper datetime microformat makes sense, short term we've got a mechanism that got stretch beyond it's spring.
  267. [14:43:12] <Phae> absolutely
  268. [14:43:32] <andr3> yes
  269. [14:43:42] <BenWard> And swapping it for a _well thought out and specified_ replacement, but which still operates in the core same way, makes more sense than redeveloping every separate issue of data failure.
  270. [14:44:01] <Phae> yep, that's my feeling too
  271. [14:44:51] <BenWard> As regards the issue of hiding data, I would be in favour of making the new pattern opt-in on a per property basis. So it can't be used to hide miscellaneous data, just those where we specify the format.
  272. [14:45:21] <BenWard> I'll add that to my value-excerption-pattern-issues page, actually.
  273. [14:45:27] <andr3> you're concerned with misuses, right?
  274. [14:45:30] <drewinthehead> a quick solution is to change any examples that use abbr-pattern to use raw in-page data.
  275. [14:45:55] <BenWard> That's the quickest solution, yes. But that doesn't suit all publishers either.
  276. [14:46:19] <BenWard> The BBC have graded-browser-support-esque behaviour, so hiding with stylesheets isn't a solution for them.
  277. [14:46:19] * pawel314 ( has joined #microformats
  278. [14:46:24] <drewinthehead> No, but that gives them what they're asking for. (mwhahah)
  279. [14:46:54] <BenWard> Both the current solutions — ABBR and visible data — are documented on /wiki/machine-data
  280. [14:47:20] <drewinthehead> we should consider doubling up any example that uses abbr with an example that doesn't use it.
  281. [14:47:44] * mn_francis_ (n=mn_franc@nat/yahoo/x-943e9c5dd7a71a5f) has joined #microformats
  282. [14:47:48] <drewinthehead> many authors won't get as far as /wiki/machine-data
  283. [14:48:24] <BenWard> Indeed
  284. [14:48:46] * mn_francis (n=mn_franc@nat/yahoo/x-95cc89936f0a91f5) Quit (Read error: 104 (Connection reset by peer))
  285. [14:49:01] <BenWard> machine-data will be a better publicised page once we're stable of some of the issues that come out of it. I documented it mostly for benefit of µf devs at this point
  286. [14:50:40] <drewinthehead> there's only one example without abbr-pattern on /wiki/hcalendar-examples and it's a fugly one
  287. [14:51:01] <Phae> heh
  288. [14:55:00] * myakura ( Quit ("Leaving...")
  289. [14:55:40] * emrojo (n=emrojo@ Quit ("Leaving.")
  290. [14:55:47] <BenWard> This might be of interest to those interested in pursuing a datetime-microformat:
  291. [14:56:58] * BobJonkman (n=BobJonkm@ has joined #microformats
  292. [14:57:11] * trovster ( Quit ()
  293. [14:57:39] * trovster ( has joined #microformats
  294. [15:02:27] <BenWard> Anywya, I'm off to see Radiohead now. So I shall bid you all farewell for now :-)
  295. [15:02:39] <Phae> have fun :)
  296. [15:02:59] <drewinthehead> cheerio
  297. [15:03:12] * BenWard (n=BenWard@nat/yahoo/x-b6f1dab782d3d7da) Quit ()
  298. [15:03:24] <andr3> cya, have fun.
  299. [15:03:54] <andr3> i'm off too.
  300. [15:04:03] <andr3> later
  301. [15:04:07] * andr3 (n=andr3@ Quit ()
  302. [15:04:16] <Phae> well, i think i ruined that conversation anyway. i think the date stuff has tons or merit.
  303. [15:05:17] <drewinthehead> it's a big task, and only applies to dates, leaving the generic problem unsolved
  304. [15:05:23] <Phae> yep.
  305. [15:05:38] <drewinthehead> data- class names would be simplest
  306. [15:06:04] <drewinthehead> but subject to data-rot
  307. [15:06:16] <Phae> i know. i realise the main "issue" now which had passed me by. the hidden data arguement. i just believe in this case it's the lesser evil.
  308. [15:06:49] <Phae> pragmatism first.
  309. [15:07:59] <drewinthehead> it at least shouldn't introduce any new problems, and could work alongside any future solution
  310. [15:08:38] * Phae nods.
  311. [15:09:07] <Phae> mkaply has had the most reservations. i wonder if he's awake ;)
  312. [15:09:17] <mkaply> yes
  313. [15:09:20] <Phae> hi :D
  314. [15:09:28] <drewinthehead> (and as if by magic...)
  315. [15:09:31] <Phae> heh
  316. [15:09:47] * pat-in-wv ( has joined #microformats
  317. [15:09:58] <mkaply> I love it when people write pseudocode and just say "you just do it like this"
  318. [15:10:07] <mkaply> Like it's the easiest thing in the workld to do
  319. [15:10:29] <Phae> ah, yeah
  320. [15:10:38] <drewinthehead> mkaply: in respect to data- classnames?
  321. [15:10:44] * CloCkWeR1 ( Quit (Read error: 104 (Connection reset by peer))
  322. [15:10:45] <mkaply> drewinthehead: yes.
  323. [15:10:56] <mkaply> drewinthehead: But I'm willing to implement whatever you guys come up with.
  324. [15:11:09] <drewinthehead> does it present a parsing issue for you? i think for me it would be pretty easy
  325. [15:11:11] <Phae> well, it's not just that. if there's a real issue with parsing this stuff
  326. [15:11:12] <Phae> it's important
  327. [15:11:18] <drewinthehead> provided it keeps the data- prefix
  328. [15:11:24] * cygri ( has joined #microformats
  329. [15:11:54] <mkaply> drewinthehead: yeah, I think it will be OK. why do people like data- vs data: or data{} (just curious)
  330. [15:12:21] <Phae> {} is a bitch for CSS. You have to escape the chars.
  331. [15:12:28] <drewinthehead> as is :
  332. [15:12:40] <drewinthehead> so a dash is safest
  333. [15:12:46] <Phae> I know we shouldn't necessarily pander because of that, but - is least offensive, imho
  334. [15:13:17] * bogdanlazarsb ( has joined #microformats
  335. [15:13:32] <mkaply> And I really hate the embedded spaces thing. I don't know that I want this as a general pattern
  336. [15:13:47] <mkaply> starting to have to encode and unencode things
  337. [15:13:56] <mkaply> and should they be unicode encoded?
  338. [15:14:03] <mkaply> and does the class attribute allow international characters?
  339. [15:14:23] <Phae> well, these are all good questions that need documenting. :)
  340. [15:16:06] <drewinthehead> class can only accept a-zA-z0-9 - _ : and .
  341. [15:16:22] <drewinthehead> note, + is not allowed
  342. [15:16:24] <mkaply> so it can't be escaped
  343. [15:16:29] <mkaply> because % is not allowed
  344. [15:16:34] <Phae> ok
  345. [15:16:35] <mkaply> So this can't be generalized for all abbr
  346. [15:16:37] <drewinthehead> correct, afaik
  347. [15:17:15] <drewinthehead> hold on, i may have misread that ... disregard :)
  348. [15:17:22] <Phae> heh
  349. [15:17:50] <drewinthehead> i was reading the rules for ID and NAME
  350. [15:17:53] <drewinthehead>
  351. [15:18:14] <drewinthehead> CDATA applies to class
  352. [15:18:22] <Phae> ok
  353. [15:18:23] <csarven> [11:19:38] <drewinthehead> class can only accept a-zA-z0-9 - _ : and . -- not exactly true
  354. [15:18:47] <drewinthehead> csarven: right.
  355. [15:18:55] <csarven> You can start a class even with "#" e.g., class="#foo"
  356. [15:19:36] <drewinthehead> csarven: I've already said I was reading the wrong part of the spec...
  357. [15:19:37] <csarven> Oops [11:20:47] <drewinthehead> hold on, i may have misread that ... disregard :) :)
  358. [15:19:41] <csarven> My bad
  359. [15:19:45] <Phae> IT says that HTML 4 imposes further restrictions tho
  360. [15:21:51] <Phae> so it can have escaped chars and unicode
  361. [15:23:21] <drewinthehead> it looks that way
  362. [15:23:44] <mkaply> But you have to define what you use. Because you can't tell whether something is escaped unicode or just escaped.
  363. [15:23:53] <Phae> ok
  364. [15:24:23] <mkaply> Plus you have the problem that on an ISO-8859-1 page, you wouldn't expect escaped unicode.
  365. [15:24:39] <drewinthehead> why do we need escaped unicode?
  366. [15:25:28] <mkaply> Are we going to allow this for any text? Not jus dates?
  367. [15:25:53] <drewinthehead> that's a big question
  368. [15:26:19] <mkaply> If a country name, for instance, contains i18n chars, would it be in the encoding of the page. Does that validate?
  369. [15:26:49] <Phae> wouldn't the same problem exist with the data in @title anyway?
  370. [15:26:57] * Phae isn't sure how that works.
  371. [15:27:10] <mkaply> true.
  372. [15:27:40] <Phae> it's just shifting the same data into a different attribute
  373. [15:27:46] <Phae> so i assume that encoding issue exists already
  374. [15:27:47] <drewinthehead> yup
  375. [15:28:03] <mkaply> So then the only issue is encoding space
  376. [15:28:11] <Phae> oaky. that narrows it down some :)
  377. [15:28:20] <Phae> so. what circumstances do we need a space?
  378. [15:29:26] <Phae> country names, again, i'm guessing.
  379. [15:30:31] * purp ( has joined #microformats
  380. [15:30:34] * pat-in-wv ( has left #microformats
  381. [15:33:09] * purp_ (n=jmeyer@ has joined #microformats
  382. [15:33:21] <drewinthehead> aren't there international country codes for that?
  383. [15:33:44] <Phae> Yeah, think so. I'm just trying to think of what our use-cases are
  384. [15:33:55] <Phae> and whether they have non-space solutions
  385. [15:33:57] <drewinthehead> ISO has a set of 2 char codes ... just found it
  386. [15:34:06] <Phae> cy!
  387. [15:34:18] <drewinthehead> where do we use @title currently?
  388. [15:34:22] <Phae> i think that's my favourite one- i think it might be made up.
  389. [15:34:26] <drewinthehead> dates, geo
  390. [15:34:37] <csarven> tel
  391. [15:34:40] <Phae> yep
  392. [15:34:41] <csarven> err
  393. [15:34:57] <Phae> is that it at the moment?
  394. [15:35:01] <csarven> No, not tel.
  395. [15:35:18] <Phae> has the fixed data formats listed
  396. [15:35:38] <csarven> Some hCard values
  397. [15:35:50] * emrojo (n=emrojo@ has joined #microformats
  398. [15:36:07] <csarven> e.g., country-name, region which use <abbr>
  399. [15:36:21] <Phae> country name is a legit use of abbr, though.
  400. [15:36:24] <Phae> imo.
  401. [15:36:39] <Phae> UK is short for United Kingdom and should be expanded that way
  402. [15:36:55] <Phae> So I'd suggest that the abbr might remain in that case - no?
  403. [15:37:10] <csarven> Yes
  404. [15:37:44] <Phae> sooo...
  405. [15:43:34] * purp_ (n=jmeyer@ Quit ()
  406. [15:45:23] <drewinthehead> so..
  407. [15:46:57] * purp ( Quit (Connection timed out)
  408. [15:47:00] <Phae> i don't want to make too many assumptions.
  409. [15:47:07] <Phae> do we actually have a space encoding issue?
  410. [15:47:32] <drewinthehead> one has yet to make itself known
  411. [15:48:28] <Phae> right.. ok.
  412. [15:51:25] <drewinthehead> my biggest objection is hidden data. but then abbr-pattern has failed because the data is exposed.
  413. [15:51:31] <Phae> quite.
  414. [15:51:56] <Phae> and as i said, i think we need to be pragmatic. we want to use data that people don't want to expose in their pages. we have to give a little somewhere.
  415. [15:52:05] * cygri ( Quit ()
  416. [15:55:33] <trovster> Do screenreaders read out all @titles or just those in abbr ?
  417. [16:03:46] <Phae> uh, depends how they're configured, afaik
  418. [16:03:50] <Phae> they can
  419. [16:03:52] <Phae> i believe.
  420. [16:04:19] <Phae> it's not just SRs anyway - sighted users could do without the ugly machine-led toolips
  421. [16:05:30] <trovster> OK.
  422. [16:05:53] * drewinthehead thinks ISO dates are beautiful
  423. [16:06:01] <Phae> you're special tho, drew ;)
  424. [16:06:26] * trovster must be special too
  425. [16:06:41] <trovster> So much better than mm-dd-yyyy vs dd-mm-yyyy confusing
  426. [16:07:14] <Phae> anyway- that's not really what we're discussing anymore. :) the dates aren't universally pleasing, let's just say.
  427. [16:08:05] <trovster> Indeed.
  428. [16:08:56] <Phae> although. dd-mm-yyyy is pretty nice and friendly.. 2008-05-17T12:00:00+0100 is less so.
  429. [16:09:15] <Phae> it's just not that readable to the average user
  430. [16:09:45] <csarven> Because the latter includes time and zone ;)
  431. [16:09:54] <Phae> sure - i was using an extreme, but valid, example
  432. [16:09:58] <csarven> Which is not a must
  433. [16:10:01] <Phae> of what could feasibly currently be in a title
  434. [16:10:52] * BobJonkman likes ISO dates 'cos they sort beautifully
  435. [16:11:02] <Phae> oo.. -discuss post about the beeb stuff
  436. [16:12:04] * tantek catches up on a few hours of past IRC
  437. [16:12:14] <Phae> it's picking up steam on the blogs
  438. [16:12:18] <tantek> Phae, I found where I initially noted the data in class is bad
  439. [16:12:21] <tantek>
  440. [16:12:25] <Phae> cools.
  441. [16:12:26] <tantek> this past January
  442. [16:12:28] <Phae> thx
  443. [16:12:37] <tantek> I'm sorry I didn't bring that up earlier
  444. [16:12:44] <Phae> please do read up though
  445. [16:12:48] <tantek> I did
  446. [16:12:58] <tantek> I'm vehemently opposed to putting data in the class attribute
  447. [16:12:59] <Phae> ah, sorry, misread you. i thought you were about to :)
  448. [16:13:30] <BobJonkman> OPML also puts data in attributes; very messy
  449. [16:13:34] <tantek> we *must* find better alternatives
  450. [16:13:49] <tantek> we must hold ourselves to higher standards than any XML/RDF solution
  451. [16:14:08] <tantek> it's part of what sets microformats apart from so many other failed efforts and data representation on the web
  452. [16:15:24] <tantek> we must not go down the path of invisible (meta)data - IMHO that principle is inviolable for microformats
  453. [16:16:02] <tantek> in fact, given that it is "not visible data", I think perhaps a better way of putting it is "dark data"
  454. [16:16:13] <tantek> so yes
  455. [16:16:18] <tantek> we must not go down the path of dark data
  456. [16:17:40] <tantek> drewm's brainstorm above is similar to what I was talking about in terms of "datevalue" and "timevalue"
  457. [16:18:08] <tantek> we don't need to go to the granularity of "yearvalue" "monthvalue" "dayvalue" as a first step
  458. [16:18:19] <tantek> I'm convinced "datevalue" and "timevalue" would solve the 80% of publishing cases
  459. [16:18:44] <tantek> and iterating on that with existing content in the wild would help us figure out if we need anything else
  460. [16:20:14] <tantek> here is a short code example:
  461. [16:21:05] <tantek> the weekly dinner is tonight at <span class="dtstart">2008-06-24T18:30</span>
  462. [16:21:48] <tantek> however that's not the easiest to read, nor do most people publish that as human visible text, so per the abbr-datetime pattern:
  463. [16:22:20] <tantek> the weekly dinner is tonight at <abbr class="dtstart" title="2008-06-24T18:30">6:30pm</abbr>
  464. [16:22:33] <tantek> which has raised two issues
  465. [16:23:00] <tantek> 1. when "2008-06-24T18:30" is read by a screen reader, it's not the most understandable thing
  466. [16:23:30] * purp ( has joined #microformats
  467. [16:24:26] * azazul ( has joined #microformats
  468. [16:24:29] <tantek> 2. (and I think this is the worse problem) There is a non-local violation of DRY. That is, the "date" information is now in the text *twice* (actually it was before also), and those two instances of the date information are not on the same element, which makes it worse. That is, "tonight" is in the prose, *outside* of the "2008-06-24".
  469. [16:24:57] <tantek> In my analysis of examples of event information on the web, the date and time are often published in separate elements, often for display purposes
  470. [16:25:36] <tantek> the brainstorm proposal is essentially to introduce a date and time value excerption longhand
  471. [16:25:58] * purp ( Quit (Client Quit)
  472. [16:26:41] <tantek> just as we introduced the "value" class name to enable folks to excerpt property values (often separate them from the "type" subproperty), we introduce "datevalue" and "timevalue" class names to enable folks to excerpt date and time values
  473. [16:26:47] <tantek> so the example becomes:
  474. [16:28:14] <tantek> the weekly dinner is <span class="dtstart"><abbr class="datevalue" title="2008-06-24">tonight</abbr> at <abbr class="timevalue" title="18:30">6:30pm</abbr></span>
  475. [16:28:40] * pjkix (n=pkhalil@ has joined #microformats
  476. [16:28:40] <jibot> pjkix is PJ Khalil a Web Developer in SF and can be found online at
  477. [16:29:09] <tantek> the proposal also allows setting the date and time in separate element subtrees as well, which may be necessary for some document structures:
  478. [16:29:37] <tantek> the weekly dinner is <span class="dtstart"><abbr class="datevalue" title="2008-06-24">tonight</abbr></span> at <span class="dtstart"><abbr class="timevalue" title="18:30">6:30pm</abbr></span>
  479. [16:29:55] <tantek> note the two instances of dtstart, one of which sets the date for the dtstart, and the other of which sets the time
  480. [16:30:28] <tantek> of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so I think this is ok.
  481. [16:30:38] * mn_francis (n=mn_franc@nat/yahoo/x-e31a3da7a641baaa) has joined #microformats
  482. [16:30:38] <jibot> mn_francis is a web developer for Yahoo! Europe; is his personal site
  483. [16:30:54] * mn_francis_ (n=mn_franc@nat/yahoo/x-943e9c5dd7a71a5f) Quit (Read error: 104 (Connection reset by peer))
  484. [16:31:01] <tantek> this also provides a *very* convenient way to re-use the same date information for start and end, e.g. expanding the example:
  485. [16:31:14] <drewinthehead> tantek: do you think that sufficiently addresses the concerns raised with the current use of abbr-pattern?
  486. [16:31:23] <Phae> i'm only saying this because someone will - not to argue it with you ( :) ) - not everyone is going to agree with your use of abbr to expand
  487. [16:31:25] <tantek> one sec drew, I'm getting close
  488. [16:31:35] <drewinthehead> :)
  489. [16:32:26] <tantek> the weekly dinner is <span class="dtstart dtend"><abbr class="datevalue" title="2008-06-24">tonight</abbr></span> from <span class="dtstart"><abbr class="timevalue" title="18:30">6:30</abbr></span> - <span class="dtend"><abbr class="timevalue" title="20:30">8:30pm</abbr></span>
  490. [16:33:07] <tantek> note what just happened. we just eliminated another duplication of date information by reusing the start *date* information for the end *date* information and *only* specifying the end *time* information separately.
  491. [16:33:45] <tantek> drew, to answer your question, two things
  492. [16:34:23] <tantek> first, the abbr-date-pattern, as documented and explained by adactio is just fine (in contrast to the abbr-datetime-pattern)
  493. [16:34:35] <Phae> that's getting pretty complicated, imho.
  494. [16:35:08] <tantek> Phae, much less complicated that inventing yet another syntax ( " { ... } " ???? ) that web authors would have to learn
  495. [16:35:13] <tantek> than inventing
  496. [16:35:29] <tantek> continuing: similar to the abbr-date-pattern, this proposal would introduce the abbr-time-pattern, which is similarly acceptable
  497. [16:35:32] <Phae> but it's all in one place, rather than spreading it ou
  498. [16:35:32] <Phae> t
  499. [16:35:37] <Phae> just playing devil's advocate
  500. [16:35:57] <tantek> Phae, the spreading it out is what content does already!
  501. [16:36:10] <tantek> it is much more important to map the machine data as close to the existing publishing practice as possible, than to try to "put it all in one place"
  502. [16:36:15] <BobJonkman> What about timezones, which are rarely exposed in the visible prose?
  503. [16:36:34] <tantek> the "put it all in one place" is why people ended up sticking so much invisible metadata in the head of the document, which we know fails
  504. [16:37:00] <tantek> BobJonkman, timezones are rarely published also
  505. [16:37:06] <tantek> I thought about that
  506. [16:37:25] <tantek> there are two choices
  507. [16:37:25] <hober> <abbr class="datevalue" title="2008-06-24" id="tonight">tonight</abbr> from <span class="dtstart"><a class="include" href="#tonight"></a><abbr class="timevalue" title="17:00">5</abbr></span> to...
  508. [16:37:46] <tantek> hober, yes, you could do that too
  509. [16:37:56] <tantek> but the example I gave I wanted to show without using the include-pattern
  510. [16:38:01] <hober> sure
  511. [16:38:12] <tantek> because I think the include-pattern introduces another complexity
  512. [16:38:23] <tantek> back to TZ
  513. [16:38:26] <tantek> two choices:
  514. [16:38:40] <BobJonkman> Perhaps yet another value, <abbr class="tzvalue">-0500</abbr>
  515. [16:38:41] <tantek> 1. simply include TZ as part of the "timevalue"
  516. [16:39:01] <tantek> e.g. <abbr class="timevalue" title="18:30-0700">6:30</abbr>
  517. [16:39:25] <tantek> 2. introduce "tzvalue" (Bob was reading ahead ;) )
  518. [16:40:02] <tantek> e.g. <abbr class="timevalue" title="18:30">6:30pm</abbr> <abbr class="tzvalue" title="-0700">PDT</abbr>
  519. [16:40:29] <tantek> or 3. allow *both*
  520. [16:40:50] <tantek> and let web authors decide if they want to specify timezone as part of the time, they can
  521. [16:41:04] <tantek> or if web authors visibly publish the timezone separately (e.g. PDT), then they can mark that up
  522. [16:41:37] <tantek> I think this would solve the 95%+ of real world publishing cases for events
  523. [16:41:49] <tantek> and frankly, for hAtom as well (which is another big source of datetime info)
  524. [16:42:11] <tantek> and it is a pattern which works for all datetime properties, which is the source of the biggest accessibility concerns raised
  525. [16:42:24] <tantek> I particularly like two aspects of this proposal
  526. [16:43:10] <tantek> 1. It keeps the date/machine date *even closer* to the visible human date, unlike the current abbr-datetime which often duplicates the date information in ISO8601 form separate from the human visible date in the content
  527. [16:43:41] <tantek> this proximity of duplicate information helps to reduce the risk (not eliminate, but reducing is good) of duplicate data divergence
  528. [16:44:01] <tantek> which results in higher quality (more accurate) content
  529. [16:45:00] <tantek> 2. It allows multiple date properties to re-use (i.e. NOT duplicate/triplicate) the same *date* information (which is a VERY common case in events and blog posts) while being able to separately specify/markup the *time* information
  530. [16:45:22] <tantek> so above and beyond addressing the accessibility/readability issues of ISO8601 datetimes, I think this proposal:
  531. [16:45:33] <tantek> a. better fits content publishing practices
  532. [16:45:57] <tantek> b. reduces DRY risk/issues/instances
  533. [16:46:27] * charlenopires (n=charleno@ has joined #microformats
  534. [16:46:28] <tantek> and of course, it should go without saying (but apparently it needs to be repeated), this proposal introduces no dark data.
  535. [16:46:57] <BobJonkman> Appears to be compatible with HTML5 too, although it may require duplication of data in the <time> element and a class attribute.
  536. [16:47:39] <tantek> Bob - could you provide a link to the chapter by chapter split version of HTML5? the long / complete version tends to hang/crash browsers too often.
  537. [16:48:02] * mn_francis (n=mn_franc@nat/yahoo/x-e31a3da7a641baaa) Quit ("Screw you guys, home.")
  538. [16:48:15] <Phae> back online shortly.
  539. [16:48:17] <tantek> though to be clear, fitting existing content publishing practices is way more important than mapping to a "future" standard (which the <time> element is)
  540. [16:48:19] * Phae ( Quit ()
  541. [16:48:25] <mkaply> those new values don't actually solve the accessibility problem.
  542. [16:48:31] <mkaply> You still have titles that can't be read to humans
  543. [16:48:41] <tantek> mkaply, not true
  544. [16:48:42] <mkaply> <abbr class="tzvalue" title="-0700">PDT</abbr>
  545. [16:48:52] <mkaply> -0700 would get read by the screen reader
  546. [16:48:53] <tantek> adactio demonstrated that abbr-date is accessible
  547. [16:48:55] <tantek> as is abbr-time
  548. [16:49:04] <tantek> is tzvalue the only you are objecting to?
  549. [16:49:11] <tantek> just to be clear
  550. [16:49:49] <mkaply> I would also object to the incredible amount of complexity that would add.
  551. [16:50:15] <tantek> an additional class name is about as simple as you can get in terms of publishing
  552. [16:50:26] <tantek> a new format/syntax is MUCH more complex
  553. [16:50:59] <mkaply> this doesn't work either
  554. [16:51:00] <mkaply> <abbr class="datevalue" title="2008-06-24">tonight</abbr>
  555. [16:51:04] <mkaply> The screen reader should read "tonight"
  556. [16:51:06] <mkaply> not the date
  557. [16:51:33] <tantek> mkaply, in tests I believe folks have demonstrated that screen readers *do* read the text by default rather than title
  558. [16:52:00] <tantek> that was one of the misconceptions that I think was debunked fairly recently (past couple of months)
  559. [16:52:11] <tantek> *and* 2008-06-24 is readable/accessible
  560. [16:52:13] <mkaply> So then what is BBC's complaint about the abbr pattern? besides the fact that it looks weird in the U
  561. [16:52:18] <mkaply> UI
  562. [16:52:20] <tantek> that's been determined by i18n experts
  563. [16:52:30] <tantek> the tooltip issue is orthogonal
  564. [16:52:41] <tantek> the problem is that the full datetime is not the most readable
  565. [16:52:51] <tantek> people can understand/read 2008-06-24 quite easily
  566. [16:53:02] <tantek> it's when you introduce the T and the time that it looks ugly becomes quickly unreadable
  567. [16:53:03] <mkaply> but we just established that people aren't supposed to see that date, right?
  568. [16:53:06] <tantek> no
  569. [16:53:12] <mkaply> it's hidden in the title
  570. [16:53:18] <tantek> the tooltip issue is orthogonal
  571. [16:53:19] <csarven> SO by splitting it into smaller more consumable parts it will no longer be an issue?
  572. [16:53:23] <csarven> I'm confused by all this now.
  573. [16:53:24] <tantek> it's *inspectable* in the title
  574. [16:53:38] <tantek> csarven, that's right, the issue is with 2008-06-24T18:30
  575. [16:53:42] <tantek> not with 2008-06-24
  576. [16:53:44] <tantek> nor with 18:30
  577. [16:53:48] <csarven> I see
  578. [16:53:55] <tantek> both of which themselves, in context, are readable, understandable
  579. [16:54:01] <tantek> it is the compound datetime that is the problem
  580. [16:54:31] <mkaply> actually timezone is not readable either. No matter what you do to it. I bet if you grabbed 10 people off the street, 9 wouldn't know what -0700 meant
  581. [16:54:39] <mkaply> or Z for that matter
  582. [16:54:44] <csarven> Agreed
  583. [16:55:05] * BobJonkman has found the HTML5 chapter on <tme> at
  584. [16:55:05] <tantek> mkaply, I'd actually bet 10/10 ;)
  585. [16:55:37] <csarven> Depends on the street ;)
  586. [16:56:25] <tantek> timezone *is* the hardest piece yes, and for that, that is why I proposed offering choices of incorporating it into the "timevalue", or separately marking it up, or leaving it out altogether (which is the 80% case today)
  587. [16:56:35] <mkaply> So is the problem trying to be solved here that people can see the date in the tooltup?
  588. [16:56:41] <mkaply> I'm still not understanding the problem
  589. [16:56:46] <tantek> thus we leave that compromise to "the market" and see what choices authors make in the wild
  590. [16:57:05] <csarven> mkaply Not only that but screen readers read out the full ISO8601 which is not easily consumed
  591. [16:57:09] <tantek> mkaply, the "people can see the date in the tooltip" problem is ORTHOGONAL
  592. [16:57:25] <mkaply> tantek: But you said the accessibility thing wasn't a problem. So what is the problem
  593. [16:57:30] <mkaply> orthogonal to what?
  594. [16:57:31] <tantek> that's a separate issue with a separate problem
  595. [16:57:36] <tantek> orthogonal to the compound problem
  596. [16:57:39] <csarven> For some reason by splitting the datetime into smaller chunks it is read easier
  597. [16:57:47] <tantek> mkaply, no you are confusing two things
  598. [16:57:54] <mkaply> why is there a compound problem? When are people going to see the compound date?
  599. [16:58:03] <mkaply> Or is the problem for people creating the dates?
  600. [16:58:27] <tantek> they are apparently seeing/hearing the compound datetime now in use of the abbr-datetime pattern
  601. [16:58:36] <tantek> see above q&a w csarven
  602. [16:58:43] <tantek> datetime = difficult to read/hear
  603. [16:58:50] <tantek> date and time separately = no problem
  604. [16:58:55] <tantek> that's what this solves
  605. [16:58:56] <mkaply> but yo7u said
  606. [16:58:58] <mkaply> mkaply, in tests I believe folks have demonstrated that screen readers *do* read the text by default rather than title
  607. [16:59:26] <tantek> yes, and in the cases where they don't, this makes it better
  608. [16:59:42] * purp (n=jmeyer@ has joined #microformats
  609. [16:59:44] <tantek> such cases are when preferences are customized etc.
  610. [16:59:50] <mkaply> So all we're trying to solve here is the occasional screen reader that reads the title.
  611. [16:59:54] <tantek> *and* for humans looking at tooltips
  612. [17:00:08] <tantek> it's easier to inspect/read/verify the data
  613. [17:00:18] <tantek> mkaply - no, there are many facets
  614. [17:00:31] <tantek> don't try to oversimplify to "all we're trying to solve here"
  615. [17:00:40] <tantek> that's why this has taken so long to figure out
  616. [17:00:43] <csarven> I think some configure their reader to read out the @title's. Was this one of the issues?
  617. [17:00:48] <tantek> it's not a simple cut and dry one problem one solution
  618. [17:01:14] <tantek> csarven, whether seeing (tooltip) or hearing a compound datetime, it is hard to understand
  619. [17:01:31] <tantek> splitting it into date and time solves that
  620. [17:01:49] <csarven> Minimises I would say
  621. [17:02:05] <tantek> everything is relative right? makes it better.
  622. [17:02:13] <tantek> we are not trying to be perfect
  623. [17:02:24] <tantek> in fact, trying to be perfect is one of our anti-principles.
  624. [17:02:28] <tantek> deliberately so
  625. [17:02:35] <csarven> two thousand eight dash ...
  626. [17:02:37] <tantek> because that usually means you are sacrificing something else
  627. [17:02:53] <tantek> csarven - no, it's read as separate digit quantities
  628. [17:02:54] <csarven> Right. I'm just saying that it minimises the longhand
  629. [17:03:12] <tantek> csarven, don't try to guess how things are read - you will almost certainly get it wrong
  630. [17:03:23] <tantek> that's why we've insisted on people performing actual tests
  631. [17:03:41] <csarven> tantek I only wanted to emphasise the dash"
  632. [17:03:43] <tantek> how things are spoken by readers
  633. [17:03:57] <tantek> csarven - and how do you know the dash is spoken at all?
  634. [17:04:19] <tantek> periods and commas are not spoken for example
  635. [17:04:30] <csarven> Fair
  636. [17:04:34] <tantek> punctuation is for setting tempo in speech
  637. [17:04:45] <tantek> so don't guess theoretically what is spoken by readers
  638. [17:04:51] <tantek> it's a waste of time
  639. [17:05:14] <tantek> this proposal also solves a *specific* problem, that the abbr-datetime
  640. [17:05:25] <tantek> rather than trying to solve an arbitrary machine-data problem
  641. [17:05:33] <tantek> this is also one of our principles
  642. [17:06:25] <mfbot> [[principles]] M * Tantek * (+29) direct link rather than redirect
  643. [17:08:51] <BobJonkman> So do we run this past the Accessibility folks and the BBC, or just put it to a vote on our Wiki?
  644. [17:09:16] <tantek> The BBC is not our gatekeeper nor should they be.
  645. [17:09:21] * pat-in-wv ( has joined #microformats
  646. [17:09:22] <tantek> Nor should any one content publisher be.
  647. [17:09:26] * pat-in-wv ( has left #microformats
  648. [17:09:37] <tantek> Something I was discussing with adactio which deserves to be restated.
  649. [17:09:54] <tantek> There are always going to be some publishers that don't adopt microformats (for now), for whatever reasons.
  650. [17:10:08] <tantek> This doesn't mean we stop whatever we are doing and attempt to placate them.
  651. [17:10:20] <BobJonkman> I just want to avoid the current problems the exisiting datetime patterns have created
  652. [17:10:22] <tantek> That would set a really bad precedent, and is a really bad way to do design.
  653. [17:10:32] <tantek> However, we also shouldn't ignore feedback.
  654. [17:10:54] <tantek> The right thing to do is to collect any *new* feedback and add it to our existing documentation of feedback and issues.
  655. [17:11:18] <tantek> And then look at that compendium overall when looking to make changes, improvements etc.
  656. [17:11:41] <tantek> Also, as long as we are making forward progress, we don't have to be perfect, nor should we attempt to be.
  657. [17:12:02] <tantek> But we should be very careful to NOT go backwards.
  658. [17:12:17] <tantek> I.e. violating our visible data principles
  659. [17:13:11] <tantek> Bob, I ran this brainstorm by adactio last week and he seemed to think it had merit. So I'm now running it past people here in IRC to see if people here think it has some merit.
  660. [17:13:29] <tantek> The next step is to document it on the wiki.
  661. [17:13:51] <csarven> What's the policy/approach on the formats: inlight of a better way of doing something, will the previously determined conventions be allowed in the future?
  662. [17:14:12] <csarven> Say we datevalue and timevalue is a go, what happens to datetime?
  663. [17:14:44] <tantek> when you say "Accessibility folks" you are referring to a broad spectrum of folks also, some of whom are very professional and diligent, and some who are reckless and inflammatory. I think the best thing we can do is to discuss proposals in the open, and let those who are interested in following the discussion follow along.
  664. [17:15:21] <tantek> csarven, we let datetime remain and advise folks to use the better solutions when they can.
  665. [17:15:57] <tantek> and we would update examples etc. accordingly
  666. [17:15:59] <tantek> and document how to change things from datetime to date and time in content
  667. [17:16:01] <tantek> and then let content naturally evolve forward
  668. [17:16:03] <BobJonkman> HTML5 says that the datetime attribute can contain either date, or time, or both, with or without timezone. It's up to the parser to figure it out (and there's a description of a parsing algorithm)
  669. [17:16:20] <BobJonkman> So we could keep datetime but reduce the info in each instance.
  670. [17:16:37] <tantek> ISO8601 can contain either date, or time, or both, with or without timezone. I'm not sure what HTML5 adds to that.
  671. [17:17:23] <BobJonkman> Just that we may not need the additional classnames of datevalue or timevalue; the classname datetime can contain either
  672. [17:17:25] <tantek> BobJonkman, I too want to provide an alternative to the existing datetime pattern that provides better results.
  673. [17:18:05] <csarven> Small note here: datevalue is valid ISO8601. timevalue is not valid ISO8601
  674. [17:18:23] * DanWrong (i=fwuser@ Quit ()
  675. [17:18:35] <tantek> BobJonkman, that's an interesting suggestion.
  676. [17:19:09] <tantek> And has an additional ramification, that is, perhaps we don't need the datetime class at all.
  677. [17:19:31] <tantek> Why not simply use value excerption and compounding of multiple value excerpts to solve that problem?
  678. [17:20:27] <tantek> e.g. I wonder if this could work:
  679. [17:20:34] * danbri (n=danbri@unaffiliated/danbri) has joined #microformats
  680. [17:20:47] <tantek> the weekly dinner is <span class="dtstart"><abbr class="value" title="2008-06-24">tonight</abbr> at <abbr class="value" title="18:30">6:30pm</abbr></span>
  681. [17:21:46] <csarven> Ya, compound of datevalue and timevalue would solve it
  682. [17:22:00] <hober> what about the T
  683. [17:22:00] <tantek> csarven, why do you need the compound at all?
  684. [17:22:12] <BobJonkman> Wonderful! It keeps syntax on existing microformatted pages valid
  685. [17:22:41] <tantek> hober, the point is that we specify parsing of value excerption for datetime properties to specifically look for a date, a time, a datetime, all with or without timezone
  686. [17:22:47] <BobJonkman> hober: I believe the T is optional anyway
  687. [17:22:48] <tantek> no need for the T
  688. [17:23:02] <csarven> AFAIK "18:30" is not valid ISO8601. To have a proper datetime we need to combine the datevalue and the timevalue if we want to preserve the time
  689. [17:23:03] <tantek> BobJonkman the T is optional in ISO8601 but not in W3C-datetime
  690. [17:23:23] <BobJonkman> tantek: I stand corrected.
  691. [17:23:35] <tantek> csarven, see what I wrote to hober above
  692. [17:23:57] <tantek> we specify precise parsing rules for value excerpts of datetime properties
  693. [17:24:03] <maddiin> well, this all makes sense to me, but you can´t leave content publishers out. this proposal makes it a little bit of a nightmare to implement. at least for full dates with date+time+timezone.
  694. [17:24:37] <tantek> maddiin this brainstorm/proposal/design is driven by actual content publisher practices - they are not being left out.
  695. [17:24:52] <tantek> if you think you know of a case that would pose difficulty, please post a URL to the case
  696. [17:25:03] <tantek> continuing with the examples from above:
  697. [17:25:28] <tantek> the weekly dinner is <span class="dtstart dtend"><abbr class="value" title="2008-06-24">tonight</abbr></span> from <span class="dtstart"><abbr class="value" title="18:30">6:30</abbr></span> - <span class="dtend"><abbr class="value" title="20:30">8:30pm</abbr></span>
  698. [17:26:00] <csarven> tantek I think I understand what you are saying. I used the word "compound" there incorrectly. I didn't mean to combine the date and the time on the same element. I've meant more in terms of concatinating the datevalue and timevalue in order to be both valid iso8601 and to preserve the time
  699. [17:26:02] <tantek> we introduce allowing multiple instances of a singular property to specify different components of that singular property
  700. [17:26:37] <tantek> csarven, it's not a simple concatenation, that's what I meant about specifying *precise* parsing rules for value excerpts of datetime properties
  701. [17:27:29] <tantek> BobJonkman, well done with your analysis borrowed from the HTML5 spec! I believe you have helped eliminate any need for any new classes at all!
  702. [17:28:23] <BobJonkman> Thank you!
  703. [17:28:38] <hober> Well, big +1 from me so far.
  704. [17:29:54] <tantek> It's like the simple solution was staring us in the face the whole time, and we had to walk down a couple of complex paths, get some distance/perspective to understand the problem, in order to see the simple solution.
  705. [17:32:10] <mkaply> So we would introduce that multiple dtstart/dtend get put together?
  706. [17:32:26] <mkaply> And when we concatenate them, we add the T? Becaue they are probably a date and a time?
  707. [17:32:33] * mkaply wants the T
  708. [17:33:04] <hober> If we require the -s and the :s, then it's pretty clear which piece is which.
  709. [17:33:30] <tantek> mkaply, the T is syntactic, not semantic
  710. [17:33:40] <hober> The idea is that parsing .value in datetime cases is not string concatenation at all
  711. [17:33:59] <tantek> at that point, after you have parsed a separate date and a separate time, you have the components
  712. [17:34:05] <mkaply> tantek: I understand, but in the end a parser will need to create a time/date value that it gives to other services to do interesting things. We need to make sure that is defined properly
  713. [17:34:06] * jgraham ( has joined #microformats
  714. [17:34:10] <mkaply> for a JSON representation for instance
  715. [17:34:22] <tantek> sure, for debug purposes if you want to pretty-print a full ISO8601 datetime then yes, you introduce the T
  716. [17:34:38] <tantek> right, for JSON ISO8601 datetime also sure
  717. [17:34:43] <mkaply> and would we require the punctuation? So that the two could be distinquished
  718. [17:34:47] <tantek> but there is no need for there to be a "T" in the content
  719. [17:34:51] <tantek> yes
  720. [17:34:57] <mkaply> because you might put date before time
  721. [17:35:04] <hober> You can serialize the parsed datetime however you'd like.
  722. [17:35:05] <tantek> we would require "-" for dates and ":" for times
  723. [17:35:06] <mkaply> sorry, time before date
  724. [17:35:16] <tantek> precisely
  725. [17:35:27] <tantek> which has added benefits of more human readability also
  726. [17:35:57] <tantek> since 2008-06-24 is more readable than 20080624 (especially when spoken)
  727. [17:35:59] <tantek> and 18:30 is more readable than 1830 (also when spoken)
  728. [17:36:15] <hober> I have a vague desire to require the : in non-Z tz values
  729. [17:36:16] <tantek> yes, value excerpts for datetime properties require full "-" and ":" puncuation
  730. [17:36:16] * drewinthehead ( Quit (Read error: 110 (Connection timed out))
  731. [17:36:22] <hober> -07:00, not -0700
  732. [17:36:54] <mkaply> so is a parser to assume that if a date has value, they follow this pattern (not the traditional value pattern)
  733. [17:36:56] <tantek> and require the minus/plus
  734. [17:36:58] <tantek> -/+
  735. [17:36:59] <hober> (would help human readability and match atom:published & atom:updated)
  736. [17:37:00] <mkaply> Since there is really no way to tell them apart
  737. [17:37:01] <tantek> on tz values
  738. [17:37:06] <tantek> hober, I can agree with that
  739. [17:37:22] <tantek> mkaply, correct, just as value excerpting works now
  740. [17:37:25] <tantek> the first test
  741. [17:37:32] <tantek> is if there is a "value" child
  742. [17:37:40] <tantek> then you parse differently
  743. [17:37:45] <tantek> .
  744. [17:38:20] <mkaply> Did we ever determine value excerpting was even meant to apply in every case? I thought the only reference that was found was in a presentation
  745. [17:38:22] <mkaply> not on the wiki
  746. [17:39:01] * KevinMarks ( Quit ("The computer fell asleep")
  747. [17:39:18] <tantek> well let's specify it explicitly for all datetime properties for this proposal
  748. [17:39:26] <tantek> one problem at a time :)
  749. [17:39:55] <maddiin> tantek: i am writing my personal blog app at the moment and right now i simply do <abbr class="published" title="{{ comment.created|isoformat }}">{{ comment.created|babel_datetime(lang) }}</abbr>
  750. [17:40:11] <hober> I'm reluctant to generalize value excerpting to the general case without a really compelling argument
  751. [17:40:25] <tantek> hober, fortunately we don't have to address that at the moment
  752. [17:40:26] <maddiin> which would result in this with the proposal:
  753. [17:40:29] <hober> indeed
  754. [17:40:40] <mkaply> hober: Most parsers already generalize value exceerpting to every element in every microformat
  755. [17:40:42] <maddiin> <abbr class="published value" title="{{ comment.created|babel_date(format='YYYY-MM-d') }}">{{ comment.created|babel_date(lang, format='MMMM d, YYYY') }}</abbr> at <abbr class="published value" title="{{ comment.created|babel_datetime(format='h:mm:ss') }}">{{ comment.created|babel_datetime(format='h:mm:ss a') }}</abbr> <abbr class="published value" title="{{ comment.created|babel_datetime(format='ZZZ') }}">{{ comment.created|babel_datetime(la
  756. [17:40:42] <maddiin> ng, format='zzz') }}</abbr>
  757. [17:41:25] <maddiin> well, i could simplify it a bit, but nonetheless it is still a lot more work
  758. [17:41:27] <tantek> maddiin not quite
  759. [17:41:36] <tantek> start with what the actual data/markup would look like
  760. [17:41:55] <tantek> and the work backwards to your {{ }} template code/functions
  761. [17:42:02] <tantek> and then work backwards
  762. [17:42:03] <mkaply> there's only one problem I find with the idea.
  763. [17:42:11] <maddiin> output would be: June 13, 2008 at 4:29:04 PM CEST
  764. [17:42:12] <mkaply> technically year alone is a valid date
  765. [17:42:29] <mkaply> 2004 was a date
  766. [17:42:34] <tantek> maddiin - also, "value" excerpts need to be on children, not the element itself
  767. [17:42:44] <tantek> 2004 is an ISO8601 year
  768. [17:43:04] <tantek> but not a valid "date" as far as vCard and iCalendar "date" type goes
  769. [17:43:05] <mkaply> but we just said we'd use punctuation to know the date from the tiem
  770. [17:43:13] <mkaply> I guess time always has ":"
  771. [17:43:17] <BobJonkman> mkaply, maddin et al: HTML5 datetime parsing alogrithm at
  772. [17:43:28] <mkaply> I don't really like your split dtstart/dtend though
  773. [17:43:37] <mkaply> I think that will be tough to implement
  774. [17:43:54] <tantek> mkaply, yes that does make more work for parsers, but it is better for the content, and reducing duplication/triplication of data
  775. [17:44:23] <hober> Atom references the date-time production in RFC3339.
  776. [17:44:33] <tantek> which is derived from W3C-datetime
  777. [17:44:38] <tantek> which is a subset of ISO8601
  778. [17:44:45] <mkaply> BobJonkman: excuse my while I shoot myself in the head
  779. [17:44:46] <hober> right
  780. [17:44:56] <hober> but "2004" doesn't match that production
  781. [17:44:59] <hober> 2004-01-01 does
  782. [17:45:08] <BobJonkman> mkaply: perhaps I should have appended a smiley or several...
  783. [17:45:58] * veeliam (n=veeliam@ Quit (Read error: 104 (Connection reset by peer))
  784. [17:46:32] <tantek> perhaps we won't be normatively referencing the HTML5 datetime parsing alogrithm ;)
  785. [17:48:27] * charlenopires (n=charleno@ Quit (Client Quit)
  786. [17:48:54] * NatBat (i=568eef7c@gateway/web/ajax/ Quit (" ajax IRC Client")
  787. [17:50:31] * bergie_ ( has joined #microformats
  788. [17:51:39] * bergie ( Quit (Read error: 104 (Connection reset by peer))
  789. [17:52:11] * pat-in-wv ( has joined #microformats
  790. [17:52:19] * pat-in-wv ( has left #microformats
  791. [18:01:33] * trovster ( Quit ()
  792. [18:06:04] <mfbot> [[events/2008-06-24-weekly-meetup-dinner]] M * Steve Ganz * (+27) attendees -
  793. [18:07:22] * Hey_neken ( has joined #microformats
  794. [18:09:20] <mkaply> tantek: actually, your split dtstart/dtend will be very difficult to parse because that's unlike any pattern we've had in the past
  795. [18:09:45] <mfbot> [[machine-data]] * Tantek * (+1102) As Invisible Supplementary Data - - noted additional violations of principles, worse expected data quality due to separation of duplicate data
  796. [18:09:49] <mkaply> you have two values from two different dtstarts and you actually have to figure out how to combine them
  797. [18:10:06] <tantek> mkaply it is small set of possible values (date, time, tz)
  798. [18:10:14] <tantek> and the combination is very straight forward
  799. [18:10:29] <tantek> currently parsers only look at the first dtstart for example
  800. [18:10:37] <tantek> this extends that only a little
  801. [18:10:46] * Phae ( has joined #microformats
  802. [18:10:46] <jibot> Phae is Frances Berriman of
  803. [18:10:46] * ChanServ sets mode +o Phae
  804. [18:10:53] <mkaply> Except that the plural case of every other property is to represent it as a plural property.
  805. [18:11:06] <mkaply> This is the first time that plurality means "process and combine into a non plural property"
  806. [18:11:06] <tantek> to look at the first date that is specified, the first time that is specified (if any), and the first tz that is specified (if any)
  807. [18:11:22] <tantek> mkaply, not true. "note" on hCard works like this
  808. [18:11:31] <tantek> it's a singular property
  809. [18:11:40] <tantek> that you can specify multiple instances of and have concatenated
  810. [18:11:44] * julianstahnke ( Quit ("Leaving...")
  811. [18:11:55] <tantek> in the case of datetime, the compounding is a bit more than just concatenating
  812. [18:12:10] <tantek> but the same concept of "process and combine into a non plural property" is at work
  813. [18:12:33] <mkaply> tantek: actually if you look at the way parsers are representing note, it is as a plural property
  814. [18:12:43] <mkaply> it is only combined when you give it to a service
  815. [18:12:52] <tantek> interesting
  816. [18:12:59] <Phae> i'm just reading back over the logs
  817. [18:13:01] <tantek> semantically it is singular though, then
  818. [18:13:06] <mkaply> in our context, plural property means "can have more than one instance in a microformat"
  819. [18:13:06] * bluesmoon ( has joined #microformats
  820. [18:13:06] <jibot> bluesmoon is Philip <> & improves performance at Yahoo! & likes food & hacking & lives in the valley
  821. [18:13:11] <mkaply> not what it looks like in the Vcard
  822. [18:13:39] <tantek> the semantic of singularity of a property is the same (in hCard or vCard)
  823. [18:14:01] <tantek> how it's parsed may be different
  824. [18:14:13] <tantek> and thus multiple uses of the classname may result in a single value
  825. [18:14:20] <mkaply> Actually a vcard can have multiple NOTE:, so that's not singular
  826. [18:14:25] <jibot> Grant is Grant Henninger and is at
  827. [18:14:34] <tantek> mkaply, not in practice
  828. [18:14:56] <tantek> all vCard implementations I've seen only support a single note
  829. [18:14:59] <tantek> instance
  830. [18:16:21] <mkaply> Singular properties: 'fn', 'n', 'bday', 'tz', 'geo', 'sort-string', 'uid', 'class'. For properties which are singular, the first descendant element with that class SHOULD take effect, any others being ignored.
  831. [18:16:22] <mkaply> All other properties MAY be plural. Each class instance of such properties creates a new instance of that property.
  832. [18:18:19] <mkaply> There currently is no case in the spec where two separate properties <foo>one</foo> and <foo>two</foo> get combined into a foo onetwo
  833. [18:18:26] <mkaply> That's the whole point of value excerpting.
  834. [18:18:34] <mkaply> If that worked, we wouldn't need value excerpting
  835. [18:20:28] <tantek> value excerpting was introduced as a way to generalize what existed for the "note" property
  836. [18:20:51] <tantek> and to separate the value from the "type" subproperty
  837. [18:22:27] * charlenopires (n=charleno@ has joined #microformats
  838. [18:23:11] * rmarkwhite (i=rmarkwhi@gateway/tor/x-f49219723d40ee55) has joined #microformats
  839. [18:23:11] <jibot> rmarkwhite is Robert Mark White
  840. [18:23:42] <mfbot> [[datetime-design-pattern]] * Tantek * (+847) Machine-data in class - already discussed/rejected *many times*. violates existing modern web designer use of class names. totally opposed.
  841. [18:28:27] <mkaply> when the term "plural" is used, parsers interpret that has keep the data separate, not grab all instances of the data and combine it into a singular property.
  842. [18:28:49] <tantek> mkaply, fair enough, we need to document this better.
  843. [18:29:28] <mkaply> I've already implemented the basic case you guys described. But in my infrastructure (and I bet X2V), the other case will be quite difficulr
  844. [18:29:32] <mkaply> or difficult
  845. [18:29:50] <tantek> which basic case?
  846. [18:29:59] <tantek> sorry, I'm having a little trouble following
  847. [18:30:09] <mkaply> separating time and date into child values
  848. [18:30:18] <mkaply> That's easy
  849. [18:30:26] <tantek> ah great, that's good to know
  850. [18:30:30] <mkaply> The hard part is when you have two dtstarts on your page, one with the time, and later one with the date.
  851. [18:30:32] <mkaply> Taht's hard
  852. [18:30:46] <tantek> is the include pattern easier to implement?
  853. [18:33:48] <mkaply> include pattern is a breeze. Just copying DOM nodes.
  854. [18:34:03] <mkaply> It's done before I even parse the microformat
  855. [18:34:26] <mkaply> I'll think more. I might be able to come up with something.
  856. [18:34:27] <tantek> ah, good to know
  857. [18:34:45] <mkaply> I have the ability to insert customer getters for particular properties if they do interesting things.
  858. [18:34:55] <mkaply> So my infrastructure supports it, I just try to avoid them
  859. [18:35:32] <tantek> understandable
  860. [18:45:19] <mfbot> [[datetime-design-pattern]] * Tantek * (+1170) drafted proposal/brainstorm "date and time separation using value excerption" summary and simple example. more to come, documenting from IRC logs (link noted inline).
  861. [18:48:53] * bluesmoon ( Quit ("Ex-Chat")
  862. [18:52:37] * danbri (n=danbri@unaffiliated/danbri) Quit ()
  863. [18:59:40] <mfbot> [[datetime-design-pattern]] * JakeArchibald * (+195) Machine-data in class -
  864. [19:00:56] <mfbot> [[datetime-design-pattern]] * Tantek * (+370) date and time separation using value excerption - - subheads, started derivation section
  865. [19:02:06] * remi_ ( has joined #microformats
  866. [19:05:17] * emrojo (n=emrojo@ has left #microformats
  867. [19:06:13] <mfbot> [[datetime-design-pattern]] M * Tantek * (+351) added additional list of cons/justification for opposition, removed unnecessary "looks like you are" comment that didn't add to the discussion.
  868. [19:15:00] * cygri (n=cygri@ has joined #microformats
  869. [19:16:50] * drewinthehead ( has joined #microformats
  870. [19:16:50] <jibot> drewinthehead is the author of hKit and a developer at
  871. [19:16:50] * ChanServ sets mode +o drewinthehead
  872. [19:17:15] <Phae> wb drew
  873. [19:17:41] <drewinthehead> o hai Phae
  874. [19:17:46] <Phae> ;)
  875. [19:30:06] * drewinthehead ( Quit (Remote closed the connection)
  876. [19:30:46] * drewinthehead ( has joined #microformats
  877. [19:30:46] * ChanServ sets mode +o drewinthehead
  878. [19:34:19] * MrTopf ( Quit ()
  879. [19:35:28] * MrTopf ( has joined #microformats
  880. [19:39:49] * riffraff ( Quit (Remote closed the connection)
  881. [19:40:17] * MrTopf ( Quit (Read error: 104 (Connection reset by peer))
  882. [19:40:26] * MrTopf ( has joined #microformats
  883. [19:42:15] <mkaply> drewinthehead: did you catch any of the conversation about parsing the datetime-design stuff?
  884. [19:42:51] <drewinthehead> i didn't but not to follow in depth. was multitasking
  885. [19:43:12] <drewinthehead> i tend to be slow on the more involved issues - i need to re-read with greater care :)
  886. [19:44:24] <tantek> i'm writing up with more summary / readability on the wiki so hopefully it will be easier to read there.
  887. [19:44:39] <drewinthehead> that'd be great, tantek
  888. [19:45:00] <tantek> in short, I had what I thought was a good idea, but BobJonkman's contributions made it a *great* idea IMHO.
  889. [19:45:07] * jgraham ( Quit ("leaving")
  890. [19:45:13] <tantek> or perhaps that should be IMNSHO ;)
  891. [19:45:28] <tantek> and the IRC logs show the derivation
  892. [19:46:11] <Phae> i still have abbr related reservations, but i shall withhold judgement for now.
  893. [19:48:12] <mkaply> Phae: as in you wish abbr wasn't involved at all?
  894. [19:48:26] <Phae> pretty much.
  895. [19:48:34] <Phae> i don't always agree with its use
  896. [19:48:46] * rmarkwhite (i=rmarkwhi@gateway/tor/x-f49219723d40ee55) Quit (Remote closed the connection)
  897. [19:48:54] * Phae is trying not to open that can. again.
  898. [19:51:15] * rmarkwhite (i=rmarkwhi@gateway/tor/x-cdbc8f446d0b30f0) has joined #microformats
  899. [19:51:30] * tantek is copy and pasting and editing from IRC logs.
  900. [19:51:37] * tantek thanks Robert Bachmann yet again.
  901. [19:56:35] * MrTopf ( Quit (Read error: 110 (Connection timed out))
  902. [20:03:56] <mfbot> [[datetime-design-pattern]] * Tantek * (+8087) date and time separation using value excerption - - noted a few advantages, added some more derivation, noted a few issues raised and resolved.
  903. [20:06:02] <mfbot> [[datetime-design-pattern]] M * Tantek * (-13) date and time separation using value excerption - - fix a few timevalue
  904. [20:07:19] * KevinMarks (n=KevinMar@nat/google/x-38d7fd827eda2f4e) has joined #microformats
  905. [20:09:09] <mfbot> [[datetime-design-pattern]] M * Tantek * (-6) advantages -
  906. [20:10:05] <mfbot> [[abbr-date-pattern]] MN * Tantek * (+33)
  907. [20:10:51] <mfbot> [[abbr-datetime-pattern]] MN * Tantek * (+37)
  908. [20:12:42] <tantek> drewinthehead, Phae ok here is what I could copy/paste/edit from IRC to wiki in short order - please excuse any imprecision as potential editing mistake(s) rather than intentional:
  909. [20:14:29] <Phae> ok
  910. [20:15:33] <drewinthehead> thanks
  911. [20:16:03] <tantek> I linked to the IRC discussion in a few places to provide citations in case that version is more readable than my edits
  912. [20:20:54] * danbri (n=danbri@unaffiliated/danbri) has joined #microformats
  913. [20:25:08] <mfbot> [[recipe-brainstorming]] * Yde * (+384) Issues -
  914. [20:33:55] * dotjay (n=dotjay@ has joined #microformats
  915. [20:36:39] <mfbot> [[presentations]] * GeraldBauer * (+25) removed old preso and added link to new one from april talk
  916. [20:41:10] <mfbot> [[recipe-brainstorming]] * Yde * (+139) Discussion - added discussion about alternative ingredients
  917. [20:41:16] <mfbot> [[events]] * GeraldBauer * (+170) added note about Vancouver Semantic(Web)Camp 2008
  918. [20:41:58] * NatBat (i=568eef7c@gateway/web/ajax/ has joined #microformats
  919. [20:41:59] <jibot> NatBat is Natalie Downe and can be found online at
  920. [20:44:08] * dotjay (n=dotjay@ Quit ("/me can has exit.")
  921. [20:44:17] <drewinthehead> hey NatBat
  922. [20:49:53] <drewinthehead> i think the google social graph api must have me blacklisted ... searches for me never work
  923. [20:52:11] <NatBat> Hello drewinthehead and peeps :)
  924. [20:52:18] <mfbot> [[datetime-design-pattern]] M * TobyInk * (+873) Machine-data in class -
  925. [20:53:09] <mfbot> [[datetime-design-pattern]] M * TobyInk * (+3) Machine-data in class -
  926. [20:57:16] * NatBat (i=568eef7c@gateway/web/ajax/ Quit (" ajax IRC Client")
  927. [21:04:23] * drewinthehead wonders if 30 slides is too many for a 5 minute intro to microformats
  928. [21:04:56] <Phae> not if they're just clangers
  929. [21:18:14] * bergie_ ( Quit ()
  930. [21:19:40] <drewinthehead> 10 seconds per slide
  931. [21:19:54] * drewinthehead gulps
  932. [21:19:59] <Phae> will this be filmed? :)
  933. [21:20:11] <drewinthehead> i think they tend to be
  934. [21:20:38] * Phae just realised how weird it is to say "filmed" these days.
  935. [21:20:51] <drewinthehead> better than 'taped' i think
  936. [21:21:02] <Phae> i say that, too.
  937. [21:21:31] <drewinthehead> i still prefer 'film' to 'movie', even if no film is involved.
  938. [21:22:08] <Phae> me too :)
  939. [21:23:12] <drewinthehead> movie is way more archaic ... "moving picture" ... i'm off to catch a talkie!
  940. [21:23:23] <Phae> heh
  941. [21:23:59] <drewinthehead> my slides are up
  942. [21:24:31] <Phae> :D
  943. [21:26:51] <mfbot> [[datetime-design-pattern]] * TobyInk * (+929) advantages - dark data sometimes desired
  944. [21:32:48] <mfbot> [[datetime-design-pattern]] * Tantek * (+920) advantages - dark data is never desirable regardless of whether publishing it is sometimes desired.
  945. [21:33:59] <mfbot> [[datetime-design-pattern]] M * Tantek * (+71) date and time separation using value excerption - move discussion to discussion section
  946. [21:34:40] <mfbot> [[datetime-design-pattern]] M * Tantek * (+39) discussion - back link
  947. [21:35:57] <tantek> folks we need to make it more clear that if you want to work on invisible metadata, microformats is not the place for it
  948. [21:36:13] <tantek> I know it sounds harsh, but this is one of the key distinguishing aspects and principles of microformats.
  949. [21:36:44] <tantek> If you want to work on invisible metadata or "dark data", there are lots of folks working on that in XML and RDF, and to some extent RDFa communities.
  950. [21:37:07] <tantek> Better to join those efforts and advance that work than attempt to corrupt microformats into something they shouldn't be.
  951. [21:37:30] * tobyink ( has joined #microformats
  952. [21:37:30] <jibot> tobyink is tobyink
  953. [21:43:17] <hober> hear hear
  954. [21:43:26] <hober> metacrap FTL
  955. [21:50:11] * NatBat (i=568eef7c@gateway/web/ajax/ has joined #microformats
  956. [21:50:11] <jibot> NatBat is Natalie Downe and can be found online at
  957. [21:51:35] * DavidMead ( has joined #microformats
  958. [21:53:59] <mkaply> drewinthehead: thank you for that image. My eyes are bleeding
  959. [21:54:40] <hober> mkaply: I have that same model laptop; I momentarily thought that it was my laptop and felt gross.
  960. [21:57:41] <BobJonkman> tantek: Nice work on the Wiki so far!
  961. [21:58:36] <BobJonkman> This new principle for datetime, could it be applied to the reuse of data in hResume?
  962. [21:59:34] * charlenopires (n=charleno@ Quit (Client Quit)
  963. [21:59:48] * DavidMead ( has left #microformats
  964. [22:00:14] * purp_ (n=jmeyer@ has joined #microformats
  965. [22:01:14] <BobJonkman> I've never been very happy with the <object> element for referencing hCard data in class="experience"
  966. [22:03:23] * purp__ (n=jmeyer@ has joined #microformats
  967. [22:03:46] * purp (n=jmeyer@ Quit (Read error: 104 (Connection reset by peer))
  968. [22:07:25] * NatBat (i=568eef7c@gateway/web/ajax/ Quit (" ajax IRC Client")
  969. [22:09:08] * KevinMarks (n=KevinMar@nat/google/x-38d7fd827eda2f4e) Quit ("The computer fell asleep")
  970. [22:10:32] <csarven> BobJonkman
  971. [22:13:03] <BobJonkman> csarven: Thanx! I'll collect my thoughts and provide justification (something better than "I've never been happy with...")
  972. [22:18:17] * dw (n=dw@unaffiliated/dw) Quit ("bbiab")
  973. [22:18:31] * purp_ (n=jmeyer@ Quit (Read error: 110 (Connection timed out))
  974. [22:20:25] * vbgunz (n=vbgunz@ Quit (Remote closed the connection)
  975. [22:20:47] * mkaply (n=chatzill@nat/ibm/x-2d0523e707b137db) Quit (Read error: 110 (Connection timed out))
  976. [22:24:36] * BobJonkman (n=BobJonkm@ Quit (Read error: 104 (Connection reset by peer))
  977. [22:26:21] * bogdanlazarsb ( has left #microformats
  978. [22:28:57] * danbri (n=danbri@unaffiliated/danbri) Quit ()
  979. [22:29:03] * SunWuKung ( Quit ()
  980. [22:32:44] * KevinMarks ( has joined #microformats
  981. [22:35:30] * dw ( has joined #microformats
  982. [22:39:07] * jonnys1234 ( Quit ()
  983. [22:40:10] * vbgunz (n=vbgunz@ has joined #microformats
  984. [22:41:04] * BenWard ( has joined #microformats
  985. [22:41:04] * ChanServ sets mode +o BenWard
  986. [22:41:04] <jibot> BenWard is a Web Developer at Yahoo! Europe and an admin at and based in the UK and better defined at
  987. [22:43:52] * DanWrong ( has joined #microformats
  988. [22:55:18] * remi_ ( Quit (Read error: 110 (Connection timed out))
  989. [22:55:32] * danbri (n=danbri@unaffiliated/danbri) has joined #microformats
  990. [22:56:44] <csarven> BenWard Hi
  991. [22:56:53] <BenWard> Hi csarven
  992. [22:57:04] * purp__ (n=jmeyer@ Quit ()
  993. [22:57:20] <csarven> Check this out: the
  994. [22:57:51] * remi_ ( has joined #microformats
  995. [22:58:15] <BenWard> Ah, interesting
  996. [22:58:17] <csarven> I'm not sure if I've overlooked something but I think <object> is misused in the case of the include-pattern
  997. [22:58:54] <csarven> First noted this: (see my response to AndiBaio)
  998. [22:59:20] <BenWard> For my tastes, I'm in favour of deprecating the object form if possible (and treat it as such in my own work), simply off the back of the rendering issues it causes. I'm not sure if we need a use case for invisible includes any more, so it might be feasible to drop it.
  999. [23:00:07] <BenWard> The semantics are more interesting, and I'd need to check the spec more fully, but your issue seems reasonable
  1000. [23:00:21] <BenWard> The reason for object is the supposed need for invisible includes — hyperlink needs inner text.
  1001. [23:00:54] <BenWard> But that was for hResume, and I think the requirement predates just having hCards for the organisations themselves, without having to reidentify the person.
  1002. [23:01:05] <BenWard> Or, if it doesn't predate it, I'm unsure why a company hCard wouldn't be acceptable.
  1003. [23:01:16] * pawel314 ( Quit (Read error: 104 (Connection reset by peer))
  1004. [23:01:36] <BenWard> Or, if it is required to have an explicit connection between the subjects hCard and the organisations they worked for, I wonder if AGENT could be used…
  1005. [23:01:46] <BenWard> Anyway, huge number of possible threads in that :D
  1006. [23:02:26] <BenWard> I'll try to give the include pattern a look over in the near future, I'm pretty filled up with the machine-data work at the mo, and also I'm in the process of moving to the US, which is a pretty busy thing!
  1007. [23:03:09] <csarven> We are all (theoratically) moving all the time, Ben :P
  1008. [23:03:39] <BenWard> Theoretically true, I on the other hand am facing a physical move of some 6000 miles!
  1009. [23:04:04] <BenWard> Err, maybe more. I don't know the distance between London and San Francisco off the top of my head.
  1010. [23:04:06] <csarven> I will be moving to a new location this weekend (only a few blocks away)
  1011. [23:04:12] <csarven> Permanently?
  1012. [23:04:32] <BenWard> Indefinite timescale. I'm moving from Yahoo! Europe to the Brickhouse team in San Fran
  1013. [23:04:38] <BenWard> Certainly will be over for a few years.
  1014. [23:04:44] <csarven> Nice
  1015. [23:05:00] <tantek> BenWard - company hCard is insufficient for hResume because the *title* is listed as part of experience, and that is for the *person*, not the company
  1016. [23:05:04] <csarven> I haven't been to SF (only airport)
  1017. [23:05:14] <BenWard> @tantek: Ah, ok
  1018. [23:05:33] <BenWard> @tantek: T'was just a pondering. hResume predates me :)
  1019. [23:06:01] <tantek> I too would be ok deprecating <object> for include-pattern, but only if keep the option of using empty (or only with title attribute) <a href>
  1020. [23:06:45] <csarven> <a> doesn't have to be empty
  1021. [23:06:51] <BenWard> Yeah, real-world accessibility testing revealed that's not really an option — hence keeping OBJECT in there for the invisible part.
  1022. [23:06:59] <csarven> What would the @title be for in <a>?
  1023. [23:07:00] <tantek> I want to keep the *option* of using empty <a href>
  1024. [23:07:12] <tantek> of course it doesn't have to be empty
  1025. [23:07:15] <csarven> Sure, it shouldn't effect anything
  1026. [23:07:17] <tantek> we're talking about an *option* here
  1027. [23:07:29] <csarven> What's @title for?
  1028. [23:07:50] <tantek> some folks wanted to markup the include-pattern empty <a href>s with some additional information
  1029. [23:07:59] <tantek> an inline expansion
  1030. [23:09:43] <tantek> can anyone expand on what this means? "The current accessibility understanding is that empty links can present a barrier to screen reader users." what barrier?
  1031. [23:10:02] <tantek> does anyone have any evidence of *any* screen reader doing anything other than *ignoring* empty links?
  1032. [23:10:29] <BenWard> Yes:
  1033. [23:10:32] <csarven> I thought they simply ignored them. Perhaps @title is read if empty?
  1034. [23:10:43] <tantek> BenWard - that' where I got the quote
  1035. [23:10:47] <tantek> but that article doesn't expand on it
  1036. [23:10:48] <tantek> at all
  1037. [23:10:51] <tantek> AFAICT
  1038. [23:11:39] <BenWard> Then I suggest leaving a comment on the article for clarification. The tables below show the test results where empty links have the href attribute read aloud.
  1039. [23:11:43] <tantek> the include pattern use of empty <a href> is similar to <param> or <link> - it's an instruction for the parser, not data itself, certainly not a "hyperlink" to be navigated.
  1040. [23:11:44] <csarven> So default appears to be to read out the @title if the element is empty
  1041. [23:12:46] <BenWard> No, as noted below the results, the title is read out _when_ the screen reader user has configured their software to do so
  1042. [23:12:59] * danbri (n=danbri@unaffiliated/danbri) Quit ()
  1043. [23:13:16] <tantek> ah I see the "href read aloud" bug
  1044. [23:13:20] <tantek> that sucks
  1045. [23:14:33] <BenWard> Yeah, it does a bit.
  1046. [23:14:40] <BenWard> I think I'd like to build a screen reader one day
  1047. [23:14:42] <tantek> yes, the content publishing practices that the include-pattern solves requires an option that does NOT include any inner text
  1048. [23:15:01] * purp (n=jmeyer@ has joined #microformats
  1049. [23:15:03] <tantek> so if that's not <a href> then we have to find another
  1050. [23:15:18] <BenWard> Well, that's why we still have object
  1051. [23:15:32] <BenWard> Although csarven's new issue calls that in for review
  1052. [23:16:08] <tantek> perhaps the problem is with using the data attribute of object
  1053. [23:16:25] <BenWard> Do you have capacity to handle editorial duties on include-pattern at the mo, Tantek?
  1054. [23:16:39] <tantek> what if we used a plain <object> and placed the include-pattern instruction into a <param> insie the object?
  1055. [23:16:54] <BenWard> Worth testing with.
  1056. [23:16:55] <tantek> to some extent yes (editorial)
  1057. [23:16:57] <csarven> Isn't <param> deprecated in XHTML?
  1058. [23:17:04] * csarven checks
  1059. [23:17:09] <tantek> um no
  1060. [23:17:23] <BenWard> No, pretty sure it's still there :)
  1061. [23:17:28] <tantek> I mean, it's uglier and with more markup, but we need a solution that doesn't alter the text content.
  1062. [23:20:33] <dw> i saw that bbc blog entry. does RDFa have any similar problems?
  1063. [23:20:42] <csarven> You guys are right, it is still okay. Why did I think that it is deprecated. I must have been thinking of <embed> which is acknowledged by W3C whatsoever.
  1064. [23:20:48] <BenWard> I'm not aware of any include pattern in RDFa
  1065. [23:20:55] <csarven> err NOT acknowledged
  1066. [23:21:14] <BenWard> Maaaaybe XLink or something with XHTML would fill a similar role for that tech
  1067. [23:21:16] <dw> oh, think we're talking about 2 different things. this is the hCard problem right?
  1068. [23:21:32] <BenWard> include-pattern
  1069. [23:21:34] <tantek> <param valuetype="ref" value="#bricklayers-card" />
  1070. [23:21:44] <tantek> or in full:
  1071. [23:22:37] <tantek> <object><param valuetype="ref" value="#bricklayers-card" /></object>
  1072. [23:22:55] <tantek> or if you really wanted to make it clear to useragents that they if they don't understand the include-pattern, they should ignore
  1073. [23:23:17] <tantek> <object declare="declare" class="include"><param valuetype="ref" value="#bricklayers-card" /></object>
  1074. [23:23:51] <BenWard> Interesssssting.
  1075. [23:24:27] <BenWard> Definitely worth building a test case for, since avoiding data=#something could feasibly avoid that repeat HTTP-request issue that was reported as well
  1076. [23:25:07] <csarven> Doesn't that still use <object>? The point was not to use <object> if it is text/html
  1077. [23:25:08] <tantek> right
  1078. [23:25:19] <tantek> right on BenWard that is
  1079. [23:28:29] <tantek> ok, don't all shoot at once, but in looking through there may be another include-pattern alternative to consider
  1080. [23:28:42] <BenWard> It's definitely worth looking into. It would be much better if we could have an include pattern with just one syntax with not exceptions, really.
  1081. [23:28:51] <tantek> empty <ins>, using its cite attribute for the reference
  1082. [23:28:59] <tantek> include is an insertion of a sort
  1083. [23:29:20] <tantek> though that is bending the semantics of the cite attribute on ins at best
  1084. [23:29:23] <tantek> e.g.
  1085. [23:29:41] <BenWard> ‘This attribute is intended to point to information explaining why a document was changed.’
  1086. [23:29:41] <tantek> <ins class="include" cite="#bricklayers-card"></ins>
  1087. [23:29:48] <tantek> exactly
  1088. [23:30:04] <tantek> but there's nothing for a screen reader to latch onto (obviously needs testing)
  1089. [23:31:05] * Phae ( Quit ("Leaving.")
  1090. [23:31:28] <mfbot> [[Main Page]] * Wikiword * (+27)
  1091. [23:31:54] <mfbot> [[Main Page]] M * Tantek * (-27) Reverted edit of Wikiword, changed back to last version by JacobMalthouse
  1092. [23:32:16] <mfbot> [[Special:Log/block]] * Tantek * (+0) blocked "User:Wikiword" with an expiry time of infinite: vandal
  1093. [23:32:17] <BenWard> For me, I disagree with breaking with HTML semantics like that.
  1094. [23:32:22] * cygri (n=cygri@ Quit ()
  1095. [23:32:45] <tantek> BenWard, I tend to lean in that direction as well. Then again, when was the last time you saw an <ins> with cite attribute? Like never?
  1096. [23:33:04] <tantek> In all my years I've *never* seen an instance of that in the wild (non test-case)
  1097. [23:33:23] <tantek> so how much harm would it do for us to re-appropriate a long unused attribute?
  1098. [23:34:31] <tantek> and finally, there is the already used to stuff tons of stuff <script> element
  1099. [23:34:36] <tantek> e.g.
  1100. [23:34:58] <BenWard> That's true, but I don't think we as have the authority to steal semantics of HTML elements, however infrequent their use. We build on top of HTML, not in place of it. Where we don't have an element that matches our semantic need, we've gotta fall back to HTML's generics instead.
  1101. [23:35:39] <BenWard> It's frustrating — seeing <ins> and it being _close_ to what we'd like, but it's not a match.
  1102. [23:36:06] <BenWard> It's a hexagon in the octagon hole :)
  1103. [23:37:02] <tantek> it would be interesting to see if anyone actually cared about <ins cite>
  1104. [23:37:02] <csarven> Would the use of <cite> be stretching this?
  1105. [23:37:30] <tantek> as I was saying, finally, there is the overly abused/stuffed script element:
  1106. [23:37:31] <csarven> "a reference to other source"
  1107. [23:37:35] <BenWard> BRB — I'm going to lose my connection as I switch to Yahoo VPN. Have to reconnect
  1108. [23:37:35] <tantek> e.g. <script class="include" type="text/x-include" src="#bricklayers-card"></script>
  1109. [23:38:11] <mfbot> [[datetime-design-pattern]] M * TobyInk * (+375) discussion -
  1110. [23:39:34] * bennewarde ( has joined #microformats
  1111. [23:40:05] * KevinMarks ( Quit ("The computer fell asleep")
  1112. [23:43:39] <tobyink> @tantek - <script> is certainly an option. it seems to be what a lot of people are using to embed custom data in HTML
  1113. [23:44:28] <tobyink> perhaps type="text/html" would be more accurate though
  1114. [23:45:17] <mfbot> [[datetime-design-pattern]] * Tantek * (+702) type data != content data, don't conflate them. if you think everything is data, consider spending your time in a system that thinks that way, e.g. RDF, rather than HTML+microformats.
  1115. [23:45:31] <bennewarde> <script> is interesting, and does semantically follow somewhat. It's there for the purpose of a script, ultimately — albeit one not part of the page.
  1116. [23:46:42] <tantek> do we need to write up a document on "why microformats might not be for you?"
  1117. [23:46:54] <tantek> that has stuff like:
  1118. [23:47:02] <tantek> do you like dark data?
  1119. [23:47:07] <tantek> do you think of *everything* as data?
  1120. [23:48:54] <bennewarde> I'm not really comfortable with how uptight the machine-data/abbr discussion is getting.
  1121. [23:49:15] <tantek> it's just another "what is data?" rathole
  1122. [23:49:28] <tantek> I've spent far too much time in discussions of that sort in W3C meetings etc.
  1123. [23:49:33] <tantek> it's basically a waste of time
  1124. [23:50:29] <tantek> basically, if you want to do invisible data, and/or treat a system as generic data, then HTML+microformats really are not for you, there are other technologies (and communities) to pursue dark generic data.
  1125. [23:51:42] <bennewarde> Yes, but we don't go down that discussion route. We just stay focussed on the identified problems, and where a remark or otherwise deviates, it doesn't need to be followed up, or any follow up remains in context of the problem.
  1126. [23:52:02] <tantek> this is why we probably need a separate page on this topic
  1127. [23:52:05] <tantek> hence I asked
  1128. [23:52:11] <tantek> do we need to write up a document on "why microformats might not be for you?"
  1129. [23:52:22] <tantek> that lists all the distractions that such folks tend to get into
  1130. [23:52:34] <tantek> all the ratholes that are basically not worth the time
  1131. [23:52:52] <tantek> (not in this community at least)
  1132. [23:53:51] <bennewarde> I'm unsure if that will help. If it's possible to write such a page in a neutral informative matter, then fine. But if it just ends up coming across as an argument device in the discussions, I'd recommend deferring it until after on this occasion.
  1133. [23:54:06] <tantek> certainly this will all provide good material for discussion at tonight's dinner.
  1134. [23:54:15] <tantek> we can't be neutral because we have principles
  1135. [23:54:22] <tantek> that's what makes microformats what they are
  1136. [23:54:28] <tantek> because we do say NO to plenty of things
  1137. [23:54:49] <tantek>
  1138. [23:54:58] <tantek> specifically:
  1139. [23:55:02] <tantek> perhaps that needs some expansion
  1140. [23:55:58] <tantek> The sooner we save people time by making it clear that exploring such things are not considered good use of the community's time, the sooner it saves both the community time, and the dark generic data newcomer.
  1141. [23:56:02] * BenWard ( Quit (Read error: 110 (Connection timed out))
  1142. [23:56:10] * bennewarde is now known as BenWard
  1143. [23:56:10] * charlenopires (n=charleno@ has joined #microformats
  1144. [23:56:11] * ChanServ sets mode +o BenWard
  1145. [23:58:43] <tantek> We did a lot of this in the early days of microformats, and I fear that some of that continuous vigilance has been forgotten in community memory.
  1146. [23:59:26] <tobyink> 3 years is a long time on the internet though - it's good to re-examine choices and see whether they are still valid

These logs were automatically created by mflogbot on using a modified version of the Java IRC LogBot.

See for more information.