/irc-logs / w3c / #html-wg / 2007-05-14 / end

Options:

  1. # Session Start: Mon May 14 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:09] * zcorpan_ tests in ie
  4. # [00:10] <zcorpan_> http://simon.html5.org/test/html/parsing/residual.html
  5. # [00:10] <zcorpan_> TABLE is red in ie7
  6. # [00:10] <zcorpan_> COL and COLGROUP too
  7. # [00:11] <zcorpan_> after TABLE, everything is green (also things that probably should be black)
  8. # [00:16] <hyatt> wow so winie reopens even more than ffx does
  9. # [00:17] <zcorpan_> at the TABLE, it nests the rest of the document inside that FONT
  10. # [00:18] <hyatt> oh i may have missed a close
  11. # [00:18] <hyatt> or it could have to do with how it recovered
  12. # [00:18] <hyatt> if you see red, it means WinIE reopened
  13. # [00:18] <zcorpan_> TABLE: <font><table><font class="fail"></table>All of this should be green.</font>
  14. # [00:18] <hyatt> oh i should just throw in an extra </font> in those examples
  15. # [00:19] <hyatt> </font></font>
  16. # [00:19] <hyatt> since it will be harmless in the other browsers
  17. # [00:20] <zcorpan_> in opera everything is green after the OBJECT
  18. # [00:21] <hyatt> hey if you cleaned that test up and noted what each browser does that would rule
  19. # [00:22] <hyatt> the test right now basically shows what ffx and safari d
  20. # [00:22] <hyatt> o
  21. # [00:22] <zcorpan_> sure
  22. # [00:24] <zcorpan_> test cleaned up, also uploaded to live dom viewer
  23. # [00:25] <zcorpan_> ok, ie7 again...
  24. # [00:26] <zcorpan_> these are black: APPLET BUTTON MARQUEE. these are red: COL COLGROUP TABLE
  25. # [00:27] <hyatt> fascinating
  26. # [00:27] <hyatt> wow i should add applet button marquee
  27. # [00:27] <hyatt> i should probably just add embed too
  28. # [00:28] <hyatt> i'm scared to reopen col/colgroup/table
  29. # [00:28] <hyatt> even if winie doe
  30. # [00:29] * Quits: zcorpan_ (zcorpan@84.216.40.20) (Ping timeout)
  31. # [00:31] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  32. # [00:33] * Joins: zcorpan_ (zcorpan@130.243.79.10)
  33. # [00:34] <zcorpan_> ie6 is same as ie7
  34. # [00:34] <zcorpan_> all are green in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070503 Minefield/3.0a5pre
  35. # [00:36] <zcorpan_> opera 9.20 build 8771: these don't include the test text at all: APPLET FIELDSET LEGEND. these are black: BUTTON CANVAS. these are red: OBJECT PARAM
  36. # [00:36] * Joins: gavin_ (gavin@74.103.208.221)
  37. # [00:39] * zcorpan_ also learns that the dom viewer in ie's developer toolbar is lying
  38. # [00:42] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
  39. # [00:44] * Joins: zcorpan (zcorpan@84.216.42.41)
  40. # [00:44] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
  41. # [01:00] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  42. # [01:21] * zcorpan notes that safari matches ie7 with http://simon.html5.org/test/css/magic-body/background-image/009.htm
  43. # [01:23] <Philip`> zcorpan: In what way is it lying?
  44. # [01:24] <Philip`> (About non-tree DOM, I guess?)
  45. # [01:24] <zcorpan> Philip`: for the residual style test, it claims that everything is nested inside each FONT as a very deep tree
  46. # [01:25] <Philip`> Ah
  47. # [02:01] * Joins: hyatt (hyatt@24.6.91.161)
  48. # [02:05] * zcorpan finds that his testing results were incorrect. opera and mozilla both fail http://simon.html5.org/test/css/magic-body/overflow/004.htm and moz also fails 004.xht
  49. # [02:31] * Quits: kingryan (rking3@64.81.240.149) (Quit: kingryan)
  50. # [02:38] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  51. # [02:39] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  52. # [02:43] * Joins: gavin_ (gavin@74.103.208.221)
  53. # [02:53] * Parts: zcorpan (zcorpan@84.216.42.41)
  54. # [03:44] * Joins: inimino (inimino@75.71.88.233)
  55. # [03:52] * Quits: tH (r@83.100.174.14) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
  56. # [04:40] * Joins: Zeros (Zeros-Elip@69.140.48.129)
  57. # [04:47] * Quits: myakura (myakura@125.194.247.196) (Ping timeout)
  58. # [04:58] * Joins: myakura (myakura@125.194.247.196)
  59. # [05:00] * Joins: marcos (chatzilla@131.181.148.226)
  60. # [05:37] * Joins: Sander (svl@71.57.109.108)
  61. # [05:51] * Joins: hyatt (hyatt@24.6.91.161)
  62. # [06:25] * Quits: jdandrea_ (jdandrea@68.192.165.143) (Quit: jdandrea_)
  63. # [06:40] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  64. # [06:45] * Joins: gavin_ (gavin@74.103.208.221)
  65. # [06:46] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
  66. # [07:22] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  67. # [08:09] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  68. # [08:31] * Joins: ROBOd (robod@86.34.246.154)
  69. # [08:35] * Quits: frippz (fredrikfro@193.11.209.47) (Quit: frippz)
  70. # [08:44] * Quits: heycam (cam@210.84.3.81) (Ping timeout)
  71. # [08:47] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  72. # [08:50] * Joins: zdenko (zdenko@193.77.152.244)
  73. # [08:52] * Joins: gavin_ (gavin@74.103.208.221)
  74. # [08:59] * Joins: loic (loic@86.71.4.162)
  75. # [09:01] * Joins: heycam (cam@203.214.77.236)
  76. # [09:24] * anne notes that <embed> is not like <applet> so treating it the same is likely leading to more bugs
  77. # [09:24] <anne> (<embed> is a void tag)
  78. # [09:25] * Quits: loic (loic@86.71.4.162) (Connection reset by peer)
  79. # [09:25] <hsivonen> anne: what are you referring to? what's treating it like applet?
  80. # [09:27] * Joins: loic (loic@86.71.4.162)
  81. # [09:29] <anne> <hyatt> wow i should add applet button marquee
  82. # [09:29] <anne> <hyatt> i should probably just add embed too
  83. # [09:53] * Disconnected
  84. # [09:53] * Attempting to rejoin channel #html-wg
  85. # [09:53] * Rejoined channel #html-wg
  86. # [09:53] * Topic is 'HTML WG http://www.w3.org/html/wg/ logged: http://krijnhoetmer.nl/irc-logs/'
  87. # [09:53] * Set by Zeros on Mon Apr 30 23:38:28
  88. # [09:53] * Joins: citoyen (eira@195.139.204.228)
  89. # [09:53] * Joins: Zeros (Zeros-Elip@69.140.48.129)
  90. # [09:53] * Quits: jmb (jmb@81.86.70.47) (Ping timeout)
  91. # [09:53] * Quits: deltab (deltab@82.46.154.93) (Ping timeout)
  92. # [09:53] * Quits: schepers (schepers@69.134.24.226) (Ping timeout)
  93. # [09:53] * Joins: jmb (jmb@81.86.70.47)
  94. # [09:53] * Joins: jgraham (jgraham@85.210.7.238)
  95. # [09:53] * Quits: heycam (cam@203.214.77.236) (Ping timeout)
  96. # [09:53] * Joins: loic (loic@86.71.4.162)
  97. # [09:53] * Quits: ROBOd (robod@86.34.246.154) (Ping timeout)
  98. # [09:53] * Joins: martijn (martijn@83.137.193.141)
  99. # [09:53] * Joins: hsivonen (hsivonen@130.233.41.50)
  100. # [09:53] * Joins: heycam (cam@203.214.77.236)
  101. # [09:53] * Joins: ROBOd (robod@86.34.246.154)
  102. # [09:54] * Joins: schepers (schepers@69.134.24.226)
  103. # [09:54] * Joins: inimino (inimino@75.71.88.233)
  104. # [09:54] * Joins: nickshanks (nicholas@195.137.85.17)
  105. # [09:57] * Joins: gavin_ (gavin@74.103.208.221)
  106. # [09:57] * Joins: Dashiva (noone@129.241.151.35)
  107. # [09:57] * Joins: sbuluf (bu@200.49.140.57)
  108. # [10:00] * Joins: hyatt (hyatt@24.6.91.161)
  109. # [10:38] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  110. # [10:50] * Joins: glazou (daniel@80.118.184.70)
  111. # [10:50] <glazou> hello
  112. # [10:50] <glazou> when is the BOF at Xtech ?
  113. # [10:50] * Joins: gsnedders (gsnedders@86.139.123.225)
  114. # [10:53] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
  115. # [10:55] <MikeSmith> glazou - there was mention of Thursday night
  116. # [11:00] <glazou> hmmm
  117. # [11:00] <MikeSmith> possibly Friday
  118. # [11:00] <glazou> apparently xtech BOFs are all scheduled on tuesday night
  119. # [11:00] <glazou> friday ?
  120. # [11:01] <glazou> xtech ends friday noon !
  121. # [11:01] <glazou> see http://2007.xtech.org/public/content/2007/05/08-bofs-free
  122. # [11:01] <MikeSmith> Friday was mentioned ... but I think many people are leaving early on Friday
  123. # [11:01] <glazou> right
  124. # [11:01] <MikeSmith> glazou - yeah, saw that
  125. # [11:01] <MikeSmith> I'm hosting a BoF myself on Tuesday ... on location-aware browsing
  126. # [11:02] <glazou> yep saw that
  127. # [11:02] <MikeSmith> and Molly is having an all-day "browser summit" thing on Tuesday
  128. # [11:02] <MikeSmith> maybe during that?
  129. # [11:03] <MikeSmith> in the daytime
  130. # [11:05] <glazou> hmmm
  131. # [11:05] <glazou> you have a url for molly's thing ?
  132. # [11:05] <MikeSmith> http://2007.xtech.org:80/public/news
  133. # [11:06] <MikeSmith> http://www.molly.com/2007/05/10/blue-sky-web-browser-standards-and-interop-summit-xtech-paris/
  134. # [11:06] <MikeSmith> http://2007.xtech.org:80/public/content/2007/05/10-browser-summit
  135. # [11:07] <glazou> thanks
  136. # [11:10] <MikeSmith> glazou - ask annevk when he's on ... he might know more
  137. # [11:10] <glazou> sure
  138. # [11:10] <glazou> I was expecting to see him here actually
  139. # [11:11] <MikeSmith> I guess he is probably traveling today
  140. # [11:12] <glazou> k
  141. # [11:41] * Quits: sbuluf (bu@200.49.140.57) (Quit: sbuluf)
  142. # [11:49] * glazou is now known as glazou_afk
  143. # [11:59] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  144. # [12:03] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  145. # [12:04] * Joins: gavin_ (gavin@74.103.208.221)
  146. # [12:32] * Joins: zcorpan (zcorpan@130.243.79.10)
  147. # [13:13] * Quits: zcorpan (zcorpan@130.243.79.10) (Ping timeout)
  148. # [13:17] * Joins: zcorpan (zcorpan@130.243.79.10)
  149. # [13:20] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  150. # [13:22] * Joins: beowulf (carisenda@91.84.50.132)
  151. # [13:23] * Joins: tH (r@83.100.174.14)
  152. # [13:23] * Joins: zcorpan_ (zcorpan@84.216.42.41)
  153. # [13:24] * Quits: zcorpan (zcorpan@130.243.79.10) (Ping timeout)
  154. # [13:39] * Joins: dk (dougkearns@203.164.14.59)
  155. # [13:43] * glazou_afk is now known as glazou
  156. # [14:10] * Joins: jdandrea (jdandrea@68.192.165.143)
  157. # [14:15] * Quits: zcorpan_ (zcorpan@84.216.42.41) (Ping timeout)
  158. # [14:17] * Joins: zcorpan_ (zcorpan@84.216.42.41)
  159. # [14:25] * Joins: anne (annevk@213.236.208.22)
  160. # [14:26] <anne> for some reason I was disconnected
  161. # [14:26] * anne will be travelling tomorrow morning
  162. # [14:29] <anne> www-html is amusing
  163. # [14:31] <anne> glazou, tomorrow is the day for discussion I think
  164. # [14:32] <anne> glazou, and maybe during the rest of the conference too
  165. # [14:32] * Joins: Shunsuke (kuruma@219.110.80.235)
  166. # [14:32] <anne> glazou, at this point it doesn't look like we'll have some specific meeting
  167. # [14:32] <anne> glazou, apart from browser & standards & interop day tomorrow
  168. # [14:58] * Joins: ROBOd (robod@86.34.246.154)
  169. # [15:06] <MikeSmith> anne - just glad the amusement is on www-html instead of public-html ... hopefully public-html will get a lot less amusing
  170. # [15:09] <Philip`> Maybe it'd be alright if www-html were like public-html was a week ago (except with fewer people), and if public-html were like whatwg is now
  171. # [15:16] <anne> public-html@w3.org like whatwg@whatwg.org would be most excellent
  172. # [15:19] <MikeSmith> anne - yeah, let's work on getting it there
  173. # [15:19] <MikeSmith> Philip` - yeah that too
  174. # [15:27] * Quits: Shunsuke (kuruma@219.110.80.235) (Quit: See you...)
  175. # [15:28] <Philip`> No idea how long it'll take to get there - whatwg is at the stage of refining and fixing the features that have been added, but public-html will probably have to go through a stage of questioning all the basic decisions about every single feature
  176. # [15:28] <anne> depending on how much effort "the new guys" put into it
  177. # [15:29] <MikeSmith> Philip` - as long as it is a specific technical discussion of the spec itself, that would be big progress
  178. # [15:29] <MikeSmith> (for the public-html list)
  179. # [15:29] <anne> heh
  180. # [15:29] <anne> i think some did discuss the spec though
  181. # [15:31] <MikeSmith> anne - yeah, some. problem is the not-some other stuff ...
  182. # [15:37] * Joins: jdandrea_ (jdandrea@68.192.161.254)
  183. # [15:39] * Quits: jdandrea (jdandrea@68.192.165.143) (Ping timeout)
  184. # [16:08] * Joins: frippz (frippz@193.15.86.38)
  185. # [16:28] * Quits: myakura (myakura@125.194.247.196) (Ping timeout)
  186. # [16:34] * Quits: zcorpan_ (zcorpan@84.216.42.41) (Ping timeout)
  187. # [16:40] * Joins: Shunsuke (kuruma@219.110.80.235)
  188. # [16:44] * Joins: billmason (billmason@69.30.57.156)
  189. # [16:44] * Parts: billmason (billmason@69.30.57.156)
  190. # [16:46] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  191. # [16:50] * Joins: jdandrea (jdandrea@68.192.165.143)
  192. # [16:51] * Joins: gavin_ (gavin@74.103.208.221)
  193. # [16:52] * Quits: jdandrea_ (jdandrea@68.192.161.254) (Ping timeout)
  194. # [16:52] * Joins: hasather (hasather@81.235.209.174)
  195. # [17:04] * Quits: frippz (frippz@193.15.86.38) (Quit: frippz)
  196. # [17:06] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
  197. # [17:13] * Joins: DanC_lap (connolly@128.30.52.30)
  198. # [17:27] <glazou> anne: ok
  199. # [17:28] * Joins: frippz (fredrikfro@193.11.209.47)
  200. # [17:28] * Joins: myakura (myakura@125.194.247.196)
  201. # [17:32] * Joins: h3h (bfults@66.162.32.234)
  202. # [17:32] * Quits: zdenko (zdenko@193.77.152.244) (Quit: zdenko)
  203. # [17:47] * Quits: dk (dougkearns@203.164.14.59) (Ping timeout)
  204. # [17:58] * Quits: glazou (daniel@80.118.184.70) (Quit: glazou)
  205. # [18:00] * Joins: Sander (svl@71.57.109.108)
  206. # [18:05] * Joins: zcorpan_ (zcorpan@84.216.41.242)
  207. # [18:08] * Joins: dbaron (dbaron@71.198.189.81)
  208. # [18:10] * Quits: myakura (myakura@125.194.247.196) (Quit: Leaving...)
  209. # [18:19] * Joins: myakura (myakura@125.194.247.196)
  210. # [18:22] * Quits: inimino (inimino@75.71.88.233) (Ping timeout)
  211. # [18:52] * Quits: hasather (hasather@81.235.209.174) (Ping timeout)
  212. # [18:53] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  213. # [18:58] * Joins: gavin_ (gavin@74.103.208.221)
  214. # [19:14] <DanC_lap> hmm.. more design principles discussion, not particularly productive
  215. # [19:15] <DanC_lap> I suppose repeating my request to stop that isn't as useful as starting some other discusison
  216. # [19:17] * Joins: othermaciej (mjs@17.255.105.176)
  217. # [19:21] <Lachy> DanC_lap, the problem is, particluarly with pave the cowpaths, people don't really understand the scope of it, and so they're jumping to conclusions that it could be used to support a wide range of bad things
  218. # [19:22] <hsivonen> DanC_lap: sorry about sending email during the recess. I was too routinized to hit reply to all plus send. I was rather ashamed when I realized I had responded to the list that was in recess.
  219. # [19:23] <Lachy> but at least John Foliot's latest mail didn't really focus on the principle, but rather somewhat productively addressed my questions.
  220. # [19:29] <DanC_lap> not a big deal, hsivonen
  221. # [19:30] <hsivonen> DanC_lap: thanks
  222. # [19:38] * Joins: deltab (deltab@82.46.154.93)
  223. # [19:39] <othermaciej> Lachy: I'm glad he responded to your points, regrettably, a lot of his reply is in vague generalities
  224. # [19:39] <othermaciej> I'm particularly concerned about his remark that he can't prove more semantic features are needed, but he *knows* it's true
  225. # [19:40] <tH> truthiness?
  226. # [19:40] <Lachy> yeah, I'm also concerned by him pushing the burden of proof on to others to disprove him, rather than having him prove his own claims
  227. # [19:41] <DanC_lap> let's not spend time arguing who has the burden of proof.
  228. # [19:41] <DanC_lap> let's just put the design principles on the back burner
  229. # [19:42] <Lachy> ok, fair enough
  230. # [19:42] <othermaciej> design principles or no, we'll have to make decisions about specific technical issues
  231. # [19:42] <othermaciej> so avoiding debate on the design principles will not actually let us avoid disagreement
  232. # [19:43] <Lachy> I'm having a hard time taking this suggestion seriously, but trying to respond calmly and objectively http://lists.w3.org/Archives/Public/www-html/2007May/0462.html
  233. # [19:43] <othermaciej> I am disappointed that the outcome of the two positive reviews of the design principles document by the designated reviewers is to ignore it for the time being
  234. # [19:43] <DanC_lap> Ryan King suggested we start with the parsing/tree generation part of the spec, rather than just breadth-first. I find the idea appealing. What do you think, hixie?
  235. # [19:43] <Philip`> Maybe it needs time for people to see decisions made about specific technical issues, and then the points made in those decisions can be generalised into design principles and people will be happier since they've seen that they work
  236. # [19:44] <DanC_lap> that's sorta what I'm hoping, Philip`...
  237. # [19:44] <othermaciej> I do think we should have a review agenda, but I don't think parsing is the most interesting place to start
  238. # [19:44] <othermaciej> mainly because it is all about very obscure technical details and most people do not have the technical expertise to meaningfully review it
  239. # [19:45] <Philip`> Parsing is a good way to scare off people who don't like going into the messy details of how browsers work and how they ignore the previous standards and disagree with other browsers
  240. # [19:45] <DanC_lap> maciej, I can see how that's disappointing... the two positive reviews were mixed with a lot of mixed reviews, and I haven't managed to review the discussion carefully.
  241. # [19:45] <othermaciej> I would suggest starting with a topic that is conceptually simpler and where there might be actual design work, not just reverse engineering
  242. # [19:46] <DanC_lap> hmm... why?
  243. # [19:46] * DanC_lap is in no hurry to do any design work
  244. # [19:46] <othermaciej> because, as I said, I think the vast majority of people can't usefully contribute to a review or discussion of the parsing algorithm
  245. # [19:47] <othermaciej> I suppose in a certain light that could be seen as an advantage
  246. # [19:47] <othermaciej> but people may try to contribute anyway based on uninformed opinion, in an area where opinion is not really applicable
  247. # [19:47] <h3h> yeah, I would recommend *not* starting with Parsing
  248. # [19:48] <h3h> the Parsing section is what has caused 90% of the confusion thus far on the list
  249. # [19:48] <h3h> and is very technical (and non-debatable to a point, really) in nature
  250. # [19:48] <DanC_lap> my attempts to get this group to *not* do X have had very little success. I need a suggestion of what to do instead.
  251. # [19:48] <othermaciej> I would suggest starting with the definition of some set of non-controversial elements that existed in HTML 4, or with <canvas>
  252. # [19:48] <h3h> I'd say start with forms
  253. # [19:48] <h3h> they're the most established
  254. # [19:49] <Lachy> if we start with reviwing elements and semantics, we have to be careful to avoid bikeshedding
  255. # [19:49] <othermaciej> I actually think <canvas> might be a good place to start
  256. # [19:49] * DanC_lap has to look up "bikeshedding"
  257. # [19:49] <h3h> <canvas> works for me
  258. # [19:49] <h3h> and I seriously doubt a linear traversal of the spec will be realistic
  259. # [19:50] <othermaciej> it's new since HTML 4, relatively self-contained, and not insanely hard to understand
  260. # [19:50] <othermaciej> we need someone to run an agenda
  261. # [19:50] <Lachy> yeah, until some argues that HTML isn't a graphics API, and cavnas shouldn't be included
  262. # [19:50] <h3h> I'd much rather have many active threads about different parts of the spec, so people can apply their expertise in the right places
  263. # [19:50] <h3h> instead of replying to discussions that they don't understand simply because they are the only discussions happening
  264. # [19:50] <Philip`> Would it be sensible to wait a week or so until Hixie's finished integrating the current canvas feedback into the spec, before having new people start reviewing it?
  265. # [19:50] <othermaciej> h3h: many active threads is hard on editors, hard on chairs, hard on people responsible for issue tracking, and hard on people who might want to pay attention selectively to the list
  266. # [19:51] <Lachy> havnig too many threads becomes difficult to follow, particlaly for those of use who have knowledge about all of it
  267. # [19:51] <h3h> yeah...
  268. # [19:51] <DanC_lap> "and I seriously doubt a linear traversal of the spec will be realistic" <- what does that mean? surely it's feasible to go over the spec breadth-first and collect issues, no?
  269. # [19:51] <othermaciej> DanC_lap: I think before raising a specific review topic, we might want to set up a basic issue tracker and designate some people to be responsible for recording issues
  270. # [19:51] <DanC_lap> othermaciej, of course
  271. # [19:51] <h3h> DanC_lap: it means only having discussions about one topic at a time in the spec
  272. # [19:52] <DanC_lap> the breadth-first tactic doesn't involve (much) discussion. Just raising issues.
  273. # [19:52] <h3h> that sounds great, but I think is terribly idealistic for a group of this size and varying expertise
  274. # [19:53] <h3h> everyone is going to try to throw in their 2 cents at every step of the way
  275. # [19:53] <Philip`> (DanC_lap: http://lightyellow.bikeshed.org/ though you probably found it already)
  276. # [19:54] * Lachy awaits the flood of replies to othermaciej's last post to the list, particlarly about the predefined class names point
  277. # [19:55] <othermaciej> Lachy: I should have specified that I don't necessarily think all those changes are good
  278. # [19:55] <h3h> I think this is where the group size is going to hurt the most
  279. # [19:55] <DanC_lap> I have a big blind-spot around forms. back in 199x, I proposed finishing the HTML 1.x spec without forms. didn't fly. If we're to start with forms, I'll need Chris W. to do most of the chairing.
  280. # [19:56] <othermaciej> DanC_lap: raising issues ad-hoc about all sorts of areas of the spec means it is unlikely they'll be promptly addressed, compared to focusing on a particular area
  281. # [19:56] * Joins: kingryan (rking3@208.66.64.47)
  282. # [19:56] <Lachy> Philip`, you should have painted it blue! ;-)
  283. # [19:56] <othermaciej> it's hard to think of a section that would not have some sort of controversy around it
  284. # [19:57] <DanC_lap> othermaciej, I'm not sure I see your point. It's tautological that a breadth-first approach is different from a depth-first approach.
  285. # [19:57] <othermaciej> DanC_lap: I think I mentioned a specific likely difference, rather than just asserting it will be different
  286. # [19:57] <Hixie> DanC_lap: i think that a review of the parsing section can only be usefully done by comparing large numbers of pages as parsed by an html5 browser and as parsed by IE. It's not clear to me it's a section that can be reviewed without implementation experience. At least the 8.2 section. 8.1 (Writing HTML documents) would make sense to review.
  287. # [19:58] <Lachy> I suspect these elements would have very little controversy http://www.whatwg.org/specs/web-apps/current-work/#sections (<section>, headings, etc.)
  288. # [19:58] <othermaciej> yeah, I was going to suggest 3.8 Sections
  289. # [19:58] <kingryan> DanC_lap: I see that what we talked about the other day has already come up to the group at large :D
  290. # [19:58] <Lachy> 3.11 Lists, as well
  291. # [19:59] <Lachy> and 3.15 tabular data
  292. # [19:59] <Hixie> i would recommend against <canvas> this week for the reason Philip` gave, actually
  293. # [19:59] * h3h thinks a wiki page with an ordered agenda would be useful at this point
  294. # [19:59] <othermaciej> also 3.9 Prose, 3.11 Lists, or 3.14 Embedded Content (skipping <canvas> and media elements as deserving their own review agenda topic)
  295. # [19:59] <Hixie> (i'm still integrating past feedback)
  296. # [19:59] <h3h> sorry, *proposed* ordered agenda
  297. # [20:00] * DanC_lap gives it a whirl in http://esw.w3.org/topic/HtmlTaskBrainstorm
  298. # [20:00] <Lachy> DanC_lap, are we going to try and allocate a time limit for the review of each section, so that threads don't drag on forever?
  299. # [20:00] <othermaciej> 4.11 Client-side session and persistent storage might be a good one too, or 4.3 Session history and navigation
  300. # [20:00] <h3h> Lachy: I like that idea in theory
  301. # [20:00] <Hixie> lachy: we need a group to collect all the arguments made and summarise them
  302. # [20:01] <Hixie> Lachy: it should become obvious when the comments start repeating themselves
  303. # [20:01] <Hixie> Lachy: that's when to move on :-)
  304. # [20:01] <othermaciej> I agree with Hixie that 8.1. Writing HTML documents might also be a good early one
  305. # [20:01] <Lachy> yeah, we just need someone to step in and say stop when that starts to happen
  306. # [20:01] * othermaciej hopes people tracking issues will note when an issue or argument is a duplicate
  307. # [20:02] <Hixie> Lachy: well that's objectively measurable -- when the people collecting feedback have done nothing but say add "[argument also made here, here, here, here, here]" to the relevant wiki/issue page for a certain amount of time, it's done :-)
  308. # [20:02] <Hixie> the certain amount of time would need establishing of course
  309. # [20:03] <Lachy> Hixie, when you get a chance, can I please get whatever stats you have for code, samp, kbd, and var from you? They're asking on www-html.
  310. # [20:04] * DanC_lap dumped some of the ideas above in http://esw.w3.org/topic/HtmlTaskBrainstorm near the bottom
  311. # [20:04] <Hixie> Lachy: i'll be at work in about an hour
  312. # [20:04] <Hixie> Lachy: if you're still up, remind me :-)
  313. # [20:05] <Lachy> ok, I'll probably be asleep. email them to me
  314. # [20:05] <Hixie> k
  315. # [20:05] <Hixie> if i remember
  316. # [20:05] <Lachy> I'll write you an email now
  317. # [20:05] <Hixie> cool
  318. # [20:05] <DanC_lap> anybody know Chasen Le Hara or Roman Kitainik? They offered to help with issue tracking, summarization, and clustering
  319. # [20:06] * anne notes that 8.1 is not in sync with 8.2 atm
  320. # [20:06] <DanC_lap> anybody wanna hold my hand setting up bugzilla for our use?
  321. # [20:07] * DanC_lap opens a http://www.w3.org/Bugs/ account...
  322. # [20:07] <anne> we want Bugzilla?
  323. # [20:07] <anne> ouch
  324. # [20:08] <DanC_lap> I want roundup, but I also want something supported by the systems team.
  325. # [20:08] <DanC_lap> W3C systems team supports bugzilla and tracker. tracker is not mature enough for my tastes.
  326. # [20:08] <DanC_lap> what do you want, anne ?
  327. # [20:09] * anne likes http://www.w3.org/2005/06/tracker/
  328. # [20:10] <DanC_lap> you're not nervous that it hasn't been used by zillions of people?
  329. # [20:10] <DanC_lap> it doesn't seem to keep a complete audit trail
  330. # [20:10] <anne> dino has my faith
  331. # [20:10] * anne used the tool quite a bit
  332. # [20:10] <anne> anyway, Hixie put down some requirements somewhere...
  333. # [20:11] * anne hasn't checked whether tracker meets those
  334. # [20:11] * Parts: zcorpan_ (zcorpan@84.216.41.242)
  335. # [20:11] <anne> I believe that (a) tracker is more hackable than Bugzilla and (b) more usable than Bugzilla
  336. # [20:11] <xover> How about we just get something set up to get started, and then bug the systeam about new versions or other tools as needed?
  337. # [20:11] * Joins: zcorpan_ (zcorpan@84.216.41.242)
  338. # [20:12] <DanC_lap> picking an issue at random... http://www.w3.org/2005/06/tracker/webapi/issues/2 ... it's closed, but I don't see an audit trail event that set the state to closed
  339. # [20:12] <anne> If that's the criteria a web page will work :)
  340. # [20:13] <anne> DanC_lap, doesn't e-mail 4 tell you why it's closed?
  341. # [20:13] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  342. # [20:14] <DanC_lap> I've been using a web page for a while. (http://www.w3.org/html/wg/il16 ). it only works if I personally am involved in every issue. It's time to move beyond that now.
  343. # [20:14] <anne> Bugzilla doesn't track e-mails on the list and isn't very user friendly
  344. # [20:14] <anne> Tracking all e-mails related to an issue is quite important, I think
  345. # [20:15] <DanC_lap> did the machine somehow read e-mail 4 and automatically set the status to "closed"?
  346. # [20:15] * Quits: Shunsuke (kuruma@219.110.80.235) (Quit: See you...)
  347. # [20:15] <anne> No, I closed it
  348. # [20:15] <DanC_lap> tracking email related to an issue is not that hard, if people put the issue name/number in the subject
  349. # [20:15] <anne> It does track the e-mails automatically
  350. # [20:16] <anne> I think Bugzilla works ok for tracking bugs in software, but it doesn't seem very good issue tracking software to me...
  351. # [20:16] <DanC_lap> one of hixie's requirements is a summary. I dunno if any of tracker/bugzilla/roundup supports an issue summary
  352. # [20:17] <anne> http://lists.w3.org/Archives/Public/www-archive/2007May/0011.html is one of those e-mails from Hixie
  353. # [20:17] <xover> DanC_lap: Last bullet on http://www.w3.org/2005/06/tracker/features ?
  354. # [20:17] <anne> He lists 3 things. Bugzilla gives you about a hundred but not really a good way to do those 3 things
  355. # [20:18] <anne> Actually, Bugzilla is pretty good at showing the current status
  356. # [20:18] <DanC_lap> I could maybe live with tracker if several people are happy to use it.
  357. # [20:19] <xover> Where's the source for tracker?
  358. # [20:19] <DanC_lap> a few clicks from http://www.w3.org/2005/06/tracker/ , I assume
  359. # [20:20] <DanC_lap> anne, when you closed that issue, did it generate an audit trail entry?
  360. # [20:20] <xover> Hmm. Can't seem to find it...
  361. # [20:20] <DanC_lap> nor can I...
  362. # [20:20] <xover> And the links there keep giving me permission deniet / auth dialogs.
  363. # [20:21] <DanC_lap> I note that the tracker todo list doesn't use tracker. http://www.w3.org/2005/06/tracker/todo
  364. # [20:21] <anne> DanC_lap, no
  365. # [20:21] <anne> I don't think the source code is publicly available
  366. # [20:22] <DanC_lap> ?!
  367. # [20:22] <xover> So “hackable” means...? :-)
  368. # [20:22] <anne> That I got from dino
  369. # [20:22] * Philip` notices that http://www.w3.org/html/wg/il16 has slightly incorrect character encoding
  370. # [20:23] <Philip`> (You should write it in HTML5 and add <meta charset="utf-8"> ;-) )
  371. # [20:23] <xover> I can't at most of the pages linked here or from the tracker pages; they're all not liking my user's privileges.
  372. # [20:23] <jdandrea> xover: ditto for me
  373. # [20:23] <Philip`> Oh, sorry, it's UTF-8 already, though some of the content is double-encoded UTF-8
  374. # [20:24] <othermaciej> DanC_lap: I think tracker is pretty weak - mailing list integration is the only strong point
  375. # [20:24] * jdandrea has been multitasking but reading along (who isn't?)
  376. # [20:24] <DanC_lap> hmm... I don't see the encoding bug, Philip` . clue me in?
  377. # [20:25] <Philip`> I see "Asbj<A with tilde><cedilla or something>rn Ulsberg"
  378. # [20:25] <othermaciej> it doesn't have a good way to record duplicates, doesn't support milestones very well (so we couldn't clearly defer an issue to HTML6), does not separate issue description from discussion, doesn't make it easy to organize things into categories (it only has the "product" level of category)....
  379. # [20:25] <Philip`> (and it becomes four characters if I switch the browser to iso-8859-1)
  380. # [20:26] <DanC_lap> phpht. nxml-mode garbled Ulsberg's name.
  381. # [20:26] <DanC_lap> my kingdom for consistent copy-and-paste!
  382. # [20:26] * anne notes that DanC_lap's page is in quirks mode
  383. # [20:26] <othermaciej> I think it might be worth having a tracker discussion on the list, since I don't think most people read www-archive regularly
  384. # [20:26] * zcorpan_ likes quirks mode
  385. # [20:26] <xover> Character should be: ø / &oslash; for reference.
  386. # [20:27] <anne> zcorpan_, maybe we should make quirks mode the web and be done with it :)
  387. # [20:27] <zcorpan_> yeah
  388. # [20:27] <anne> zcorpan_, no doctypes, no rendering differences because of a doctype and all works sort of...
  389. # [20:27] <Philip`> But then you'd break the 50% of sites that rely on standards mode
  390. # [20:27] <zcorpan_> we'll have to spec standards mode too
  391. # [20:27] <anne> Some other survey indicated that number to be 10%...
  392. # [20:28] <anne> It'd be the new quirks mode :)
  393. # [20:28] <Philip`> unless you redefine quirks to be standards and standards to be quirks, and require HTML5 documents to have no doctype, and say all the old HTML4 Strict and XHTML pages are legacy content
  394. # [20:28] <zcorpan_> hopefully we might be able to merge almost with full
  395. # [20:28] <Philip`> but the standards-liking people on the web wouldn't be terribly happy with that, I'd expect
  396. # [20:28] <anne> I like standards
  397. # [20:28] <DanC_lap> name, quirksmode fixed in 1.22
  398. # [20:29] <xover> Interesting autocomplete.
  399. # [20:29] * anne wonders if browsers should have a special w3.org rendering mode
  400. # [20:30] <anne> halt on the first error, hah!
  401. # [20:30] * DanC_lap doesn't look forward to discussion of which issue-tracking system to use on public-html, but agrees that there's some obligation
  402. # [20:30] <Philip`> DanC_lap: Looks good to me now :-)
  403. # [20:30] <DanC_lap> I consider it a "he who does the work makes the rules" sort of thing. But I'm low on volunteers.
  404. # [20:30] <othermaciej> I'd rather discuss requirements than which to use per se
  405. # [20:30] <othermaciej> did anyone volunteer for issue tracking?
  406. # [20:30] <DanC_lap> yes, 6 of us... or so...
  407. # [20:31] <DanC_lap> see http://www.w3.org/2002/09/wbs/40318/tasks83/results
  408. # [20:31] * othermaciej is not above encouraging more volunteers if needed
  409. # [20:31] <DanC_lap> or "simplified results" under http://www.w3.org/html/wg/#current
  410. # [20:32] <DanC_lap> David Dailey has made some progress investigating issue tracking stuff, but I think his target is too high.
  411. # [20:33] * Joins: dbaron (dbaron@63.245.220.242)
  412. # [20:33] <xover> Set up Bugzilla to get started, then start bugging systeam about making tracker public and making whatever changes we need to it for possible later migration?
  413. # [20:34] <DanC_lap> oops; I used up the time I have. I have another meeting now. xover, you're welcome to set up bugzilla for us
  414. # [20:34] <anne> What exactly are the goals of the tracking system?
  415. # [20:34] <DanC_lap> ... on a sort of trial basis, xo
  416. # [20:34] <DanC_lap> xover
  417. # [20:34] <othermaciej> we need to discuss goals / requirements before picking one
  418. # [20:34] <xover> hehe, will have a look at it.
  419. # [20:36] <anne> I strongly agree with othermaciej
  420. # [20:36] <anne> In related news, html5lib has been partially ported to Ruby
  421. # [20:36] <anne> http://intertwingly.net/blog/2007/05/14/Ruby-HTML5-Tokenizer
  422. # [20:36] <xover> Anyone working on a Perl version?
  423. # [20:37] <Hixie> othermaciej: are there requirmeents beyond those i posted?
  424. # [20:37] <Philip`> xover: There's someone working on a C version
  425. # [20:37] <anne> xover, not that I know. I believe someone is doing a C version though which will rule them all :)
  426. # [20:37] <Philip`> It'd be interesting to do some benchmark comparisons :-)
  427. # [20:37] <xover> Hmm. SHould be feasible to do Perl bindings on top of that, yeah.
  428. # [20:38] <Philip`> It's nice how HTML5 defines the parsing algorithm and also gives a large test case to feed through a parser for benchmarks
  429. # [20:38] <xover> Do we want access control for our issue tracker?
  430. # [20:38] <anne> Hixie, your e-mail is not elaborate on requirements on states and doesn't detail on the goals as far as I can tell
  431. # [20:40] <kingryan> anne: I'm working on a ruby version as well. I guess I should go ahead and get my working version out there
  432. # [20:42] <Hixie> anne: true
  433. # [20:42] <othermaciej> Hixie: well, it depends on how broadly you interpret "It should allow for a clear statement of the current state of the issue"
  434. # [20:43] <othermaciej> would "duplicate of issue XXX", or "deferred to the next version of HTML" be possible values of current state?
  435. # [20:43] <Hixie> i just meant like "open" vs "closed, no objections" vs "closed over objections", i guess
  436. # [20:43] <Hixie> i guess those would be good states too
  437. # [20:43] <Hixie> is there a wiki page yet with these requirements?
  438. # [20:43] <othermaciej> I think it is also useful to have categories
  439. # [20:43] <othermaciej> and queries
  440. # [20:43] <othermaciej> so I can check for "all open canvas issues"
  441. # [20:44] <othermaciej> we could start a wiki page
  442. # [20:44] <othermaciej> that might be more useful than starting with email
  443. # [20:44] <kingryan> Hixie: would out of scope issues be considered "closed"? or should that be a different state?
  444. # [20:45] <anne> i can make a page
  445. # [20:46] <othermaciej> kingryan: "closed" should presumably have reason it was resolved, such as indicating that the spec was changed, that the spec was not changed because the issue was out of scope, spec not changed because spec text was determined to be correct, etc
  446. # [20:46] <Hixie> kingryan: if the target audience is the editors, then 'closed' is fine; if the target audience includes those raising the issues, then that would be useful
  447. # [20:47] <Hixie> working out who the target audience is is the first step to working out the requirements
  448. # [20:47] <kingryan> Hixie: that's close to what I was thinking. Managing incoming feedback by helping people find answers for themselves would be a benefit to the WG.
  449. # [20:47] * Joins: hyatt (hyatt@17.255.99.100)
  450. # [20:47] <othermaciej> I think the audience is both editors and reviewers
  451. # [20:48] * Quits: hyatt (hyatt@17.255.99.100) (Client exited)
  452. # [20:48] * Joins: hyatt (hyatt@17.255.99.100)
  453. # [20:50] <anne> http://esw.w3.org/topic/HTML/IssueTrackerRequirements
  454. # [20:50] <anne> feel free to update
  455. # [20:51] <xover> anne: Was working on a page in paralell, so I cut&pasted over to yours.
  456. # [20:51] <xover> (So it probably repeats what's already there)
  457. # [20:55] <Hixie> updated
  458. # [20:55] * dbaron RRSAgent, pointer?
  459. # [20:55] * RRSAgent See http://www.w3.org/2007/05/14-html-wg-irc#T18-51-54
  460. # [20:55] * dbaron RRSAgent, make logs public
  461. # [20:55] <RRSAgent> I have made the request, dbaron
  462. # [21:01] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  463. # [21:01] <xover> hyatt: Do you have a W3C Bugzilla account?
  464. # [21:04] * Quits: hyatt (hyatt@17.255.99.100) (Quit: hyatt)
  465. # [21:06] * Joins: gavin_ (gavin@74.103.208.221)
  466. # [21:06] <anne> heh
  467. # [21:06] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  468. # [21:17] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  469. # [21:21] <xover> DanC_lap: Did a quick and dirty Bugzilla setup for this. Details on the Issue Tracker Requirements Wiki <http://esw.w3.org/topic/HTML/IssueTrackerRequirements>.
  470. # [21:22] * anne notes that Web Apps 1.0 has already been renamed
  471. # [21:22] <xover> Nothing fancy, just the basics so we can have a look at it.
  472. # [21:23] <xover> Yeah. And we may want to be more fine-grained then that in setting it up.
  473. # [21:25] <Hixie> "what is this web apps 1.0 thing?"
  474. # [21:25] <Hixie> :-P
  475. # [21:25] <Hixie> (as anne says, there is no "Web Apps 1.0" anymore)
  476. # [21:26] <xover> Give me a list of components and I'll set it up.
  477. # [21:27] <anne> "The DOM", "The semantics", "Browsing Contexts", "APIs", "The Language Syntax"
  478. # [21:27] <xover> Actually, that might as well go in the Wiki too.
  479. # [21:27] <anne> (from the HTML 5 introduction)
  480. # [21:28] <xover> BTW, http://www.w3.org/Bugs/Public/editkeywords.cgi lists existing keywords that may cover some of the "closed, no objection" status stuff.
  481. # [21:29] <anne> can't access that
  482. # [21:30] <anne> I think I'll go home
  483. # [21:30] <xover> Hmm. Ah, it's a config page so you need extra right to access it. Pity.
  484. # [21:30] <anne> I have to get up at 4:30AM tomorrow or something
  485. # [21:30] <xover> Ugh. Rather you then me... :-)
  486. # [21:30] <xover> `night
  487. # [21:31] * Quits: zcorpan_ (zcorpan@84.216.41.242) (Ping timeout)
  488. # [21:31] <DanC_lap> hmm.. IssueTrackerRequirements ... says "should". a requirement is a *must*, no? and... where's the other side of the negotiation? i.e. who proposes to meet these requirements?
  489. # [21:32] <anne> this is not a spec
  490. # [21:32] <anne> so no RFC2119 terminology
  491. # [21:32] <anne> although you're free to change stuff as you see fit :)
  492. # [21:33] <xover> WikiTitle should prolly say "Brainstorm" or summat... :-)
  493. # [21:35] * Joins: kwijibo (keith@87.113.74.56)
  494. # [21:36] <xover> anne: I added the keywords to the Wiki if you want to have a look.
  495. # [21:37] <xover> (and all these fields can be queried against, obviously)
  496. # [21:38] <kwijibo> is @profile really being dropped in html5? What will it be replaced by?
  497. # [21:38] * Quits: anne (annevk@213.236.208.22) (Ping timeout)
  498. # [21:39] * Quits: Lachy (Lachlan@203.217.95.91) (Connection reset by peer)
  499. # [21:40] <DanC_lap> I sure hope @profile isn't dropped. GRDDL depends on it.
  500. # [21:43] * Joins: Lachy (Lachlan@203.217.95.91)
  501. # [21:45] <kwijibo> me too
  502. # [21:48] <kwijibo> why was it dropped in the whatwg? http://wiki.whatwg.org/wiki/Changes_from_HTML4#Dropped_Attributes
  503. # [21:48] <Philip`> As far as I'm aware, the reason for profile not being included is that microformats are meant to use it but in practice they don't (but they work alright without it anyway, and content authors aren't going to change) and presumably there hasn't been a compelling reason to include it so far
  504. # [21:49] <Philip`> (I could be wrong, though)
  505. # [21:49] <kwijibo> eRDF and GRDDL use it though
  506. # [21:49] <kwijibo> and embedded semantics in html is just starting to take off
  507. # [21:50] <kwijibo> @profile's use is minimal, but growing, so it doesn't seem very forward looking to drop it
  508. # [21:50] <DanC_lap> microformats only sorta work without @profile. it's more clear how they work with @profile.
  509. # [21:51] <kwijibo> and especially unjoined up if w3c drops @profile in x/html5 but demands it for GRDDL
  510. # [21:52] <Philip`> I'd guess those would be good points to bring up in favour of adding profile and defining what it means
  511. # [22:03] <kwijibo> DanC_lap, re: GRDDL and microformats, with hCard at least, do you think perhaps what is needed is not a canonical @profile, but a choice of profiles?
  512. # [22:04] <kwijibo> or perhaps just an hCard ontology with loose semantics
  513. # [22:06] * Joins: dbaron (dbaron@63.245.220.242)
  514. # [22:08] <hsivonen> DanC_lap: are there known microformat consumers that ignore microformat data in the absence of profile=''?
  515. # [22:08] <Hixie> if they only "sort of" work without profile="", someone should tell the microformats community
  516. # [22:08] <Hixie> because currently, basically nobody uses profile=""
  517. # [22:08] <Hixie> and those few that do, usually use it incorrectly
  518. # [22:08] * Quits: loic (loic@86.71.4.162) (Quit: hoopa rules)
  519. # [22:09] <DanC_lap> hsivonen, http://esw.w3.org/topic/GrddlImplementations is a list of bits of software that grok hCard given a suitable profile but not otherwise.
  520. # [22:09] * Quits: jdandrea (jdandrea@68.192.165.143) (Quit: jdandrea)
  521. # [22:10] <kingryan> hsivonen: AFAIK, *all* microformat consumers will consume the mf even without the profile
  522. # [22:10] <DanC_lap> basically, any software that assumes hCard based on class names is squatting. HTML authors are supposed to be able to use any class names they like, for whatever purpose they like.
  523. # [22:10] <kingryan> fwiw, I've been working on getting proper profiles published on mf.org for hcard, hcalendar, hreview and xfolk
  524. # [22:11] <DanC_lap> I suppose the HTML WG has the right to take back class names, but it bothers me a bit.
  525. # [22:11] * kwijibo doesn't like predefined classnames
  526. # [22:12] <DanC_lap> the central registry of class names seems... I dunno... boring, somehow.
  527. # [22:12] <Philip`> HTML4 says class is to be used "For general purpose processing by user agents" (as well as for stylesheets) - I'm not entirely sure what means - would it include UAs processing certain class values as e.g. calendars?
  528. # [22:12] <hsivonen> DanC_lap: it seems that the microformat community sees more benefit in assuming that anything that looks like a hcard can be treated as such
  529. # [22:13] <DanC_lap> yes, they do. but I don't think W3C should endorse that.
  530. # [22:13] <hsivonen> DanC_lap: do the Grddl implementations work with real-world microformat data out there?
  531. # [22:13] <DanC_lap> some.
  532. # [22:13] <DanC_lap> e.g. the XTech web site
  533. # [22:14] <hsivonen> DanC_lap: I don't think it would be particularly useful to not endorse how microformats are practiced
  534. # [22:14] * Joins: jdandrea (jdandrea@68.192.165.143)
  535. # [22:15] <DanC_lap> surely crawlers and such can have local policies that say "smells like a duck to me; close enough." but it's still useful to be able to have an explicit "I am using hCard per http://www.w3.org/2006/03/hcard " mechanism.
  536. # [22:15] <kwijibo> the question mark I have regarding µf and GRDDL is, if there is a canonical profile, what ontologies should be used in the mapping?
  537. # [22:15] <DanC_lap> well, we disagree, hsivonen
  538. # [22:15] <hsivonen> DanC_lap: if the stuff works well enough with duck typing, what's the problem?
  539. # [22:15] <DanC_lap> yes, that has to be answered for each microformat, kwijibo
  540. # [22:16] <Lachy> DanC_lap, it's useless to try and mandate something like profile="" given the overwhelming evidence that it will fail in reality
  541. # [22:16] <kwijibo> DanC_lap: but some µf (well, hCard at least), are used in quite different ways
  542. # [22:16] <DanC_lap> it's not useless to allow profile="".
  543. # [22:16] <kwijibo> is an hCard a vCard, a Person, an Address, a Place?
  544. # [22:17] <DanC_lap> profile="" is already succeeding, for my purposes.
  545. # [22:17] <kwijibo> hsivonen: why should w3c endorse bad practice?
  546. # [22:17] <hsivonen> DanC_lap: I'm rather indifferent about allowing it, but I'm not keen on requiring it if I'm at the receiving end of conformance checker user complaints
  547. # [22:18] <hsivonen> kwijibo: if the practice works, classification as "bad" may be the thing to fix
  548. # [22:18] <Lachy> DanC_lap, what use is profile if you're the only one using it?
  549. # [22:18] <kwijibo> hsivonen: it only works so far
  550. # [22:18] <DanC_lap> Lachy, I'm not the only one using it, and I don't think it's a good use of my time to read the web to you.
  551. # [22:19] * kwijibo is using it
  552. # [22:19] <hsivonen> kwijibo: let's fix it when it no longer works
  553. # [22:19] <Lachy> what the?
  554. # [22:19] <DanC_lap> you're jumping to conclusions, Lachy.
  555. # [22:20] <DanC_lap> conclusions where the evidence to the contrary is available in the web.
  556. # [22:20] <Lachy> DanC_lap, Hixie gave evidence to show that it's rarely used on the web, and rarely used correctly when it is
  557. # [22:20] <DanC_lap> I'm not surprised.
  558. # [22:20] * kwijibo distrusts these pragmatic stances about what works and doesn't
  559. # [22:20] * Joins: zcorpan_ (zcorpan@84.216.41.242)
  560. # [22:20] <kwijibo> s/pragmatic/'pragmatic' :)
  561. # [22:21] <Hixie> DanC_lap: this is why we should agree on the principles first. not having profile="" is very much an application of the Pave The Cowpaths principle.
  562. # [22:21] <Lachy> well, I expect to see some evidence to support your case, including sufficient real world examples on the web that use it correctly and implementations that require it to be used
  563. # [22:21] <DanC_lap> (a) profiles for microformats are somewhat new, as is GRDDL, and (b) even if only a small fraction of the web uses profiles/GRDDL, it's still useful. There will always be more sloppy/unstructured stuff than formalized stuff, but the formalized stuff is still valuable.
  564. # [22:22] <Hixie> profiles for microformats have existed ever since the dawn of microformats
  565. # [22:22] <Hixie> the very first microformat, XFN, was introduced with a formal profile description grammar
  566. # [22:22] <DanC_lap> Lachy, I'll repeat myself just once more: XTech and http://esw.w3.org/topic/GrddlImplementations
  567. # [22:22] * Joins: inimino (inimino@75.71.88.233)
  568. # [22:22] <Hixie> and profile="" failed almost overnight, with no XFN processors looking at the profile="" attribute after about a week
  569. # [22:23] * kwijibo finds it whimsical that current real world examples are required for a future specification
  570. # [22:23] <Hixie> kwijibo: profile="" is not a future spec, it comes from HTML4 (198)
  571. # [22:23] <Hixie> 1998 even
  572. # [22:23] <kwijibo> so?
  573. # [22:23] <kwijibo> html 5 is a future specification
  574. # [22:23] <hsivonen> kwijibo: profile has had ample time to succeed
  575. # [22:24] <hsivonen> kwijibo: instead, it has failed
  576. # [22:24] <Lachy> so given evidence from the past that shows little use, there's no reason that will change much in the future
  577. # [22:24] <kwijibo> define failed?
  578. # [22:24] <zcorpan_> content doesn't use it and processors don't look at it
  579. # [22:24] <kwijibo> you could have said that of semantic markup as a whole in 2001
  580. # [22:24] <Lachy> kwijibo, an abundance of pages that use microformats on the web successfully, without using profile
  581. # [22:24] <hsivonen> kwijibo: markup consumers seeing more value in ignoring it and producers not bothering to use it "right"
  582. # [22:25] * kwijibo thinks this discussion is a little focused on microformats
  583. # [22:25] <Lachy> microformats is where the real world evidence comes from, what do you expect?
  584. # [22:26] <zcorpan_> xfn is the most used value for profile=""
  585. # [22:26] <zcorpan_> if we ignore microformats, we can conclude that profile="" isn't used at all in the wild :)
  586. # [22:26] <Lachy> zcorpan_, that's also the default value in WordPress
  587. # [22:27] <DanC_lap> Lachy, who gets to choose class names, authors or readers? Who gets to choose HTTP URI paths? (e.g. /robots.txt, /favico). Do you see an issue around taking choices away from content providers?
  588. # [22:27] <hsivonen> DanC_lap: tantek chooses :-)
  589. # [22:28] <Lachy> lol
  590. # [22:28] <DanC_lap> we like it when tantek chooses, but not when microsoft chooses. go figure.
  591. # [22:28] <Hixie> we do?
  592. # [22:28] <Hixie> half the features in HTML 5 are straight from microfost
  593. # [22:28] <Hixie> microsoft
  594. # [22:28] <Hixie> (well maybe a bit less than half. still a bit chunk)
  595. # [22:29] <Lachy> DanC_lap, I'm aware that fixing the robots.txt and favico URIs was a mistake, and the favicon one has been fixed (mostly)
  596. # [22:29] <Lachy> that's why we have rel=icon now
  597. # [22:30] <gsnedders> Lachy: but sadly from a UA POV you need to try /favicon.ico regardless :(
  598. # [22:30] <DanC_lap> yes, rel="icon" is an improvement, but I'm still gettting zillions of /favico requests for hardly any good reason.
  599. # [22:30] <zcorpan_> why is /favicon.ico frowned upon?
  600. # [22:30] <Lachy> only for IE, that need will fade once IE fixes that bug and current versions of IE fade
  601. # [22:30] <gsnedders> zcorpan_: needless requests
  602. # [22:30] <zcorpan_> ok
  603. # [22:31] <Hixie> you don't need favicon.ico for IE
  604. # [22:31] <Hixie> IE supports rel="SHORTCUT ICON"
  605. # [22:31] <DanC_lap> how will IE fix that bug? they'll stop paying attention to anything but rel="icon"? they'll stop supporting /favicon.ico ? that would be a pleasant surprise.
  606. # [22:31] <gsnedders> Lachy: but it's needed for backwards compat, I doubt they'll drop it
  607. # [22:31] * hsivonen notes that rel='icon' came about without URIs
  608. # [22:31] <Hixie> we'll always support /favicon.ico
  609. # [22:31] <hsivonen> IIRC by someone at Mozilla just implementing support
  610. # [22:32] <hsivonen> hyatt could probably tell more. IIRC, he had something to do with the ico/bmp decoder
  611. # [22:32] <hsivonen> nn. plane to catch in the morning
  612. # [22:33] <DanC_lap> zcorpan_, /favicon.ico is frowned on because the HTTP server operator is supposed to be the one who chooses what various paths mean, not the browser.
  613. # [22:33] <DanC_lap> but I guess it's now an open marketplace; short strings are for sale to the highest bidder.
  614. # [22:33] <DanC_lap> or the first one to get critical mass. or something.
  615. # [22:34] <kwijibo> even if microformats 'work' without @profile, nothing else does - get rid of @profile, and you might as well build microformats into the html5 spec
  616. # [22:34] <DanC_lap> that seems to be the trend
  617. # [22:35] <kwijibo> and I'm pretty sceptical about the extent to which microformats are 'practical', and 'work' anyway.
  618. # [22:35] <DanC_lap> I suppose it's a reasonable thing to do. But I still think @profile is worthwhile. It doesn't cost much, and it does have some value.
  619. # [22:35] * Joins: hyatt (hyatt@17.255.99.100)
  620. # [22:36] <kwijibo> despite having used µf as an html author for maybe 18 months or so, I still have never actually used them as a consumer
  621. # [22:36] * Quits: zcorpan_ (zcorpan@84.216.41.242) (Ping timeout)
  622. # [22:37] <kwijibo> I've got zero benefit from them, and haven't seen any compelling examples of people that have
  623. # [22:41] * Joins: zcorpan_ (zcorpan@84.216.41.242)
  624. # [22:41] <Hixie> DanC_lap: tell that to the p3p folk
  625. # [22:49] <DanC_lap> so you're inclined to start review with section 8.1. Writing HTML documents, Hixie ? I just took a quick look. it seems to invite a variety of editorial comments...
  626. # [22:51] * Quits: hyatt (hyatt@17.255.99.100) (Connection reset by peer)
  627. # [22:51] * Joins: hyatt (hyatt@17.255.99.100)
  628. # [22:51] <DanC_lap> ah... "this is why we should agree on the principles first" so you're inclined to continue that discussion. hmm.
  629. # [22:52] <DanC_lap> I think we need more chairs if we're going to continue that discussion. or something.
  630. # [22:52] <Philip`> The problem with reviewing 8.1 is that the comment about void-element slashes probably won't survive for long :-(
  631. # [22:53] <zcorpan_> a useful property about 8.1 is that it doesn't contain any conformance requirements for UAs
  632. # [22:54] <Hixie> DanC_lap: either would be fine imho. mjs also made some other suggestions of good starting points.
  633. # [22:54] <Hixie> DanC_lap: at the moment i'm going through the feedback from 2005/2006
  634. # [22:54] <zcorpan_> ...so it's easier to read for authors who can't distinguish between whether a requirement applies to authors or UAs
  635. # [22:57] <othermaciej> whether or not HTML5 includes profile="", I'm wonder how GRDDL will compete with other methods of extracting microformat data if it requires profile to be present, given the large amount of microformat data that exists in documents with no profile, particularly since the 2003/g/data-view profile is not the one defined by the microformats themselves
  636. # [22:57] <othermaciej> s/I'm wonder/I wonder/
  637. # [22:58] <othermaciej> it's pretty weird that to parse XFN, it requires the GRDDL profile URI, not the XFN profile URI
  638. # [22:59] <DanC_lap> that would be wierd. it's not the case, though.
  639. # [22:59] <othermaciej> really? I don't see any mention of the XFN profile URI in the xfn example
  640. # [22:59] <othermaciej> maybe I'm looking at an old draft
  641. # [23:00] <othermaciej> http://www.w3.org/TR/grddl/
  642. # [23:00] <othermaciej> that seems like the current version
  643. # [23:00] * Quits: kingryan (rking3@208.66.64.47) (Client exited)
  644. # [23:01] <DanC_lap> yes, http://www.w3.org/TR/grddl/#profile-bind . friends.html only bears the xfn-workalike profile
  645. # [23:01] * Joins: kingryan (rking3@208.66.64.47)
  646. # [23:01] * DanC_lap hunts for the actual test case...
  647. # [23:02] <DanC_lap> the test case is http://www.w3.org/2003/g/td/friends.html
  648. # [23:02] <othermaciej> the only profile I actually see mentioned is http://www.w3.org/2003/g/data-view
  649. # [23:02] <othermaciej> I guess I'm confused about how this works
  650. # [23:02] <othermaciej> (in the spec)
  651. # [23:02] <DanC_lap> yeah, it's kinda confusing.
  652. # [23:03] * Joins: hasather (hasather@81.235.209.174)
  653. # [23:04] <DanC_lap> a document can refer to a GRDDL transformation either directly (using the http://www.w3.org/2003/g/data-view profile) or indirectly, a la the XFN-workalike case.
  654. # [23:04] <othermaciej> would GDDDL work with the standard XFN profile that would be used by existing XFN content?
  655. # [23:04] <othermaciej> (i.e. http://gmpg.org/xfn/11 )
  656. # [23:04] <DanC_lap> it would if http://gmpg.org/xfn/11 were modified a bit
  657. # [23:05] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  658. # [23:07] <othermaciej> so it couldn't parse existing microformat content, even if it used the right profile URI, unless the content at the relevant profile URI were changed to have a transformation link (which is admittedly much more reasonable than requiring the content to be changed)
  659. # [23:07] <DanC_lap> right.
  660. # [23:08] <DanC_lap> GRDDL won't get any RDF data out unless somebody explicitly put it there, whether directly or indirectly.
  661. # [23:08] <beowulf> http://www.456bereastreet.com/archive/200705/another_look_at_html_5/ # Roger Johansson sort of retracts previous sort of rant on html5
  662. # [23:09] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
  663. # [23:10] <DanC_lap> the whole GRDDL/microformats thing is not really my top priority today; I don't have enough discipline to leave it alone, though ;-)
  664. # [23:10] <DanC_lap> I'm owe the WG something about what we *should* talk about this week
  665. # [23:10] <othermaciej> I think that is a reasonable technical approach, although it limits the applicability of GRDDL tools as current examples of microformat parsers
  666. # [23:11] <DanC_lap> yes, the applicability is limited.
  667. # [23:11] <othermaciej> I'm not that interested in the profile attribute one way or another
  668. # [23:12] <othermaciej> DanC_lap: maybe a wiki page of agenda topics? would be useful even if you already have a good choice in mind
  669. # [23:12] <othermaciej> I think most review topics raised today would be good, except parsing generally (including the UA requirements)
  670. # [23:13] * Quits: frippz (fredrikfro@193.11.209.47) (Quit: frippz)
  671. # [23:14] * Joins: gavin_ (gavin@74.103.208.221)
  672. # [23:14] <DanC_lap> I didn't make a new wiki page, but I dumped some agenda topics into http://esw.w3.org/topic/HtmlTaskBrainstorm
  673. # [23:15] <othermaciej> ah, cool
  674. # [23:16] <DanC_lap> I still prefer to focus on parsing. I think it's time to explore the nitty-gritty detail end of the spectrum. But not many others seem to agree.
  675. # [23:17] <Hixie> well, it depends what you mean by "explore"
  676. # [23:17] <Hixie> how would you envision a review of section 8.2 going?
  677. # [23:18] <DanC_lap> my favorite idea is to ask people to raise issues a la "I disagree with what section X.Y says about the attached document, because..."
  678. # [23:19] <Hixie> maybe it would help me understand what you had in mind if you could do an example? like, what kind of issue in that section would you yourself disagree with and how would you raise the issue?
  679. # [23:19] <othermaciej> I would have a hard time reviewing 8.2 other than to try to implement and test on existing content
  680. # [23:20] <othermaciej> (though I do know of a tiny handful of issues based on experience w/ parsing issues on existing content, like the fact that the meta charset preparser probably needs to scan the whole document, not a fixed number of bytes)
  681. # [23:21] <Hixie> yeah, my head is in the same about that issue for now. i think someone already raised it though so eventually we'll have to fix it.
  682. # [23:21] <DanC_lap> so that's one example... something where the charset isn't in the 1st 512 bytes, I guess.
  683. # [23:21] * Hixie hates the idea of _requiring_ browsers to run two parsers in parallel, or requiring them to parse the document twice
  684. # [23:21] <DanC_lap> I was thinking about the cases where IE doesn't make a tree.
  685. # [23:22] <Hixie> DanC_lap: that's easy to respond to -- "there's no evidence that charsets are provided later than the 512th byte on a statistically significant number of pages"
  686. # [23:22] <DanC_lap> my notes also say "Gecko coerces unknown tags to upper case, Opera doesn't"
  687. # [23:23] <DanC_lap> ok, that response makes sense; i.e. it's easy enough to imagine chairing that discussion.
  688. # [23:23] <Hixie> gecko doesn't coerce tags to uppercase. that's a DOM thing, not parser.
  689. # [23:23] <Hixie> (and already covered by the spec)
  690. # [23:24] <Hixie> well, my point is i would hate for lots of issues to be raised without supporting evidence
  691. # [23:24] <Hixie> in that way
  692. # [23:24] <Hixie> because then when the editors get around to going through them they'd all just get closed with "no evidence"
  693. # [23:25] <DanC_lap> I don't know either of these issues in detail, but...
  694. # [23:26] <DanC_lap> you hand othermaciej both said the charset parsing issue needs work.
  695. # [23:26] <othermaciej> I don't necessarily mind that, but I think it would be a more positive experience for the group to start out reviewing something less technically demanding
  696. # [23:26] <DanC_lap> we've done plenty of "less technically demanding" for a while, for my tastes.
  697. # [23:27] <zcorpan_> there are only a handful of people who can make useful comments on the parsing section
  698. # [23:27] <othermaciej> honestly the details of parser error handling are extremely hard, extremely boring, and mostly only deeply relevant to implementors
  699. # [23:27] <Hixie> well for the charset thing i happen to know that browsers don't do what the spec says and i need to do some research to work out if they actually need to not do what the spec says
  700. # [23:27] <DanC_lap> what is it that has you saying "eventually we'll have to fix it" about charset stuff, Hixie ?
  701. # [23:27] <Hixie> but it's hard
  702. # [23:28] <DanC_lap> extremely hard, extremely boring, and our job, IMO.
  703. # [23:28] <Hixie> well i'm all in favour of people reviewing this section
  704. # [23:28] <Hixie> but i have no patience for uninformed feedback on this section
  705. # [23:28] <zcorpan_> DanC_lap: most people on the list aren't implementors, and aren't test case writers either, unless i'm mistaken
  706. # [23:28] <Hixie> just saying :-)
  707. # [23:29] <DanC_lap> Hixie, if you can just ignore stuff you have no patience for, that would probably be OK.
  708. # [23:29] <Hixie> fair enough
  709. # [23:29] <Hixie> i guess in practice it wouldn't really affect me and hyatt anyway, if we're just going to go through the issues once they've been distilled into bug reports in bugzilla
  710. # [23:30] <othermaciej> the parsing section does have the advantage that it's relatively objective compared to other things, but that's only helpful if people respect that
  711. # [23:30] <zcorpan_> DanC_lap: if you want people to make useful comments about the parsing section, you would have to educate them to write test cases first (which might be a good thing), or have them implement it. just commenting on it without doing any of those things is a waste
  712. # [23:30] <DanC_lap> i expect to put in place some mechanism where people can escalate to the chair if they expected to hear from the editor and didn't. So it'll be up to me to explain why the editor didn't answer (or to prompt the editor to answer)
  713. # [23:31] <Hixie> certainly i'd be happy to answer to any e-mail that people think i should have replied to but didn't
  714. # [23:31] <DanC_lap> indeed, I'd expect people to do test cases or write code. I'm kinda bored with anything else.
  715. # [23:31] <zcorpan_> oh me too, but i don't expect everyone to :)
  716. # [23:32] <zcorpan_> some just want to write tutorials
  717. # [23:32] <zcorpan_> for instance
  718. # [23:32] <DanC_lap> a tutorial would be fine. lots of people have indicated an interest in doing it, but nobody has done it. (or at least: nobody has showed it to me if they have)
  719. # [23:33] <zcorpan_> right
  720. # [23:33] <beowulf> what would you write a tutorial on, at this stage? writing tests?
  721. # [23:34] <zcorpan_> canvas, wf2
  722. # [23:34] <zcorpan_> writing html in general
  723. # [23:34] <beowulf> ah
  724. # [23:35] * Joins: dbaron (dbaron@63.245.220.242)
  725. # [23:36] * Quits: kingryan (rking3@208.66.64.47) (Client exited)
  726. # [23:37] * Joins: kingryan (rking3@208.66.64.47)
  727. # [23:37] <zcorpan_> DanC_lap: tutorials that i know of: http://dev.opera.com/articles/view/improve-your-forms-using-html5/ http://developer.mozilla.org/en/docs/Canvas_tutorial
  728. # [23:38] <Philip`> I was thinking it'd be useful to have a tutorial for making animated interactive things (mainly games, I guess) with canvas, since it's not covered by what's on MDC
  729. # [23:38] <Philip`> and the point of canvas is that it's dynamic - it's not much fun if all you're doing is drawing some lines and gradients
  730. # [23:39] <beowulf> zcorpan_: this was the first tutorial I read on wf2 http://olav.dk/wf2/demo/default.asp
  731. # [23:39] <Philip`> But then I was thinking I've got to write about another three thousand words for some project I should have finished weeks ago, so the thought left my mind...
  732. # [23:40] <zcorpan_> beowulf: ah, right. more like a demo though
  733. # [23:40] <beowulf> it worked for me :)
  734. # [23:42] <zcorpan_> yeah
  735. # [23:42] <zcorpan_> i guess opera/dashboard widget tutorials might cover some html5 things too
  736. # [23:42] <DanC_lap> 34 volutneers for the tutorial task. that's maybe enough for its own mailing list.
  737. # [23:43] * zcorpan_ is one of them, but zcorpan wants to focus on writing test cases
  738. # [23:43] <DanC_lap> tutorials for canvas, forms would be interesting candidates for June WDs
  739. # [23:43] * beowulf is one also, i think it's all i'm qualified for
  740. # [23:44] <zcorpan_> http://wiki.whatwg.org/wiki/HTML5_Tutorial
  741. # [23:47] * zcorpan_ can turn http://simon.html5.org/discussions/namnrymder-i-xml into an xhtml5 tutorial
  742. # [23:49] <zcorpan_> which would really be an xml + namepsaces tutorial
  743. # [23:57] <zcorpan_> http://www.accessifyforum.com/viewtopic.php?t=8083
  744. # Session Close: Tue May 15 00:00:00 2007

The end :)