IRC Log for #microformats on 2008-06-24

• Index
• Next: 2008-06-25
• Previous: 2008-06-23

Timestamps are in UTC.

1. [00:04:56] <mfbot> [[events/2008-06-23-weekly-meetup-dinner]] http://microformats.org/wiki?title=events/2008-06-23-weekly-meetup-dinner&diff=0&oldid=27407 * Tantek * (+171) add Pownce and Upcoming URLs and venue to details
2. [00:05:57] <mfbot> [[events/2008-06-23-weekly-meetup-dinner]] M http://microformats.org/wiki?title=events/2008-06-23-weekly-meetup-dinner&diff=0&oldid=27408 * Tantek * (+0) fix dates
3. [00:06:43] <mfbot> [[events/2008-06-23-weekly-meetup-dinner]] http://microformats.org/wiki?title=events/2008-06-23-weekly-meetup-dinner&diff=0&oldid=0 * Tantek * (+4414) events/2008-06-23-weekly-meetup-dinner moved to events/2008-06-24-weekly-meetup-dinner
4. [00:08:54] <mfbot> [[events]] http://microformats.org/wiki?title=events&diff=0&oldid=27409 * Tantek * (+39) fix date, add Pownce url to weekly dinner meetup
5. [00:12:22] * singpolyma (n=singpoly@node-2784.tor.pppoe.execulink.com) Quit ("Lost terminal")
6. [00:15:31] * vbgunz (n=vbgunz@72.186.68.186) Quit (Remote closed the connection)
7. [00:24:51] * charlenopires (n=charleno@189.82.254.13) Quit (Read error: 104 (Connection reset by peer))
8. [00:26:57] * jonnys1234 (n=johnsout@cpc1-acto6-0-0-cust434.brnt.cable.ntl.com) Quit (Read error: 110 (Connection timed out))
9. [00:38:45] * purp (n=jmeyer@64.74.221.28) has joined #microformats
10. [00:40:58] * pjkix (n=pkhalil@74.85.6.194) Quit (Read error: 110 (Connection timed out))
11. [00:41:32] * purp__ (n=jmeyer@99-204-142-97.area1.spcsdns.net) has joined #microformats
12. [00:43:55] * purp__ (n=jmeyer@99-204-142-97.area1.spcsdns.net) Quit (Read error: 104 (Connection reset by peer))
13. [00:44:00] * cygri (n=cygri@83.141.79.111) Quit ()
14. [00:44:08] * purp__ (n=jmeyer@64.74.221.28) has joined #microformats
15. [00:44:33] * purp (n=jmeyer@64.74.221.28) Quit (Read error: 104 (Connection reset by peer))
16. [00:46:04] * shigeta (n=shigeta@124.32.114.226) has joined #microformats
17. [00:54:16] * purp_ (n=jmeyer@64.74.221.28) Quit (Read error: 110 (Connection timed out))
18. [01:07:59] <mfbot> [[user/AngeloGladding]] N http://microformats.org/wiki/user/AngeloGladding * AngeloGladding * (+64)
19. [01:08:10] <mfbot> [[user/AngeloGladding]] http://microformats.org/wiki?title=user/AngeloGladding&diff=0&oldid=27410 * AngeloGladding * (+4)
20. [01:08:21] <mfbot> [[user/AngeloGladding]] http://microformats.org/wiki?title=user/AngeloGladding&diff=0&oldid=27411 * AngeloGladding * (-2)
21. [01:21:18] * danja (n=danja@host143-55-dynamic.9-79-r.retail.telecomitalia.it) has joined #microformats
22. [01:21:18] <jibot> danja is Danny Ayers, http://dannyayers.com
23. [01:23:59] * danja (n=danja@host143-55-dynamic.9-79-r.retail.telecomitalia.it) has left #microformats
24. [01:43:50] * dw (n=dw@unaffiliated/dw) Quit ("*click*")
25. [01:43:54] * dw (n=dw@gw.dmw.me.uk) has joined #microformats
26. [01:51:31] * KevinMarks (n=KevinMar@nat/google/x-91f0732d283c0198) Quit ("The computer fell asleep")
27. [01:53:46] * ianloic (i=yakk@glub.dreamhostps.com) has joined #microformats
28. [02:32:02] * danja (n=danja@host191-53-dynamic.36-79-r.retail.telecomitalia.it) has joined #microformats
29. [02:32:02] <jibot> danja is Danny Ayers, http://dannyayers.com
30. [02:57:56] * SunWuKung (n=SunWuKun@S01060016cbc4c705.vc.shawcable.net) 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 (n=pat-in-w@dpc693595205.direcpc.com) has joined #microformats
34. [03:24:00] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) has left #microformats
35. [03:25:58] * danja (n=danja@host191-53-dynamic.36-79-r.retail.telecomitalia.it) Quit ()
36. [03:57:29] <mfbot> [[events/2008-06-24-weekly-meetup-dinner]] M http://microformats.org/wiki?title=events/2008-06-24-weekly-meetup-dinner&diff=0&oldid=27412 * Tantek * (+0) attending
37. [04:14:09] * purp__ (n=jmeyer@64.74.221.28) Quit ()
38. [05:08:32] * csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) Quit ("http://www.csarven.ca/")
39. [05:28:13] * veeliam (n=veeliam@207.111.252.10) has joined #microformats
40. [06:19:36] * bergie (n=bergie@cs181192153.pp.htv.fi) has joined #microformats
41. [06:19:36] <jibot> bergie is lives in Finland and blogs at http://bergie.iki.fi/blog/ 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 (n=dw@gw.dmw.me.uk) has joined #microformats
44. [06:55:26] <mfbot> [[blog-quote-examples]] http://microformats.org/wiki?title=blog-quote-examples&diff=0&oldid=27413 * 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 (n=bogdanla@88-158-221-198.Asconet.ro) has joined #microformats
48. [07:17:27] * drewinthehead (n=drewinth@chauchcr.gotadsl.co.uk) Quit (Read error: 110 (Connection timed out))
49. [07:20:59] * SunWuKung (n=SunWuKun@S01060016cbc4c705.vc.shawcable.net) has joined #microformats
50. [07:33:13] * dw (n=dw@gw.dmw.me.uk) has joined #microformats
51. [07:35:01] * OsRo (n=osro@195-5-86-65.usul.arrakis.es) has joined #microformats
52. [07:37:41] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-c9f23ef65f18ce68) Quit ("http://www.mibbit.com ajax IRC Client")
53. [07:48:29] * drewinthehead (n=drewinth@eoms2.gotadsl.co.uk) has joined #microformats
54. [07:48:29] <jibot> drewinthehead is the author of hKit and a developer at http://edgeofmyseat.com
55. [07:48:29] * ChanServ sets mode +o drewinthehead
56. [07:49:53] * bogdanlazarsb (n=bogdanla@88-158-221-198.Asconet.ro) has left #microformats
57. [07:49:58] * levitation[A] (n=levitati@noorus.aklubi.ee) Quit (Excess Flood)
58. [07:56:15] * levitation[A] (n=levitati@noorus.aklubi.ee) has joined #microformats
59. [08:01:25] * trovster (n=trovster@creation1.plus.com) has joined #microformats
60. [08:01:25] <jibot> trovster is a web developer from the UK who writes on http://www.trovster.com and helps with www.multipack.co.uk
61. [08:01:55] * MrTopf (i=hidden-u@oecher.info) has joined #microformats
62. [08:03:17] * MrTopf (i=hidden-u@oecher.info) Quit (Read error: 104 (Connection reset by peer))
63. [08:03:23] * MrTopf (i=hidden-u@oecher.info) has joined #microformats
64. [08:09:41] <mfbot> [[hcalendar-examples-in-wild]] http://microformats.org/wiki?title=hcalendar-examples-in-wild&diff=0&oldid=27414 * Tantek * (+285) added Squid List specific event pages.
65. [08:11:03] * jonnys1234 (n=johnsout@cpc1-acto6-0-0-cust434.brnt.cable.ntl.com) has joined #microformats
66. [08:16:17] <mfbot> [[hcalendar-examples-in-wild]] http://microformats.org/wiki?title=hcalendar-examples-in-wild&diff=0&oldid=27415 * Sadtuna * (+9) konferenciakalauz.hu suboptimal date end tag fixed
67. [08:28:01] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-20997087c4b3449e) has joined #microformats
68. [08:28:01] <jibot> NatBat is Natalie Downe and can be found online at http://notes.natbat.net
69. [08:33:02] * Phae (n=phaeness@gateb.thls.bbc.co.uk) has joined #microformats
70. [08:33:02] <jibot> Phae is Frances Berriman of http://www.fberriman.com/
71. [08:33:23] * ChanServ sets mode +o Phae
72. [08:35:49] <mfbot> [[events/2008-06-24-weekly-meetup-dinner]] M http://microformats.org/wiki?title=events/2008-06-24-weekly-meetup-dinner&diff=0&oldid=27416 * Tantek * (+0) fix postal-code
73. [08:38:55] <mfbot> [[events]] M http://microformats.org/wiki?title=events&diff=0&oldid=27417 * 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 microformats.org and based in the UK and better defined at http://ben-ward.co.uk
76. [08:54:07] * ChanServ sets mode +o BenWard
77. [09:02:11] * emrojo (n=emrojo@163.117.139.70) has joined #microformats
78. [09:17:35] * KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) has joined #microformats
79. [09:20:54] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-20997087c4b3449e) Quit ("http://www.mibbit.com ajax IRC Client")
80. [09:35:10] * julianstahnke (n=julianst@hq.last.fm) has joined #microformats
81. [09:35:10] <jibot> julianstahnke is a German front-end dev for Last.fm 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 (n=Rob@lnk215.lns2-adl.adsl.esc.net.au) has joined #microformats
83. [10:42:56] * riffraff (n=rff@deri-wg1-2.nuigalway.ie) has joined #microformats
84. [10:43:18] * myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp) 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; http://cackhanded.net/ is his personal site
88. [10:46:40] * cygri (n=cygri@83.141.79.111) has joined #microformats
89. [11:06:44] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) has joined #microformats
90. [11:11:16] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) has left #microformats
91. [11:40:52] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) has joined #microformats
92. [11:40:52] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) Quit (Remote closed the connection)
93. [11:56:03] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-cddae826fe739f5c) has joined #microformats
94. [11:56:03] <jibot> NatBat is Natalie Downe and can be found online at http://notes.natbat.net
95. [12:01:13] * cygri (n=cygri@83.141.79.111) Quit ()
96. [12:07:35] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) has joined #microformats
97. [12:10:12] * vbgunz (n=vbgunz@72.186.68.186) has joined #microformats
98. [12:11:13] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) has left #microformats
99. [12:11:35] * OsRo (n=osro@195-5-86-65.usul.arrakis.es) Quit ()
100. [12:16:34] * shigeta (n=shigeta@124.32.114.226) Quit ("Leaving...")
101. [12:21:29] * cygri (n=cygri@83.141.79.111) has joined #microformats
102. [12:31:30] <Phae> Did anyone read this yet? http://www.webstandards.org/2008/06/23/haccessibility-redux/
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 (n=pat-in-w@dpc693595205.direcpc.com) has joined #microformats
109. [12:35:28] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) 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: http://www.bbc.co.uk/blogs/bbcinternet/2008/06/removing_microformats.html
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]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27418 * 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]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27419 * 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 http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27420 * 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 http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27421 * 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@194.65.5.235) 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 (i=bogdanla@88-158-221-198.Asconet.ro) has joined #microformats
164. [13:05:16] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) Quit (Client Quit)
165. [13:05:36] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) has joined #microformats
166. [13:06:51] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) has left #microformats
167. [13:08:24] * andr3 (n=andr3@194.65.5.235) 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@213.219.8.210) 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@213.219.8.210) Quit (Client Quit)
173. [13:19:05] * DanWrong (i=fwuser@213.219.8.210) 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@194.65.5.235) has joined #microformats
178. [13:53:20] <mfbot> [[datetime-design-pattern]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27422 * 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 (n=csarven@modemcable130.251-202-24.mc.videotron.ca) has joined #microformats
184. [14:15:11] <jibot> csarven is Sarven Capadisli http://www.csarven.ca
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 microformats.org 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@87.110.102.75) 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]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27423 * 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 Mail.app 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@83.141.79.111) 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 Mail.app 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 (n=pawel@nat-12.ghnet.pl) 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 (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp) Quit ("Leaving...")
289. [14:55:40] * emrojo (n=emrojo@163.117.139.70) Quit ("Leaving.")
290. [14:55:47] <BenWard> This might be of interest to those interested in pursuing a datetime-microformat: http://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html
291. [14:56:58] * BobJonkman (n=BobJonkm@206.208.226.139) has joined #microformats
292. [14:57:11] * trovster (n=trovster@creation1.plus.com) Quit ()
293. [14:57:39] * trovster (n=trovster@creation1.plus.com) 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@194.65.5.235) 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 (n=pat-in-w@dpc693595205.direcpc.com) 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 (n=Rob@lnk215.lns2-adl.adsl.esc.net.au) 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 (n=cygri@wlan-nat.fwgal01.deri.ie) 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 (i=bogdanla@88-158-221-198.Asconet.ro) 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> http://www.w3.org/TR/html401/types.html#type-cdata
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 (n=jmeyer@dhcp-12.danastreet.live555.com) has joined #microformats
380. [15:30:34] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) has left #microformats
381. [15:33:09] * purp_ (n=jmeyer@64.74.221.28) 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> http://microformats.org/wiki/machine-data has the fixed data formats listed
396. [15:35:38] <csarven> Some hCard values
397. [15:35:50] * emrojo (n=emrojo@163.117.139.70) 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@64.74.221.28) Quit ()
406. [15:45:23] <drewinthehead> so..
407. [15:46:57] * purp (n=jmeyer@dhcp-12.danastreet.live555.com) 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 (n=cygri@wlan-nat.fwgal01.deri.ie) 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> http://microformats.org/wiki?title=anti-patterns&diff=24271&oldid=24270
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 (n=jmeyer@dhcp-7.danastreet.live555.com) has joined #microformats
467. [16:24:26] * azazul (n=azazul@zelli-kojas.lanet.lv) 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 (n=jmeyer@dhcp-7.danastreet.live555.com) 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@74.85.6.194) has joined #microformats
476. [16:28:40] <jibot> pjkix is PJ Khalil a Web Developer in SF and can be found online at http://pjkix.com
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; http://cackhanded.net/ 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@189.82.254.13) 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. http://www.w3.org/html/wg/html5/#the-time
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 (n=phaeness@gateb.thls.bbc.co.uk) 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 http://www.w3.org/TR/2008/WD-html5-20080610/text-level.html#the-time
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@64.74.221.28) 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 http://microformats.org/wiki?title=principles&diff=0&oldid=27424 * 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 (n=pat-in-w@dpc693595205.direcpc.com) has joined #microformats
646. [17:09:22] <tantek> Nor should any one content publisher be.
647. [17:09:26] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) 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@213.219.8.210) 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 (n=jgraham@xpc9.ast.cam.ac.uk) 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 (n=drewinth@eoms2.gotadsl.co.uk) 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 (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) 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 http://www.w3.org/TR/2008/WD-html5-20080610/semantics.html#date-or1
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@207.111.252.10) 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@189.82.254.13) Quit (Client Quit)
786. [17:48:54] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-cddae826fe739f5c) Quit ("http://www.mibbit.com ajax IRC Client")
787. [17:50:31] * bergie_ (n=bergie@cs181192153.pp.htv.fi) has joined #microformats
788. [17:51:39] * bergie (n=bergie@cs181192153.pp.htv.fi) Quit (Read error: 104 (Connection reset by peer))
789. [17:52:11] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) has joined #microformats
790. [17:52:19] * pat-in-wv (n=pat-in-w@dpc693595205.direcpc.com) has left #microformats
791. [18:01:33] * trovster (n=trovster@creation1.plus.com) Quit ()
792. [18:06:04] <mfbot> [[events/2008-06-24-weekly-meetup-dinner]] M http://microformats.org/wiki?title=events/2008-06-24-weekly-meetup-dinner&diff=0&oldid=27425 * Steve Ganz * (+27) attendees -
793. [18:07:22] * Hey_neken (n=kaxero@215.Red-213-96-129.staticIP.rima-tde.net) 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]] http://microformats.org/wiki?title=machine-data&diff=0&oldid=27426 * 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 (n=user@82-44-60-36.cable.ubr01.mort.blueyonder.co.uk) has joined #microformats
802. [18:10:46] <jibot> Phae is Frances Berriman of http://www.fberriman.com/
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 (n=julianst@last.fm/staff/wurstkind) 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 (n=philip@c-69-181-144-83.hsd1.ca.comcast.net) has joined #microformats
820. [18:13:06] <jibot> bluesmoon is Philip <http://bluesmoon.info> & 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 http://grant.henninger.name
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@189.82.254.13) 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]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27427 * 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]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27428 * 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 (n=philip@c-69-181-144-83.hsd1.ca.comcast.net) Quit ("Ex-Chat")
862. [18:52:37] * danbri (n=danbri@unaffiliated/danbri) Quit ()
863. [18:59:40] <mfbot> [[datetime-design-pattern]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27429 * JakeArchibald * (+195) Machine-data in class -
864. [19:00:56] <mfbot> [[datetime-design-pattern]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27430 * Tantek * (+370) date and time separation using value excerption - - subheads, started derivation section
865. [19:02:06] * remi_ (n=remi@modemcable015.86-201-24.mc.videotron.ca) has joined #microformats
866. [19:05:17] * emrojo (n=emrojo@163.117.139.70) has left #microformats
867. [19:06:13] <mfbot> [[datetime-design-pattern]] M http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27431 * 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@83.141.79.111) has joined #microformats
869. [19:16:50] * drewinthehead (n=drewinth@chauchcr.gotadsl.co.uk) has joined #microformats
870. [19:16:50] <jibot> drewinthehead is the author of hKit and a developer at http://edgeofmyseat.com
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 (n=drewinth@chauchcr.gotadsl.co.uk) Quit (Remote closed the connection)
876. [19:30:46] * drewinthehead (n=drewinth@chauchcr.gotadsl.co.uk) has joined #microformats
877. [19:30:46] * ChanServ sets mode +o drewinthehead
878. [19:34:19] * MrTopf (i=hidden-u@oecher.info) Quit ()
879. [19:35:28] * MrTopf (i=hidden-u@oecher.info) has joined #microformats
880. [19:39:49] * riffraff (n=rff@deri-wg1-2.nuigalway.ie) Quit (Remote closed the connection)
881. [19:40:17] * MrTopf (i=hidden-u@oecher.info) Quit (Read error: 104 (Connection reset by peer))
882. [19:40:26] * MrTopf (i=hidden-u@oecher.info) 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 (n=jgraham@xpc9.ast.cam.ac.uk) 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 (i=hidden-u@oecher.info) Quit (Read error: 110 (Connection timed out))
902. [20:03:56] <mfbot> [[datetime-design-pattern]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27432 * 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 http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27433 * 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 http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27434 * Tantek * (-6) advantages -
906. [20:10:05] <mfbot> [[abbr-date-pattern]] MN http://microformats.org/wiki/abbr-date-pattern * Tantek * (+33)
907. [20:10:51] <mfbot> [[abbr-datetime-pattern]] MN http://microformats.org/wiki/abbr-datetime-pattern * 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: http://microformats.org/wiki/datetime-design-pattern#date_and_time_separation_using_value_excerption
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]] http://microformats.org/wiki?title=recipe-brainstorming&diff=0&oldid=27435 * Yde * (+384) Issues -
914. [20:33:55] * dotjay (n=dotjay@84.92.229.1) has joined #microformats
915. [20:36:39] <mfbot> [[presentations]] http://microformats.org/wiki?title=presentations&diff=0&oldid=27436 * GeraldBauer * (+25) removed old preso and added link to new one from april talk
916. [20:41:10] <mfbot> [[recipe-brainstorming]] http://microformats.org/wiki?title=recipe-brainstorming&diff=0&oldid=27437 * Yde * (+139) Discussion - added discussion about alternative ingredients
917. [20:41:16] <mfbot> [[events]] http://microformats.org/wiki?title=events&diff=0&oldid=27438 * GeraldBauer * (+170) added note about Vancouver Semantic(Web)Camp 2008
918. [20:41:58] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-1caee7a34c63065c) has joined #microformats
919. [20:41:59] <jibot> NatBat is Natalie Downe and can be found online at http://notes.natbat.net
920. [20:44:08] * dotjay (n=dotjay@84.92.229.1) 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 http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27439 * TobyInk * (+873) Machine-data in class -
925. [20:53:09] <mfbot> [[datetime-design-pattern]] M http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27440 * TobyInk * (+3) Machine-data in class -
926. [20:57:16] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-1caee7a34c63065c) Quit ("http://www.mibbit.com 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_ (n=bergie@cs181192153.pp.htv.fi) 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 http://allinthehead.com/presentations/2008/
942. [21:24:31] <Phae> :D
943. [21:26:51] <mfbot> [[datetime-design-pattern]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27441 * TobyInk * (+929) advantages - dark data sometimes desired
944. [21:32:48] <mfbot> [[datetime-design-pattern]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27442 * 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 http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27443 * Tantek * (+71) date and time separation using value excerption - move discussion to discussion section
946. [21:34:40] <mfbot> [[datetime-design-pattern]] M http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27444 * 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 (n=tai@ophelia.g5n.co.uk) 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/mibbit.com/x-598d1a53c3512c8c) has joined #microformats
956. [21:50:11] <jibot> NatBat is Natalie Downe and can be found online at http://notes.natbat.net
957. [21:51:35] * DavidMead (n=DaveMead@cpe-76-189-106-159.neo.res.rr.com) 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@189.82.254.13) Quit (Client Quit)
963. [21:59:48] * DavidMead (n=DaveMead@cpe-76-189-106-159.neo.res.rr.com) has left #microformats
964. [22:00:14] * purp_ (n=jmeyer@64.74.221.28) 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@64.74.221.28) has joined #microformats
967. [22:03:46] * purp (n=jmeyer@64.74.221.28) Quit (Read error: 104 (Connection reset by peer))
968. [22:07:25] * NatBat (i=568eef7c@gateway/web/ajax/mibbit.com/x-598d1a53c3512c8c) Quit ("http://www.mibbit.com 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 http://microformats.org/wiki/include-pattern-feedback#Removal_of_.3Cobject.3E_as_an_instance_of_the_include-pattern
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@64.74.221.28) Quit (Read error: 110 (Connection timed out))
974. [22:20:25] * vbgunz (n=vbgunz@72.186.68.186) 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@206.208.226.139) Quit (Read error: 104 (Connection reset by peer))
977. [22:26:21] * bogdanlazarsb (i=bogdanla@88-158-221-198.Asconet.ro) has left #microformats
978. [22:28:57] * danbri (n=danbri@unaffiliated/danbri) Quit ()
979. [22:29:03] * SunWuKung (n=SunWuKun@S01060016cbc4c705.vc.shawcable.net) Quit ()
980. [22:32:44] * KevinMarks (n=KevinMar@150.sub-75-209-204.myvzw.com) has joined #microformats
981. [22:35:30] * dw (n=dw@gw.dmw.me.uk) has joined #microformats
982. [22:39:07] * jonnys1234 (n=johnsout@cpc1-acto6-0-0-cust434.brnt.cable.ntl.com) Quit ()
983. [22:40:10] * vbgunz (n=vbgunz@72.186.68.186) has joined #microformats
984. [22:41:04] * BenWard (n=BenWard@93-96-142-212.zone4.bethere.co.uk) 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 microformats.org and based in the UK and better defined at http://ben-ward.co.uk
987. [22:43:52] * DanWrong (n=DanWrong@87.112.64.75.plusnet.ptn-ag2.dyn.plus.net) has joined #microformats
988. [22:55:18] * remi_ (n=remi@modemcable015.86-201-24.mc.videotron.ca) 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@64.74.221.28) Quit ()
993. [22:57:20] <csarven> Check this out: the http://microformats.org/wiki/include-pattern-feedback#Removal_of_.3Cobject.3E_as_an_instance_of_the_include-pattern
994. [22:57:51] * remi_ (n=remi@modemcable015.86-201-24.mc.videotron.ca) 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: http://microformats.org/wiki/include-pattern-feedback#Objects_and_Browser_Behavior (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 (n=pawel@nat-12.ghnet.pl) 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: http://yuiblog.com/blog/2008/01/23/empty-links/
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@64.74.221.28) 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 http://www.w3.org/TR/html401/index/attributes.html 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 (n=user@82-44-60-36.cable.ubr01.mort.blueyonder.co.uk) Quit ("Leaving.")
1090. [23:31:28] <mfbot> [[Main Page]] http://microformats.org/wiki?title=Main_Page&diff=0&oldid=27445 * Wikiword * (+27)
1091. [23:31:54] <mfbot> [[Main Page]] M http://microformats.org/wiki?title=Main_Page&diff=0&oldid=27446 * Tantek * (-27) Reverted edit of Wikiword, changed back to last version by JacobMalthouse
1092. [23:32:16] <mfbot> [[Special:Log/block]] http://microformats.org/wiki?title=Special:Log/block&diff=0&oldid=0 * 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@83.141.79.111) 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 microformats.org 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 http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27447 * TobyInk * (+375) discussion -
1110. [23:39:34] * bennewarde (n=BenWard@dip5-fw.corp.ukl.yahoo.com) has joined #microformats
1111. [23:40:05] * KevinMarks (n=KevinMar@150.sub-75-209-204.myvzw.com) 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]] http://microformats.org/wiki?title=datetime-design-pattern&diff=0&oldid=27448 * 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> http://microformats.org/wiki/microformats
1138. [23:54:58] <tantek> specifically: http://microformats.org/wiki/microformats#microformats_are_not
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 (n=BenWard@93-96-142-212.zone4.bethere.co.uk) Quit (Read error: 110 (Connection timed out))
1142. [23:56:10] * bennewarde is now known as BenWard
1143. [23:56:10] * charlenopires (n=charleno@189.82.254.13) 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 chat.freenode.net using a modified version of the Java IRC LogBot.

See http://microformats.org/wiki/mflogbot for more information.