/irc-logs / w3c / #html-wg / 2007-08-17 / end


  1. # Session Start: Fri Aug 17 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:05] <DanC> ok, I updated http://www.w3.org/2002/09/wbs/40318/dprv/
  4. # [00:05] <DanC> somebody spot check it, please? mjs, gsnedders, ...?
  5. # [00:05] <Hixie> doesn't let me see it
  6. # [00:05] <DanC> weird. some people can and some can't
  7. # [00:06] * Hixie wonders why his mail server suddenly won't let him send mail
  8. # [00:06] <mjs> DanC: looking (though I have another meeting momentarily)
  9. # [00:07] <mjs> DanC: can't see it at the moment
  10. # [00:07] * DanC wonders which apple manager to armwrestle for more of mjs's time ;-)
  11. # [00:08] * mjs is now known as mjs_afk
  12. # [00:08] <mjs_afk> DanC: it will come naturally - we are near the end of an OS release cycle
  13. # [00:08] * DanC fixed a markup problem in http://www.w3.org/2002/09/wbs/40318/dprv/ ; doubts it helps with the visibility
  14. # [00:09] <DanC> famous last words, mjs ;-)
  15. # [00:09] <DanC> try http://www.w3.org/2002/09/wbs/40318/dprv/ again, hixie? I changed the dates so it's open now
  16. # [00:10] * karl has 15 minutes of brain time available
  17. # [00:11] <Hixie> DanC: the descriptions of "agree" and "disagree" sound the same
  18. # [00:12] <DanC> if the suggested changes aren't made, agree stays agree but disagree stays disagree
  19. # [00:12] <Hixie> DanC: otherwise seems fine
  20. # [00:12] <Hixie> DanC: maybe make that clearer
  21. # [00:12] <Hixie> DanC: as written, then sounded equivalent
  22. # [00:12] * Quits: billmason (billmason@ (Connection reset by peer)
  23. # [00:13] * Joins: billmason (billmason@
  24. # [00:13] * DanC lacks inspiration for improving clarity; welcomes suggestions
  25. # [00:14] * Quits: mjs_afk (mjs@ (Quit: mjs_afk)
  26. # [00:15] <karl> "11. priniciple "Baby Steps"
  27. # [00:15] <karl> 14. priniciple "Handle Errors"
  28. # [00:15] <jgraham> Agree should be something like agree with the spirit of the principle but with some changes to the wording
  29. # [00:15] <jgraham> or something like that
  30. # [00:16] <karl> ooops in fact
  31. # [00:16] <karl> it is a lot of them which are called priniciple instead of principle
  32. # [00:17] <karl> danc in the intro, it is said what will be done if there is support, but not what will be done if no support at all.
  33. # [00:19] <DanC> "Strongly Disagree = No support. Delete it."
  34. # [00:20] <DanC> karl, I'd fix that typo if I could do it all at once, but I don't think I'm going to do umpteen form submissions
  35. # [00:21] <DanC> actually, regarding what will be done with the survey results, nothing is guaranteed/binding: "This survey is a non-binding, informational-gathering excercise"
  36. # [00:22] <karl> yes I have read the non-binding clause.
  37. # [00:23] <karl> but I think it will be perceived as
  38. # [00:23] <karl> not mandatory, but if support we might think of publishing it
  39. # [00:23] <karl> not mandatory, but if NO support, we might… hmm maybe publish it anyway? drop it? keep it on the wiki as non mandatory?
  40. # [00:24] <karl> I say that because the principles are used (too often) as justifications in the discussions, that it makes them a sensitive topic.
  41. # [00:26] * karl is trying to think about an alternative
  42. # [00:26] <karl> brain still foggy I guess
  43. # [00:26] <DanC> "too often"? hmm... their main utility is as justification in discussions. if they don't work that way, they should be dropped
  44. # [00:27] <karl> :) yes too often for me ;) I will explain in the review I guess.
  45. # [00:28] <karl> ooops time's up. Train time.
  46. # [00:28] * Quits: karl (karlcow@ (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  47. # [00:30] * Joins: err (gyzmodo@
  48. # [00:31] * Parts: err (gyzmodo@
  49. # [00:33] * DanC announced the survey
  50. # [00:35] <gsnedders> DanC: I better not spend two hours tomorrow morning doing WG stuff again
  51. # [00:35] <gsnedders> :)
  52. # [00:35] <DanC> that should teach you to claim things are "obvious" ;-)
  53. # [00:35] <gsnedders> I expected it to take that long, though
  54. # [00:36] <gsnedders> mainly just checking my thoughts were correct
  55. # [00:36] <DanC> it was a helpful and timely summary
  56. # [00:36] <gsnedders> (which, in all but one case, they were)
  57. # [00:36] <gsnedders> what parts did you think were too generous?
  58. # [00:48] <Hixie> where is "pave the cowpaths" in the survey?
  59. # [00:51] <Philip`> "Universal Access"/"Separation of Concerns"/"Baby Steps" are inconsistent between survey and CVS too
  60. # [00:51] <Hixie> yeah just noticed Universal Access missing
  61. # [00:51] <Hixie> that's one of the most important
  62. # [00:52] <DanC> somebody on the telcon thought one part was too generous. I don't remember which, gsnedders . And I haven't read enough mail to say.
  63. # [00:52] * Quits: kingryan (rking3@ (Ping timeout)
  64. # [00:53] <DanC> sorry about the problems in the survey; I'm struggling to stay in sync.
  65. # [00:54] * DanC hunts for current version of cowpaths, universal access...
  66. # [00:54] <DanC> http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html?rev=HEAD#universal-access
  67. # [00:57] <DanC> does cowpaths look right now?
  68. # [01:00] <DanC> should I delete baby steps?
  69. # [01:00] <DanC> it's not in http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html?rev=HEAD
  70. # [01:00] <DanC> I guess so...
  71. # [01:02] <DanC> all better now?
  72. # [01:03] <DanC> Philip`, Hixie ?
  73. # [01:06] <Philip`> DanC: Looks like it all matches the CVS copy now
  74. # [01:06] <DanC> tx
  75. # [01:06] * DanC hopes ChrisW doesn't mind that he spent half an hour helping me sync the survey with the wiki and then I undid all that and sync'd with mj's work in cvs.
  76. # [01:07] * DanC gets SIG_FAMILY_TIME
  77. # [01:09] * Joins: mjs (mjs@
  78. # [01:19] * Quits: billmason (billmason@ (Quit: .)
  79. # [01:19] * Joins: robburns (robburns@
  80. # [01:26] * Quits: gavin_ (gavin@ (Ping timeout)
  81. # [01:27] * Joins: sbuluf (sgnbqyp@
  82. # [01:31] * Joins: gavin_ (gavin@
  83. # [01:39] <Philip`> DanC: Oops, I forgot to respond about the screen.css charset problem - I meant to say thanks for forwarding the issue
  84. # [01:53] * Joins: karl (karlcow@
  85. # [01:55] * Joins: bitcrumb (Lode@
  86. # [01:55] * karl is fixing danc spelling mistakes in the survey…
  87. # [01:55] * Quits: bitcrumb (Lode@ (Quit: bitcrumb)
  88. # [01:58] <karl> done
  89. # [02:01] * Parts: hyatt (hyatt@
  90. # [02:01] * Quits: johnst (johnst@ (Quit: Leaving)
  91. # [02:01] <Philip`> karl: Would it be easy to fix http://lists.w3.org/Archives/Public/public-html/2007Aug/0639.html too?
  92. # [02:02] <Philip`> Same problem in "Handle Errors" too
  93. # [02:08] <karl> hmmm which one is which one
  94. # [02:14] <karl> hmm ok I see
  95. # [02:15] <karl> Philip`: fixed :) thanks for the notification
  96. # [02:17] <Philip`> Thanks for the fix :-)
  97. # [02:19] * Joins: olivier (ot@
  98. # [02:20] * Joins: mjs_ (mjs@
  99. # [02:21] * Quits: mjs_ (mjs@ (Quit: mjs_)
  100. # [02:22] * Quits: mjs (mjs@ (Ping timeout)
  101. # [02:35] * Philip` tries updating the spec-splitter script
  102. # [02:35] <Philip`> http://canvex.lazyilluminati.com/wa1/multipage/
  103. # [02:35] <Philip`> http://canvex.lazyilluminati.com/wa1/multipage/introduction.html#dom
  104. # [02:35] <Philip`> http://canvex.lazyilluminati.com/wa1/multipage/oopsthenamechanged.html#dom
  105. # [02:36] <Philip`> Hopefully that works at redirecting people to the correct page if a link breaks
  106. # [02:37] <Philip`> The only minor problem is that you have to download a 50KB JS file, but hopefully that gets cached and only happens once...
  107. # [03:18] * Joins: mjs (mjs@
  108. # [03:19] * Quits: zcorpan_ (zcorpan@ (Ping timeout)
  109. # [03:25] * Quits: tH (Rob@ (Quit: ChatZilla [XULRunner])
  110. # [03:31] <karl> http://www.w3.org/html/wg/html5/principles/
  111. # [03:32] <karl> $Revision: 1.2 $ of $Date: 2007/06/26 16:27:04 $ (revision log)
  112. # [03:32] * karl wonders if the last version has been committed
  113. # [03:34] * Quits: gavin_ (gavin@ (Ping timeout)
  114. # [03:39] * Joins: gavin_ (gavin@
  115. # [03:54] * Joins: mjs_ (mjs@
  116. # [03:55] * Quits: mjs (mjs@ (Ping timeout)
  117. # [04:06] * Quits: mjs_ (mjs@ (Quit: mjs_)
  118. # [04:22] * Quits: jgraham_ (jgraham@ (Ping timeout)
  119. # [04:22] * Joins: jgraham_ (jgraham@
  120. # [04:27] * Quits: jgraham_ (jgraham@ (Ping timeout)
  121. # [04:29] * Joins: jgraham_ (jgraham@
  122. # [05:06] * Joins: myakura (myakura@
  123. # [05:10] * Quits: robburns (robburns@ (Quit: robburns)
  124. # [05:23] * Joins: mjs (mjs@
  125. # [05:34] * Joins: robburns (robburns@
  126. # [05:41] * Quits: gavin_ (gavin@ (Ping timeout)
  127. # [05:46] * Joins: gavin_ (gavin@
  128. # [06:06] * Quits: robburns (robburns@ (Quit: robburns)
  129. # [06:15] * Joins: dbaron (dbaron@
  130. # [06:15] * Joins: robburns (robburns@
  131. # [06:34] <karl> http://blueoxen.net/c/purple/purple-include/
  132. # [06:34] <karl> Xinclude client side
  133. # [06:40] * Quits: robburns (robburns@ (Ping timeout)
  134. # [06:59] * Joins: robburns (robburns@
  135. # [07:02] * Quits: heycam (cam@ (Ping timeout)
  136. # [07:15] * Joins: icaaq (icaaaq@
  137. # [07:18] * Parts: icaaq (icaaaq@
  138. # [07:18] * Joins: heycam (cam@
  139. # [07:29] * Joins: foca (foca@
  140. # [07:35] * Parts: foca (foca@
  141. # [07:49] * Quits: gavin_ (gavin@ (Ping timeout)
  142. # [07:54] * Joins: gavin_ (gavin@
  143. # [08:06] * Quits: schepers (schepers@ (Ping timeout)
  144. # [08:15] * Quits: Lachy (chatzilla@ (Ping timeout)
  145. # [08:19] * Joins: Lachy (chatzilla@
  146. # [08:50] * Quits: Lachy (chatzilla@ (Quit: ChatZilla [Firefox])
  147. # [08:51] * Quits: dbaron (dbaron@ (Ping timeout)
  148. # [08:57] * Joins: Lachy (chatzilla@
  149. # [09:35] * Quits: olivier (ot@ (Quit: Leaving)
  150. # [09:35] * Quits: karl (karlcow@ (Ping timeout)
  151. # [09:36] * Joins: karl (karlcow@
  152. # [09:45] * Joins: edas (edaspet@
  153. # [09:57] * Quits: gavin_ (gavin@ (Ping timeout)
  154. # [10:02] * Joins: gavin_ (gavin@
  155. # [10:16] * Quits: karl (karlcow@ (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  156. # [11:31] * Joins: zcorpan_ (zcorpan@
  157. # [11:39] * Joins: ROBOd (robod@
  158. # [11:51] * Quits: myakura (myakura@ (Quit: Leaving...)
  159. # [11:59] * Quits: mjs (mjs@ (Quit: mjs)
  160. # [12:00] * Quits: jgraham_ (jgraham@ (Quit: Ex-Chat)
  161. # [12:01] * Joins: beowulf (beowulf@
  162. # [12:04] * Quits: gavin_ (gavin@ (Ping timeout)
  163. # [12:09] * Joins: gavin_ (gavin@
  164. # [12:17] <zcorpan_> robburns: i don't understand your problem with Hixie taking whatwg feedback into account (as he said he would)
  165. # [12:23] <robburns> hi
  166. # [12:24] <robburns> zcorpan I'm not taking issue with Hixie taking whatwg feedback into account. The issue I'm concerned about is that a WG needs an editor that has at least some time to focus on the needs of the WG
  167. # [12:25] <robburns> That means engaging with the list over substantive topice
  168. # [12:25] <robburns> drawing from the wiki to make changes to the draft
  169. # [12:26] <robburns> perhaps sending a message to the list to start discussing solutions
  170. # [12:26] <Lachy> robburns, he will be doing that. It just seems like your annoyed because his schedule isn't aligned with your interests
  171. # [12:26] <robburns> It doesn't have to me my interests, it just has to be with the interests of the WG
  172. # [12:27] <Lachy> we discussed a few ideas in #whatwg about how to address the PR issues and keeping the HTMLWG more well informed about the status and schedule
  173. # [12:27] <Lachy> define the interests of the WG?
  174. # [12:28] <Lachy> there are around 400 people in the HTMLWG and 700+ people in the WHATWG. Not all of those people are going to be interested in working on the same as everyone else
  175. # [12:29] <robburns> that's not something for me to define. The interests of the WG are something for the chairs and the editors to define (or at least tease out).
  176. # [12:29] <robburns> The WhatWG doesn't enter into this issue. They're free to do what they want.
  177. # [12:29] <Lachy> there are issues in the backlog from the whatwg and other sources that date back 2 or 3 years. You can't tell me that issues discussed within the last 2 months are automatically of higher priority than some of the older issues
  178. # [12:29] <Lachy> the whatwg and htmlwg are working *together*
  179. # [12:31] <Lachy> the barrier between the 2 groups is very artificial. However, it's unbelievable how much hostility there is from many in the HTMLWG towards the WHATWG.
  180. # [12:31] <robburns> Issues discussed in this WG are not of higher priorities than issues discussed on WhatWG (again WhatWG has nothing to do with this). However, in terms of this WG and the persons acting in a role as editor for this WG, the issues discussed in this WG are the only things available to inform edits to the draft.
  181. # [12:33] <Lachy> whether you like it or not, the whatwg is involved with this work. The HTML5 spec was adopted with everyone well aware that the whatwg would continue to operate in conjunction with the htmlwg
  182. # [12:33] <robburns> Why do you think the WGs are working together on this draft. I've tried to follow the proceedings of this WG very closely and I've seen nothing that says that. Also since this WG is open to anyone, those in the WhatWG that wanted to participate in the W3C process could simply join this WG
  183. # [12:34] <Lachy> regardless of what you think, there are people who can't join the HTMLWG. For instance, anyone who works for a W3C member needs to have approval from their employer to join. Not everyone can get that
  184. # [12:34] <robburns> The WhatWg is certainly involved in this work. The WhatWG's involvement was to decide to turn the draft over to the W3C. There was an offering and a request to accept the whole draft as is as a starting point for this WG's deliberations.
  185. # [12:34] <Lachy> Others have many other reasons for either not wanting to, or being unable to join
  186. # [12:35] <robburns> Well if the reason they cannot joint the WG are due to W3C policies, then are hardly think its appropriate to let them round-end those policies through some loop-hole held open by the editor.
  187. # [12:35] <Lachy> the spec was adopted with the understanding that Hixie would only be working on a single spec, which is worked on by both the whatwg and htmlwg. You just have to accept that
  188. # [12:36] <hsivonen> robburns: Hixie is looking at specific spec change issues on a first-come-first-served basis. Given the volume of mail on public-html, there wouldn't be any progress if he engaged in every thread on public-html immediately
  189. # [12:37] <robburns> There can be a single spec without the editor answering to a separate body. Once WhatWG decided to bring this to W3C, they made a commitment to move deliberations over to W3C. Its unfortunate if some cannot participate because of that decision, but they presumably were involved with deliberations on that at WhatWG.
  190. # [12:37] <hsivonen> robburns: it would be crazy to let the WHATWG backlog go to waste
  191. # [12:38] * Quits: edas (edaspet@ (Client exited)
  192. # [12:38] <Lachy> no, the WHATWG decided to allow the HTMLWG to work together with them. They didn't decide to move the whole thing over and disband
  193. # [12:38] <robburns> A firs-tcom-first-served basis seems like a very bureaucratic approach to this. He's not serving particular members of our WG nor is he serving particular issues brought to the WG. He's serving the WG as a whole
  194. # [12:40] <Lachy> I have no idea what you mean by that
  195. # [12:40] <robburns> I'm not suggesting he let the WhatWG backlog go to waste. Here's a possible scenario. Hixie decides that working on the m element is of eminent importance to him suddenly. He could then post a message to the list outlining a problem with the current draft or a problem faced by authors who need to mark or highlight something.
  196. # [12:41] <Lachy> he needs to address issues one at a time. Using roughly a first-come-first-served basis is a fair way to deal with all the issues
  197. # [12:41] <robburns> The list goes into discussion mode about the problem. Different perspective are aired about the problem. Battles are waged
  198. # [12:42] <robburns> meanwhile Hixie's going through all of the WhatWG email he can find on this topic. He's reading through all of them; letting them inform his view of the issue. Every once in a while he posts a response to the thread in our WG relating some great information he found in an email.
  199. # [12:42] <zcorpan_> robburns: we are chartered to "actively pursue convergence with WHATWG"
  200. # [12:43] <Lachy> robburns, rehashing all the discussion that has already been done on whatwg prior to updating the spec is counter productive. Although it would be useful to notify the group of upcoming issues and provide pointers to previous discussion for the HTMLWG to catch up, the group should try to wait till the spec has been updated to match previous feedback before discussing the issue heavily
  201. # [12:43] <robburns> At some point solutions start percolating to the problems Hixie outlined. They end up on the wiki. Then Hixie takes the solutions that ended up on the wiki and composes some new language for the draft
  202. # [12:44] <robburns> Return to step 1 and repeat all steps
  203. # [12:46] <robburns> How do the steps I outlined undermine convergence. (this is out of scope for my algorithm, but Once that process is completed Hixie goes and makes edits at the WhatWG draft). Voila: convergence
  204. # [12:46] <robburns> Lachy, what you're calling counter-productive is called WG procedures everywhere else
  205. # [12:46] <Lachy> Hixie already explained why that process of getting consenus for every issue before updating the spec is unproductive
  206. # [12:47] <robburns> Lachy, rehashing this issues here in our WG is what it means to have a WG
  207. # [12:47] <robburns> That's what it means to submit a draft as the starting point for the WGs deliberations
  208. # [12:47] <Lachy> no, rehashing every issue wastes time
  209. # [12:48] <robburns> Presumably the only issues already hashed are the ones that made into the draft adopted by the WG. Issues not in the draft are pretty much unhashed issued by definition.
  210. # [12:48] <Lachy> no, that's incorrect
  211. # [12:48] <robburns> How is that incorrect?
  212. # [12:49] <Lachy> Prior to forming the HTMLWG, Hixie had about 5000 emails sitting in his queue, discussing hundreds of issues. Many of them have not yet made it into the spec
  213. # [12:49] <Lachy> I suspect that's now increased to about 8000 again, with all the HTMLWG discussion
  214. # [12:50] <robburns> Lachy, they haven't made it into the spec because they need hashing. Hixie or any WhatWG can cite those emails as we hash out the issues in the WG. Its not a rehashing its a convergence hashing
  215. # [12:50] <Lachy> no, they haven't made it into the spec because Hixie can't write the spec as fast as issues can be discussed, so the backlog builds up
  216. # [12:50] <robburns> Those our outside demands on Hixie's time. That's a conflict with his commitment to our WG, but its not a direct concern of the WG
  217. # [12:51] <Lachy> yes, we discussed doing exactly that in #whatwg a few hours ago
  218. # [12:51] <robburns> The backlogs only going to get bigger
  219. # [12:51] <Lachy> yes, they will, and as the spec becomes more and more stable and mature, it will start to get smaller and smaller
  220. # [12:52] * Quits: sbuluf (sgnbqyp@ (Ping timeout)
  221. # [12:52] <robburns> There's an infinity of material anyone could read on a topic. At some point, you have to start writing.
  222. # [12:52] <Lachy> what is that supposed to mean?
  223. # [12:52] <Lachy> Hixie is writing the spec. Yet, that appears to be what you're objecting to because simply because you're not personally aware of all prior discussions
  224. # [12:53] <robburns> On the issue of the backlog. If it only gets bigger, at some point you have to decide to write and publish and even make recommendations final even knowing there are emails that haven't been read
  225. # [12:54] <Lachy> wtf?
  226. # [12:54] <Lachy> the spec won't become a recommendation until all issues have been dealt with. It's part of the process
  227. # [12:54] <robburns> Its not that I'm not aware of prior discussions. Its that the current deliberative work of this WG is being ignored presumably because our editor has other commitments that are over-burdening him
  228. # [12:55] <Lachy> you're unrealistically expecting Hixie to drop everything from the whatwg and focus solely on the htmlwg. That's not going to happen
  229. # [12:55] <robburns> That's completely unrealistic. Sure all of the issues might be dealt with, but none of us will ever achieve a careful reading of every email, every thread, every IRC chat surrounding these issues.
  230. # [12:56] <Lachy> yeah, so?
  231. # [12:56] <robburns> I've already said those are personal issues. I don't know if it would require dropping everything from the WhatWG. Maybe it would only require dropping 25% of commitments to WhatWG
  232. # [12:56] <Lachy> can't you just accept that not every issue is going to be discussed in the HTMLWG before the spec is updated? You're still free to make comments on the draft as it's being updated.
  233. # [12:56] <robburns> No
  234. # [12:56] <Lachy> then that's you're problem, bye
  235. # [12:57] <robburns> That's how the draft should get edited from the issues discussed in the WG
  236. # [13:01] <robburns> Lachy:, on the issue of consensus, I haven't said we need to pursue formal consensus gathering procedures. which would be time consuming. However, the edits a WG editor makes should reflect a general interest of the WG as interpreted by the editor. That's not too time-consuming or cumbersome to ask.
  237. # [13:06] <hsivonen> robburns: the spec will be edited based on HTML WG discussions *eventually*. it will take months before we get to that stage
  238. # [13:07] <hsivonen> robburns: sometimes it has takes over a year for Hixie to address an issue I've raised. Please be more patient.
  239. # [13:08] <hsivonen> s/has takes/has taken/
  240. # [13:09] <robburns> hsivonen: I don't know how to interpret that. It still sound like there are foreign time commitment he needs to clear up that are getting in the way of his role as our WG editor
  241. # [13:10] <robburns> hsivonen: This would be a bit like DanC saying: "I'm going to hold a telecon meeting for the WG, but it will be in about 6 moths or so"
  242. # [13:11] <hsivonen> robburns: well, that's how it is. the commitment isn't foreign. it is to the HTML5 spec.
  243. # [13:12] <robburns> hsivonen: well by foreign I meant its a commitments to things other than the HTML WG
  244. # [13:14] <hsivonen> robburns: it shouldn't come as a surprise to anyone that the work queue was not empty when the HTML WG adopted the HTML 5 spec
  245. # [13:15] <robburns> hsivonen: The point is that it shouldn't be a queue. Once the WhatWG decided to bring the draft to the W3C for adoption the queue is not relevant anymore. Now its a an unordered collection that can be searched as issues are raised in our WG.
  246. # [13:16] <hsivonen> robburns: seems to me you are demanding priority service
  247. # [13:16] <gsnedders> robburns: his commitment is to the HTML WG's main deliverable. how is that not to this WG?
  248. # [13:18] <hsivonen> robburns: the thing is: you have to wait like everyone else. If you want your issues to make it into the queue at all, please make it clear what change to the spec you are suggesting and with pretty good rationale why
  249. # [13:18] <robburns> gsnedders: yes I am. I am demanding priority service for the HTML WG That is that the editor of the deliverable for the WG will prioritize the needs of the WG above his own. That is he will place a higher priority on the wishes of the WG and how they want the draft changed than his own wishes in seeing the draft change. That's what the editor for a WG does.
  250. # [13:20] <gsnedders> robburns: "above his own" — it's not his own needs. he is editor of many specs, across many WGs. he cannot give a single WG priority above all.
  251. # [13:20] <robburns> hsivonen: its not my issues I'm talking about. Its the WG issues. I don't really have any issues that I'm particularly interested in. I am concerned that the edits being made to the WGs draft reflect little of what has been discussed in the WG
  252. # [13:21] <hsivonen> robburns: it would be totally counterproductive for everyone who was also on the whatwg list to reaffirm their points just to demonstrate to you that addressing issues in the WHATWG backlog is addressing issues for the HTML WG
  253. # [13:22] <robburns> gsnedders: Then how can he serve as the editor for he WG? Obviously the members of this WG want the deliverables to mesh with deliverables of other WG. I'm sure that would reflect the interests of our members. So if Hixie thinks he needs to keep the HTML WG out of the loop to protect the draft for that reason, I think he's mistaken.
  254. # [13:22] <hsivonen> robburns: vigorously discussing stuff isn't the way to get induce spec change
  255. # [13:22] <gsnedders> robburns: he _isn't_ keeping the HTML WG out of the loop
  256. # [13:22] * Joins: edas (edaspet@
  257. # [13:22] <hsivonen> robburns: feel free to subscribe to svn commit messages to get in the loop
  258. # [13:23] <robburns> I'm not trying to unduce spec change. The draft will change. I'm not concerned about that. I'm concerned that the draft changes do not reflect the wishes of this WG. I'm concerned that the editor shows little interest in the wishes of this WG
  259. # [13:23] <gsnedders> robburns: they reflect the wishes of this WG based upon what we agreed to upon adopting this draft.
  260. # [13:24] <hsivonen> robburns: the wishes of the WG cannot be deduced from what the discussion looks on the list
  261. # [13:24] <gsnedders> "to preserve continuity with the existing WHATWG effort" — does that not mean continuing with existing issues?
  262. # [13:25] <robburns> gsnedders: The initial commit reflected the wishes of the WG when we adopted the draft. That's not the commit that concerns me. Its the edits since then.
  263. # [13:25] <robburns> hsivonen: I'm aware of the changes as they happen. That's not the issue I'm raising. I'm instead concerned that the changes do not reflect the wishes of this WG.
  264. # [13:25] <gsnedders> robburns: the initial commitment of the WG allowed edits to continue from the WHATWG effort.
  265. # [13:25] <hsivonen> robburns: your wishes != wishes of the WG
  266. # [13:25] <gsnedders> robburns: alas, it should be the chairs you should raise this with, and not us
  267. # [13:26] <robburns> hsivonen:if the wishes of the WG cannot be deduced from the discussion on the list, then someone should facilitate those discussions until they can deduce the wishes 9we also have the wiki and forms and telecons and f2f, etc)
  268. # [13:26] <robburns> gsnedders: I haven't said anything about restricting edits to the WhatWG draft (though I don't understand why we need a second one)
  269. # [13:27] <hsivonen> robburns: the wishes of the WG cannot be deduced from the discussions on the list, because the list gets a disproportionate amount of messages from you which makes the opinions of others get lost in the flood
  270. # [13:27] <robburns> gsnedders: I didn't raise this with you. This got raised with me
  271. # [13:27] <beowulf> robburns: the WHATWg draft isn't a second one, they're the same thing
  272. # [13:27] <gsnedders> robburns: I was meaning that we agreed to allow such edits to be made in the HTML WG draft.
  273. # [13:28] <robburns> beosulf: OK. let's call it an unordered set. I'm not interested in prioritizing those in some absolute way. I just want the editor of the HTML WG draft to be edited in accordance with the views of the HMTL WG
  274. # [13:29] <gsnedders> robburns: how many edits have gone against the views of the HTML WG?
  275. # [13:30] <robburns> gsnedders: I haven't done a count or even a thorough analysis. I just don't get the sense that any of the substantive edits reflect any of the discussions I've seen in this WG
  276. # [13:30] <robburns> hsivonen:: I never said my wishes = the wishes of the WG. Where did I say that?
  277. # [13:31] <robburns> hsivonen:: what I said was that the edits of the draft to not = the wishes of the WG
  278. # [13:31] <hsivonen> robburns: implied by your vigor of asserting that the wishes of the WG aren't getting addressed. there are a number of other WG members here, who don't have a problem with the recent edits
  279. # [13:31] <gsnedders> robburns: surely this is implied by what was agreed when the draft was adopted, though? We allowed the draft to be a continuation of the WHATWG's effort. That is my opinion allows issues raised previously to be dealt with
  280. # [13:32] <robburns> hsivonen:: well then we have a lack of consensus on whether those edits should happen. I guess we would have to move onto lower hanging fruit or escalate the process
  281. # [13:33] <gsnedders> robburns: no. we have consensus as long as "A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection."
  282. # [13:34] <robburns> gsnedders: Are you actually saying you interpret the adoptinon of the HTML 5 draft by this WG as an adoption of a dynamically changing draft?!? So that whatever changes the editor made we're approved by concensus in advance by this group as long as the changes were first made over at the WhatWG draft?!? Is that what you're saying?
  283. # [13:34] <gsnedders> robburns: yes, that is what I understood the proposal to be
  284. # [13:34] <robburns> gsnedders: I really don't think we want every edit to be governed by the most bureaucratic procedures available.
  285. # [13:34] <robburns> gsnedders: Wow!
  286. # [13:35] <hsivonen> robburns: it sure seems like you want more bureaucracy
  287. # [13:35] <gsnedders> robburns: that's what consensus in the subject of a W3C document means.
  288. # [13:35] <hsivonen> robburns: gsnedders is right
  289. # [13:35] <gsnedders> robburns: as far as I can, in every case, we have had consensus
  290. # [13:35] <gsnedders> *I can see
  291. # [13:36] <hsivonen> anyway, gotta go
  292. # [13:36] <gsnedders> hsivonen: bye
  293. # [13:36] <robburns> gsnedders: No that's not what consensus means. You're equating particular consensus escalating procedures with consensus and then claiming that the consensus is the bureaucratic procedure.
  294. # [13:37] <gsnedders> robburns: I'm not getting into an argument about the W3C Process. The Process document is very clear on this matter.
  295. # [13:37] <robburns> hsivonen: gsnedders is right about what?
  296. # [13:37] <hsivonen> robburns: that the WHATWG backlog is part of the package
  297. # [13:38] <robburns> gsnedders: you're misunderstanding the document
  298. # [13:39] <robburns> hsivonen:I think that backlog is a great part of the package. I think those familiar with the WhatWG archive should bring it up at every opportunity to help inform our WG
  299. # [13:39] <robburns> hsivonen: It will be an invaluable resource
  300. # [13:45] * Quits: Lionheart (robin@ (Connection reset by peer)
  301. # [13:50] <Lachy> the consensus before editing approach is not used for every issue, in any other WG I'm aware of.
  302. # [13:51] <Lachy> In other, more productive groups (including the ones in which I am an editor), the editor writes the draft, listens to feedback about the draft and then iteratively updates it to reflect that feedback
  303. # [13:57] <robburns> Lachy: Are you addressing those comments to hsivonen? Because I hadn't called fora consensus process before every edit. Though hsivonen claims that one occurred before the recent edits.
  304. # [13:58] <robburns> Lachy: to me that translates into WhatWG brought us a draft. The WG has worked diligently to review that draft and discuss new proposals: collectively the WGs feedback. Now edits are made that do not reflect that feedback. So you must share my concerns that the process here is not going per usual
  305. # [14:00] <Lachy> The fact that the HTMLWG hasn't discussed certain topics doesn't preclude those topics being updated in the draft
  306. # [14:02] <Lachy> BTW, you may not have noticed, but the draft did actually get updated to reflect some of the discussion about the alt attribute that occurred on the HTMLWG after the initial edits
  307. # [14:06] * Joins: Lionheart (robin@
  308. # [14:08] <Lachy> robburns, do you think it would be productive if every issue discussed in the HTMLWG had to be discussed in the WHATWG prior to editing? That would only be fair, right? Since it is as much their work, is it is the HTMLWG's. But how should we resolve the issue if the WHATWG disagrees with the HTMLWG?
  309. # [14:09] <Lachy> s/is it is/as it is/
  310. # [14:11] <hsivonen> robburns: I didn't claim the occurrence of a consensus process. please don't claim that I did. I did claim that there are people on this channel right now who do not seem to share your concerns. Hence, the whole WG doesn't have the concerns you have.
  311. # [14:11] <robburns> Lachy: No. I think the WhatWG decided to ask the W3C to convene a WG to potentially create a recommendation for HTML5. The document we adopted already reflect the work of WhatWG. But at that point it go turned over to this WG. That's not to say that WhatWG cannot go off on their own and do their own thing (including something called HTML5).. The only issue I'm raising is that I want the editor of our deliverable here in this WG to make edits that reflect
  312. # [14:12] * Quits: gavin_ (gavin@ (Ping timeout)
  313. # [14:13] <hsivonen> robburns: to the extent there's overlap between WHATWG contributors and HTML WG participants, concernes voiced in the backlog do reflect concerns of participants to the HTML WG
  314. # [14:13] <Lachy> if that's what the WG as a whole wants, then they won't be able to keep Hixie as the editor. That's not what he, and everyone else, agreed to when he was accepted as editor
  315. # [14:14] <robburns> hsivonen: sorry that was gnsedders who said: "robburns: as far as I can [see], in every case, we have had consensus"
  316. # [14:15] <robburns> hsivonen: that's fine. I didn't say to purge the views of WhatWG members from our group. I said that edits should reflect the feedback of this group. That's not what I'm seeing
  317. # [14:15] <robburns> Lachy: nothing I'm saying conflicts with anything Hixie has said he needs. At least nothing that I'm aware of.
  318. # [14:15] <hsivonen> robburns: I already said it'll take months before you start seeing edits based on public-html. that's expected. no one is entitled to priority service
  319. # [14:17] <Lachy> robburns, that's the point hsivonen is trying to make. Since there are members of the whatwg who are also members of the whatwg, the views of those people in the HTMLWG are being addressed. Unfortunately, in a group this size, you'll never get everyone to agree and not everyone's concerns can be addressed.
  320. # [14:17] * Joins: gavin_ (gavin@
  321. # [14:17] <robburns> hsivonen: That would be fine if we didn't see edits for months. Disappointing, but fine. The problem is we're seeing edits that do not reflect the feedback of the WG. That should happen at all. It shouldn't happen today. It shouldn't happen tomorrow. It shouldn't happen in two months. Either make edits that reflect the feedback of the WG or don't make edits.
  322. # [14:18] <Lachy> robburns, you're basically saying to ignore any feedback from outside the HTMLWG. That is unacceptable.
  323. # [14:18] <Lachy> by demanding that edits only reflect the views of the HTMLWG, and not those of anyone else
  324. # [14:19] <robburns> Lachy: I understand that we can't make a recommendation that is exactly as everyone wants it. That's not what a WG or any group is about. The point is that the edits our editor makes should reflect the feedback of the group. If there's insufficient feedback to make edits, then solicit more.
  325. # [14:19] <hsivonen> robburns: feedback from the HTML WG doesn't get in without scrutiny. the scrutiny will be months away. perhaps a couple of years away
  326. # [14:19] <Lachy> this conversation is going round in circles. I give up.
  327. # [14:19] <hsivonen> robburns: more != better
  328. # [14:19] <robburns> Lachy: no I'm not trying to ignore feedback from outside the group. However, that feedback should be filtered through the WG and then reflected in the edits of the editor to our draft deliverable
  329. # [14:20] <Lachy> in that case, I demand that the HTMLWG discussions also get filtered through the WHATWG
  330. # [14:20] <Lachy> then we'll see how productive things are
  331. # [14:20] <robburns> hsivonen: The scrutiny comes from the WG. Who else could possibly be in the position to scrutinize it.
  332. # [14:21] <Lachy> the editor!
  333. # [14:21] <robburns> Lachy: that could happen, but it would undermine our convergence efforts.
  334. # [14:21] <hsivonen> robburns: Hixie and hyatt
  335. # [14:21] <Lachy> exactly! That's what you're doing!
  336. # [14:23] <robburns> hsivonen: That's backwards. Hixie and Hyatt and DanC and Tim and Chris Wilson should certainly intervene and shape the work of the WG. But the process setup by the W3C calls for the WG to scrutinize the draft, not the leaders of the WG
  337. # [14:23] <robburns> s/Tim and/ null
  338. # [14:29] <hsivonen> robburns: the WG scrutinizes the draft. the Editors scrutinize change suggestions based on the merit of the suggestions.
  339. # [14:31] <Lachy> robburns, no, in a healthy and productive WG, the members don't demand that every issue be discussed prior to the editor making any changes. The WG should review changes to the draft and provide feedback. The editors then consider that feedback, make additional changes. That happens iteratively until issues are resolved.
  340. # [14:32] <robburns> hsivonen: fine. regardless of who scrutinizes whom or what, the work of a WG editor should be to make edits reflective of the WG's feedback
  341. # [14:32] <hsivonen> robburns: if the feedback is sensible, yes
  342. # [14:32] <Lachy> robburns, yes, that's what will happen, eventually
  343. # [14:32] <hsivonen> robburns: see "merit of the suggestions" above
  344. # [14:33] <Lachy> but sometimes edits occur before discussion, other times discussion occurs first
  345. # [14:33] <Lachy> there is no fixed order
  346. # [14:33] <hsivonen> robburns: this isn't about what feedback gets pushed the most
  347. # [14:33] <robburns> Lachy: You said tat earlier. To which I said that the WG adopted the HTML5 draft and began giving feedback. Now the edits are being made that do not reflect feedback of this WG. That's only going to bog down the process. If the edits made and the feedback given are diverging that's a problem.
  348. # [14:34] <robburns> hsivonen:: I don't know what you mean by "feedback gets pushed the most"
  349. # [14:35] <hsivonen> robburns: just because there is feedback doesn't mean that the feedback is sensible, so the feedback is weighed on merit--not on the appearance of popularity
  350. # [14:35] <Philip`> By "do not reflect feedback of this WG", do you mean the edits are in areas that have not been discussed by the WG, or that they are in areas that have been discussed but those discussions have been ignored?
  351. # [14:35] <Lachy> robburns, edits are being made in sections that haven't been discussed in the HTMLWG. Edits haven't been made that don't reflect the feedback of issues that have been discussed
  352. # [14:35] <hsivonen> anyway, this discussion is harming my productivity. I'm going to do other stuff now.
  353. # [14:36] * Lachy too
  354. # [14:36] <robburns> Philip: I would say the edits may regarding @alt recently are in stark contrast to the thrust of the conversation I've been following in this WG.
  355. # [14:37] <hsivonen> robburns: those who agree with the edits are just too tired to repeat themselves.
  356. # [14:38] <robburns> Philip: Its like some sort of tag team match :-). A few leave, but they're always replaced by more.
  357. # [14:38] * Joins: foca_ (foca@
  358. # [14:38] * Quits: foca_ (foca@ (Quit: foca_)
  359. # [14:39] <robburns> hsivonen: I'm not saying there are some who agree with the edits. However, there are many in the WG who clearly do not agree with the edits. Why would a WG editor make edits like that. Its not going to make the process any more productive. Its only going to bog things down.
  360. # [14:39] <robburns> s/are some/are none
  361. # [14:41] <Lachy> the feedback of those who disagree with the edits will be taken into account (some of it already has) and future edits will reflect that
  362. # [14:43] * Joins: tH_ (Rob@
  363. # [14:43] * tH_ is now known as tH
  364. # [14:43] <Philip`> A majority of the edits based solely on WHATWG feedback are completely uncontroversial, and it would be a waste of time re-discussing them in the HTML WG - I've only seen a small number where discussions flare up in the HTML WG after related edits
  365. # [14:45] <Philip`> I suppose Hixie could avoid doing any work related to accessibility at all, since that's what seems to always cause disagreement
  366. # [14:48] <jmb> I've yet to see one accessibility related "discussion" on the list where people aren't arguing past each other. I can't see how that's remotely productive
  367. # [14:51] <beowulf> I've found the accessibility related "discussions" to be very depressing in that respect
  368. # [14:52] <robburns> Philip: How can we produce a deliverable if our editor can't edit the accessibility related material. We simply need the editor to make edits that reflect the feedback of the WG, instead of edits that are just purely the editors whim. The editor is a member of the WG too and so is perfectly capable — in fact expect — to start debates, shape debates, and intervene in whatever ways necessary to gauge the pule of the WG
  369. # [14:53] <robburns> Philip and beowul: Perhaps the accessibility related stuff is going to end up being the most contentious. Perhaps we should leave those topics alone for now and focus on other areas. It may be that by focussing on other areas of the draft, we will find common ground and make it easier to connect over the accessibility issues later.
  370. # [14:53] <robburns> s/ /and jmb:
  371. # [14:54] <jmb> robburns: if you want the editor to spend his time posting emails to the list, then that's fine; the spec just won't get edited. There are only a fixed number of hours in a day, after all
  372. # [14:55] <robburns> jmb: this doesn't have to involve a lot of emails. A few strategically placed emails will be enough to spark and guide the debate whenever the editor wants it to go. I'm sure the WG members will respond as needed.
  373. # [14:56] <robburns> I must admit that, though I usually can see where others are coming from and penetrate past misunderstanding, I have a hard time understanding the WhatWG approach to accessibility
  374. # [14:59] <Lachy> what is so hard to understand about the "WhatWG approach to accessibility"?
  375. # [14:59] <Lachy> we all want features to be accessible, we just want to introduce features that are actually useful and will actually get used
  376. # [14:59] <jmb> I can't speak for the whatwg, as I'm not a member of it (and barely track their discussions). however, my own interpretation of what I've seen is that their "approach to accessibility" is to make things accessible by default, without extra effort on the part of document authors.
  377. # [15:00] <Lachy> jmb, yes. It's a bottom up approach
  378. # [15:00] <jmb> when you consider that most of the html documents on the web are comprised of junk markup, that seems eminently sensible to me
  379. # [15:00] <Lachy> make things accessible by default and only where that doesn't quite work, should be look at making them accessible with add-ons
  380. # [15:00] <jmb> Lachy: uhuh
  381. # [15:01] * beowulf nods
  382. # [15:01] <Lachy> that's why, in the headers debate, I and a few others, were trying to get people to focus on finding examples and helping to evaluate the success of the implicit approach.
  383. # [15:02] <Lachy> unfortuantely, the accessibility advocates were so caught up in arguing from the top down for the headers attribute, that the attempt wasn't very successful and that led to complete outrage from both sides
  384. # [15:02] <robburns> Well the ground up approach wasn't the part I have trouble understanding. That approach is very much a part of HTML itself, and the HTML5 draft certainly makes strives to extend that.
  385. # [15:03] <Lachy> then I don't understand your issue, rob
  386. # [15:04] <robburns> The part I have trouble with are the parts where certain accessibility only features are discouraged. These are features that authors can use today and work in only a few implementations. However, the one's they do work in work well. And the authors that use them are grateful those features are there (as are the users that depend on those features.). Things like TH@abbr and TABLE@summary for example.
  387. # [15:05] <robburns> Especially when these features do not even require special implementation concerns by mainstream browsers.
  388. # [15:06] <Philip`> It may be a problem that if we start with those features present, any questions about how to make accessible tables can be answered with "just use 'headers'" or "just use 'summary'"
  389. # [15:06] <Lachy> I'm not entirely convinced of the success of the summary and abbr attributes. I'd rather spend time looking for more successful alternatives, even if ultimately, both summary and abbr are included along side the improved approach
  390. # [15:06] <jmb> what would really help here is if someone could state clearly and concisely the exact problem those attributes attempt to solve
  391. # [15:06] <Philip`> whereas without them, we have to think about better ways to make tables accessible that don't require explicit effort from authors
  392. # [15:07] <Philip`> (and if it turns out that we can't think of ways to make everything work implicitly, the explicit mechanisms can be added back to fill in the gaps)
  393. # [15:07] <jmb> (and "making tables accessible" is rather too wooly a use case for my liking -- I want to know _why_ it makes them accessible ;)
  394. # [15:07] <Lachy> Philip`, right!
  395. # [15:07] <jmb> +l
  396. # [15:07] <robburns> Philip: yes, that's what I think should happen too.
  397. # [15:08] <Lachy> jmb, making tables accessible is the problem that needs to be addressed (the use case is publishing tabular data)
  398. # [15:08] <robburns> And while I can think of some UA side improvements to reduce the need for @abbr, its just doesn't strike me as one of those things we can avoid
  399. # [15:08] <hsivonen> robburns: it has not yet been shown that when headers='' is used, it is used more often correctly than incorrectly. If it turned out that it is used more often incorrectly, users of UAs would be better off on average if the UAs ignored the feature.
  400. # [15:08] <Lachy> but, yes, evaluating the success of the solutions is a vital step
  401. # [15:09] <robburns> hsivonen: I didn't mention @headerrs
  402. # [15:09] <hsivonen> though personally, I expect headers='' to make it into the spec eventually as a last resort override as well as backwards compat feature
  403. # [15:09] <robburns> I was talking about accessibility only features. @headers is more of an explicit semantic feature that has accessibility implications
  404. # [15:09] <hsivonen> robburns: it illustrates a part of WHATWG accessibility thinking
  405. # [15:10] <hsivonen> robburns: virtually no one cares about that semantic for reasons other than accessibility
  406. # [15:10] <robburns> hsivonen: I don't think we're that far apart on the @headers issue. Its the other issues that I'm confused about
  407. # [15:10] <Lachy> which other issues?
  408. # [15:11] <Lachy> (other than usemap)
  409. # [15:11] <robburns> TABLE@summary and TH@abbr
  410. # [15:12] <robburns> I think someone might come up with a brilliant replacement for those features., but I have a hard time thinking what else could be done.
  411. # [15:12] <jmb> Lachy: as it happens, in the case of those two attributes, the html4 spec is perfectly clear on the reason for their existence ;)
  412. # [15:12] <hsivonen> robburns: I would guess that when the part of the spec last was under work, the usefulness of those attributes was not clear
  413. # [15:12] <hsivonen> robburns: not in theory but as practiced on the Web
  414. # [15:13] <hsivonen> though I don't really know what the story with those two is
  415. # [15:13] <Lachy> I'm not sure how much discussion about summary and abbr has taken place, but something I'd like to see is some observation of tables that actually should have summaries provided, and see if and how they deal with it
  416. # [15:13] <robburns> hsivonen: Well I would say if those would not be contentious accessibility issues, it would really help this WG to build bridges to get them in the current draft.
  417. # [15:13] <Lachy> is it not somewhat typical in books, for example, for there to be an introductory paragraph before or after the table explaining what it represents?
  418. # [15:14] <Lachy> wouldn't such an introduction make the summary="" redundant?
  419. # [15:14] <Philip`> http://canvex.lazyilluminati.com/misc/summary.html is how some collection of pages uses summary
  420. # [15:15] <hsivonen> robburns: anyway, chances are that summary='' and abbr=' will be specced later if it is shown that their real-world usage improves accessibility compared to their absence
  421. # [15:15] <Lachy> cool. we should try and compare that with data tables that don't use summary as well
  422. # [15:15] <Philip`> It would be useful to find out from AT users what the cost of incorrect summary usage ("This table is for layout only" etc) is
  423. # [15:16] <Lachy> indeed. It might be useful to get Joshue to do some usability testing in that, unless someone can present previous studies on the issue
  424. # [15:17] <Philip`> because if it's a very small cost (e.g. they never ask for the summary to be read out unless they think it's going to be useful, or it only takes a second to read it out) then it is more likely to be outweighed by the benefits of the few correct usages
  425. # [15:19] <robburns> Lachy: yes, but the great benefit of tables and diagrams and the like is that they can convey enormous amounts of information in a very compact form. ( I guess a bit like a picture's worth a thousand words). The relations between the objects in tables can be gleaned quickly in a visual way. Those quick-glance relations are opaque to anyone just listening to the table. It would take enormous concentration for may many minutes or even hours just to glean
  426. # [15:22] <robburns> Lachy: that response was regarding your question of whether the text presented before and after a table would be the same as what's in the summary. Basically it shouldn't be. It is like @alt in that sense .If the surrounding prose describe the able adequately, then there's no reason for @summary.
  427. # [15:23] <Lachy> fair enough
  428. # [15:24] <robburns> However, if the table is dense enough (packing a lot of quick-glance information into a small area), then @summary would help aural browser users tremendously.
  429. # [15:25] <Lachy> yeah, but there's an existing practical problem that really needs to be addressed. Most authors don't provide summary attributes, let alone useful descriptions within them.
  430. # [15:26] <Philip`> Is there anything we can do to make people provide more information than they usually would?
  431. # [15:27] <Lachy> I just don't think most authors can comprehend the way in which bind users read tables, nor understand how to effectively describe it to them
  432. # [15:28] <Philip`> It seems the more practical approach is to make sure UAs can extract information that authors have already provided, by using implicit association so it works even when authors didn't bother putting that information in the right fields, but there's little we can do if people don't want to provide information at all
  433. # [15:28] <Lachy> if there was more educational material for summary, just like the abundance of educational material about alt="", that might help a little
  434. # [15:30] <Lachy> axis is the other attribute some people want included, but I haven't seen anyone clearly describe how or why to use it, nor how ATs can make use of it?
  435. # [15:30] <Lachy> Philip`, do you have stats on axis?
  436. # [15:31] <Lachy> it doesn't appear to show up in your resulst
  437. # [15:32] <hsivonen> before I started developing the table integrity checker, I did quite a bit of googling in order to find out about axis
  438. # [15:32] <robburns> Philip: That might work with HAL, but extracting this information is very difficult even for humans. Typically tables are geared at specialists in various fields. Hixie's comment about how hard it was to read some of those tables is a good example. The point is it doesn't matter much how hard some tables are to read. If you're someone interested in the US bureau of labor statistics, its beneficial to spend a day figuring out how to read those tables. Bec
  439. # [15:32] <hsivonen> there's a chance that JAWS does *something* with it, but there's no material explaining what
  440. # [15:32] <Lachy> http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/tagattr/td/axis and http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/tagattr/th/axis both show 0
  441. # [15:32] <Philip`> http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/attr/axis finds zero, which I think means it's <0.2% or so
  442. # [15:33] <Philip`> (I ought to redo this with more pages some time, to find some of the rarer things)
  443. # [15:33] <hsivonen> my understanding of axis is that it is a feature that isn't well designed to work with real situations and it was put out there in case UA vendors figure something out. which, for practical purposes, they haven't
  444. # [15:35] <robburns> @axis is more like @headers in that it is more about semantics but provides accessibility benefits. Its different form @headers in that @axis can actually provide important visual presentation information (and has to to work for anyone). That is an author can CSS select cells by @axis and give them distinct borders or backgrounds or foreground color.
  445. # [15:36] <robburns> Though some on the list have said @headers (or more broadly associated data and header cells as a pseudo element) should provide visual presentation too (whether with explicit or implicit association).
  446. # [15:36] <Philip`> robburns: Yep, I was just wondering about how Lachy wanted to address the problem that people don't provide summary attributes - if they have the description nearby then moving it into summary doesn't add much value, and if they don't have a description anywhere then we've lost already and can't do much about it
  447. # [15:36] <hsivonen> robburns: as a general rule, when "semantics" comes down to mere styling hooks for the author him/herself, it is rarely useful to spec anything beyond class
  448. # [15:37] <robburns> hsivonen: I have a very different opinion about that.
  449. # [15:37] <Philip`> (The problems are easier when people do actually want to provide a summary, because then we just need to provide a way to let them do it)
  450. # [15:38] <robburns> Philip: I'm not sure I understand what you're saying totally, but I would say @summary is more specialized than @alt.
  451. # [15:39] <robburns> hsivonen: Actually, I'm rethinking what you said, and there is a place where I think I agree with you.
  452. # [15:40] <Philip`> hsivonen: Most of HTML4 looks like a list of features for UA implementors to figure out what to do with :-)
  453. # [15:40] <hsivonen> Philip`: yeah, but axis is in a league of its own when it comes to detachment from implementation realism
  454. # [15:41] <robburns> hsivonen: I prefer to make the distinction between styling that's purely about style from styling that's about presenting semantics. Selecting what font to use is usually a pure styling issue. Changing it from serif to sans serif doesn't change the meaning of the document.
  455. # [15:42] <hsivonen> Philip`: I mean, where are all the tutorials explaining how axis is supposed to help people and to what extent actual software supports it? almost a decade after its inception
  456. # [15:42] <robburns> But when the difference in presentation reflects an underlying difference in semantics then those semantics are important (and in my view if they're not totally specialized for a certain very small group of authors deserve inclusion in HTML with its own NCName somewhere)
  457. # [15:43] <Philip`> We should just copy the spreadsheet parts of ODF or OOXML, because they're designed to handle all the complex tables that people actually need
  458. # [15:43] <hsivonen> robburns: they are only important if there exists non-trivial interest on behalf of others to consume your semantics without a prior bilateral agreement
  459. # [15:44] <robburns> hsivonen: agreed
  460. # [15:44] <Lachy> woah! robburns agreed with something???!!!
  461. # [15:44] <robburns> hsivonen @axis is one of those semantics.
  462. # [15:45] <robburns> Lachy: I agree with lots of things on the list, you guys just boycott my posts :-)
  463. # [15:45] <Lachy> that's because you object to everything without appearing to be listening
  464. # [15:46] <Lachy> anyway, let's not turn this into another argumetn
  465. # [15:46] <Philip`> Are there any two tools in the world that both support @axis semantics (preferably in a compatible way)?
  466. # [15:46] <robburns> Lachy: I guess you didn't see all the strongly agrees in my questionairre responses responses (though i may end up with the infamy of having the only strongly disagree response
  467. # [15:46] <hsivonen> Philip`: I didn't find such a pair last year
  468. # [15:47] <robburns> Philip: @axis semantics support with a visual browser only requires CSS attribute value selectors
  469. # [15:47] <robburns> Philip: Or were you talking about aural or some other kind of tools
  470. # [15:48] <robburns> ?
  471. # [15:48] <Lachy> robburns, if axis is oinly ever useful for styling, then there's really no benefit using axis="foo" over class="foo", especially when the latter doesn't require any further education
  472. # [15:49] <Philip`> robburns: I was thinking of things that actually use the semantics of the attribute, rather than just using the fact that it's a (name, value) pair of strings
  473. # [15:50] <robburns> Lachy: except its styling of semantics that are important because "there exists non-trivial interest on behalf of others to consume your semantics without a prior bilateral agreement" (hsivonen)
  474. # [15:51] <Lachy> I'm not sure I've seen any evidence for such non-trivial interest
  475. # [15:53] <robburns> Philip: most of what visual browsers do is provide styling of semantics For example, most elements just need to have their default, user or author stylesheet s applied to them and then the browsers job is done (that's true of STRONG, EM, P, BLOCKQUOTE, etc), Sure there's also DOM hooks and other ways to access these elements, but no specialized semantic interpretation: and typically none required by users or authors. Same is true for @axis.
  476. # [15:53] <Philip`> Can CSS work on axis attributes that have more than one (comma-separated) value?
  477. # [15:54] <robburns> Philip: I thought CSS3 selectors had that.
  478. # [15:54] <robburns> Philip: without that authors would be limited to cells participating in only one axis. But that would cover many of the tables I've ever seen.
  479. # [15:54] <Philip`> It only seems to support space-separated lists, as far as I can tell
  480. # [15:55] <robburns> Philip: well I think tables are a bit of a CSS mess personally. But like I said, most authors just need one axis per cell. Multiple would be more flexible however.
  481. # [15:56] <Philip`> http://www.w3.org/TR/html4/struct/tables.html#multi-dimension is presumably why HTML4 included the advanced table stuff - does any tool support anything vaguely like that?
  482. # [15:57] <robburns> Phlip: Emacspeak maybe. I don't know
  483. # [15:57] <Philip`> I guess nowadays people would want to use something like RDF for processing information in that way
  484. # [15:57] <Philip`> (though I know almost nothing about RDF so maybe that's wrong)
  485. # [15:58] * Philip` tried to get Emacspeak working on Gentoo once, but it seems to only work with Emacs while the web browser (w3m?) only works with XEmacs, so he didn't get very far :-(
  486. # [15:59] <robburns> Philip: yeah, I don't know either. Its good at expressing relations, but its hard for me to imagine building a table with it.
  487. # [15:59] <robburns> Philip: yeah, I don't know how to use it myself. It seems every aural browser user I know uses a different tool And they all seem wildly uneven in the features they support.
  488. # [16:00] <robburns> s/suarl browser/aural UA (including screen readers)
  489. # [16:02] * Joins: schepers (schepers@
  490. # [16:02] <Philip`> Much easier on the desktop since you only have to care about IE and Firefox, and if you're feeling nice you can humour Safari and Opera too :-)
  491. # [16:19] * Quits: gavin_ (gavin@ (Ping timeout)
  492. # [16:24] * Joins: gavin_ (gavin@
  493. # [16:31] * Quits: edas (edaspet@ (Quit: http://eric.daspet.name/ - du nouveau sur http://www.paris-web.fr/ ce mois ci, inscrivez vous au RSS)
  494. # [16:57] * Quits: robburns (robburns@ (Quit: robburns)
  495. # [17:11] * Joins: robburns (robburns@
  496. # [17:40] * Joins: myakura (myakura@
  497. # [17:49] * Joins: dbaron (dbaron@
  498. # [17:49] * Joins: hendry (hendry@
  499. # [18:17] * Joins: polin8 (polin8@
  500. # [18:22] * Quits: Chris (cwilso@ (Quit: Chris)
  501. # [18:27] * Quits: gavin_ (gavin@ (Ping timeout)
  502. # [18:32] * Joins: gavin_ (gavin@
  503. # [18:40] * Quits: polin8 (polin8@ (Quit: polin8)
  504. # [18:47] * Quits: myakura (myakura@ (Quit: Leaving...)
  505. # [18:53] * Quits: hendry (hendry@ (Quit: leaving)
  506. # [19:24] * Joins: Roger (roger@
  507. # [19:30] * Quits: robburns (robburns@ (Quit: robburns)
  508. # [19:32] * Quits: beowulf (beowulf@ (Client exited)
  509. # [19:33] * Quits: tH (Rob@ (Connection reset by peer)
  510. # [19:34] * Joins: tH_ (Rob@
  511. # [19:34] * tH_ is now known as tH
  512. # [19:44] * Quits: ROBOd (robod@ (Client exited)
  513. # [19:45] * Quits: dbaron (dbaron@ (Quit: 8403864 bytes have been tenured, next gc will be global.)
  514. # [19:48] * Quits: Roger (roger@ (Quit: Roger)
  515. # [19:59] * Joins: mjs (mjs@
  516. # [20:09] * Joins: takkaria (takkaria@
  517. # [20:15] * Joins: jonbarnett (jbarnett@
  518. # [20:17] * Joins: xover (xover@
  519. # [20:32] <Philip`> http://www.w3.org/MarkUp/2007/ED-xhtml-role-20070703/ appears to be a more recent version of the Role Attribute specification than was mentioned before
  520. # [20:33] <gsnedders> Philip`: the other was a WD, was it not?
  521. # [20:34] * Quits: gavin_ (gavin@ (Ping timeout)
  522. # [20:37] <Philip`> http://www.w3.org/TR/2006/WD-xhtml-role-20061113/ is
  523. # [20:37] <Philip`> The orangey backgrounds in the ED look a bit ugly :-(
  524. # [20:39] * Joins: gavin_ (gavin@
  525. # [20:52] * Joins: Roger (roger@
  526. # [21:09] * Quits: Roger (roger@ (Quit: Roger)
  527. # [21:51] * Quits: takkaria (takkaria@ (Ping timeout)
  528. # [21:53] * Joins: takkaria (takkaria@
  529. # [21:54] * Quits: takkaria (takkaria@ (Client exited)
  530. # [22:10] * Quits: schepers (schepers@ (Quit: Trillian (http://www.ceruleanstudios.com)
  531. # [22:26] * Joins: schepers (schepers@
  532. # [22:26] * Joins: kingryan (rking3@
  533. # [22:27] * Quits: kingryan (rking3@ (Quit: kingryan)
  534. # [22:27] * Joins: kingryan (rking3@
  535. # [22:41] * Quits: gavin_ (gavin@ (Ping timeout)
  536. # [22:46] * Joins: hyatt (hyatt@
  537. # [22:46] * Joins: gavin_ (gavin@
  538. # [22:50] <gsnedders> DanC: there were no proper test cases behind that email. just copy and pasted the example from the RSS 1.0 spec, and deleted namespaces
  539. # [22:51] <gsnedders> DanC: I'm about to start writing proper test cases for the entire section, though
  540. # [22:52] <DanC> the test case I had in mind is one where the HTTP spec would give a content type of text/plain but the HTML5 rules give application/rss+xml
  541. # [22:53] <DanC> rock on, re proper test cases.
  542. # [22:53] <kingryan> DanC: I'm working on some test cases too
  543. # [22:53] <kingryan> (and we've been talking about this over in #whatwg, too)
  544. # [22:53] <DanC> in the same area?
  545. # [22:53] <kingryan> yes
  546. # [22:53] <kingryan> content-type sniffing for feeds, in particular, for me
  547. # [22:54] <DanC> you're more than welcome to use http://esw.w3.org/topic/HtmlTestMaterials to coordinate
  548. # [22:54] <DanC> the OpeningStatement is "HTMLAsSheAreSpoke is kinda messy; a big pile of tests will be at least as valuable as a spec for interoperability."
  549. # [22:55] <kingryan> I'll likely end up putting the tests in the html5lib svn repository
  550. # [22:56] <DanC> which, oddly, doesn't seem to be linked from HtmlTestMaterials
  551. # [22:56] <kingryan> given that we already have a number of tests there, I think its a good place to collect them
  552. # [22:56] <DanC> a pointer from Anne has gone 404; http://html5lib.googlecode.com/svn/trunk/tests/tokenizer/ <- http://lists.w3.org/Archives/Public/public-html/2007JanMar/0053.html
  553. # [22:57] <kingryan> http://html5lib.googlecode.com/svn/trunk/testdata/tokenizer/
  554. # [22:57] * DanC finds http://html5lib.googlecode.com/svn/trunk/testdata/
  555. # [22:57] <kingryan> fwiw, both the python and ruby implementations there pass all of those tests
  556. # [22:57] * DanC wishes the messy copyright issues would just go away
  557. # [22:58] <kingryan> and I think other projects, like gsnedders' php implementation use those tests
  558. # [22:58] <gsnedders> kingryan: no, I don't even have a tokeniser yet :)
  559. # [22:58] <Philip`> The Java parser and C++/JS/Perl tokeniser use the html5lib tests too
  560. # [22:58] <DanC> I'd like to take some chunk of tests and the corresponding part of the spec and propose formally that the WG approve them. that would be our 1st design decision.
  561. # [22:59] <Philip`> (At least with the tokeniser tests, the Java and C++ ones pass them all too)
  562. # [22:59] <DanC> is anybody working on tests for charset detection? that's one logical place to start: at the lowest level of bytes
  563. # [22:59] <gsnedders> DanC: http://html5lib.googlecode.com/svn/trunk/testdata/encoding/?
  564. # [23:00] <DanC> duh.
  565. # [23:00] <DanC> is there a description of the materials somewhere?
  566. # [23:01] <kingryan> DanC: not really
  567. # [23:01] <kingryan> maybe on the html5lib wiki
  568. # [23:01] <DanC> UTSL mostly works
  569. # [23:01] <Philip`> Hmm, the wiki's full of spam :-(
  570. # [23:02] <DanC> runtests.sh ...
  571. # [23:02] <Philip`> http://wiki.whatwg.org/wiki/Parser_tests kind of describes some of the test formats, incorrectly
  572. # [23:02] * DanC hears "it's full of stars" from 2001
  573. # [23:02] <gsnedders> Philip`: is was once correct, was it not?
  574. # [23:03] <DanC> is the "IE will in some cases parse to a lattice not a tree" issue captured in html5lib's tests?
  575. # [23:03] <Philip`> gsnedders: Maybe, but at least with tokeniser tests it's missing details about the content model flag and the other thingy and unimportant-error-order
  576. # [23:03] * Philip` will try to fix that now, if he can work out whether he's already registered on the wiki
  577. # [23:04] <DanC> I think I should start with a design decision that Microsoft can easily agree to, but I want to get to that lattice/tree issue/requirement before long.
  578. # [23:04] <Philip`> DanC: Some of the tests will be (unintentionally) causing that, because IE makes non-tree DOMs very frequently
  579. # [23:05] <DanC> for example?
  580. # [23:05] * Philip` tries to find a particular example in the tests...
  581. # [23:05] <DanC> (I have an example of markup; what I want is an example filename in the tests)
  582. # [23:06] <Philip`> <a><p>X<a>Y</a>Z</p></a>
  583. # [23:06] <DanC> hmm... minutes from yesterday... they haven't been cleaned up and sent out, have they?
  584. # [23:06] <Philip`> in tree-construction/tests1.dat
  585. # [23:06] <DanC> thanks
  586. # [23:06] <gsnedders> DanC: no, they haven't
  587. # [23:07] <gsnedders> who was doing them?
  588. # [23:07] <Philip`> <a X>0<b>1<a Y>2
  589. # [23:07] <Philip`> is probably a better example
  590. # [23:07] <Philip`> (still in tests1.dat)
  591. # [23:08] <Philip`> since HTML5 parsers have to clone some elements in that case, where IE just uses one element with two parents
  592. # [23:08] <DanC> Lachy took minutes, but I didn't make sure he knew about clean-up and announcement. I'll do it now, I guess.
  593. # [23:08] <Philip`> s/where/whereas/
  594. # [23:09] * DanC wonders if anybody has peeked at http://dev.w3.org/cvsweb/~checkout~/html5/cts/html5-type-sniffing.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1
  595. # [23:09] <Hixie> DanC: i sent comments to the list
  596. # [23:10] <DanC> cool
  597. # [23:11] * DanC chuckles @ application/xml; damnit
  598. # [23:11] <gsnedders> DanC: I have
  599. # [23:12] <gsnedders> DanC: only peeked, though
  600. # [23:13] <kingryan> DanC: is that simply an extraction from the current draft?
  601. # [23:14] <DanC> yes. (see Makefile for details)
  602. # [23:14] <kingryan> why extract it?
  603. # [23:14] <DanC> cuz the IETF can only read plain ASCII
  604. # [23:15] * kingryan doesn't know why the IETF is relevant here
  605. # [23:15] <DanC> the HTTP spec is an IETF spec
  606. # [23:15] <DanC> and the MIME specs
  607. # [23:16] <Hixie> kingryan: we want feedback from as many people as possible
  608. # [23:17] <kingryan> ok
  609. # [23:18] <kingryan> fwiw, I'll likely have part of the sniffing algorithm done in html5lib this weekend
  610. # [23:18] * Philip` likes that the HTML version is (almost) valid HTML5
  611. # [23:19] <DanC> not to mention well-formed XML :)
  612. # [23:19] * Quits: jonbarnett (jbarnett@ (Client exited)
  613. # [23:19] <DanC> go, kingryan , go
  614. # [23:47] * DanC commits http://www.w3.org/2007/08/16-html-wg-minutes 1.2
  615. # [23:49] <gsnedders> I'm sure some things are wrong attributed, but maybe my memory is wrong
  616. # [23:50] <DanC> it seems ok to me
  617. # [23:50] * DanC takes a look at http://www.w3.org/2002/09/wbs/40318/dprv/results ... 44 so far
  618. # [23:50] <DanC> btw... Hixie I think I addressed your comment: Where are "Pave the Cowpaths", "Universal Access", "Separation of Concerns"? They are all critically important (especially Universal Access).
  619. # [23:51] <DanC> hmm... one Disagree, but it doesn't have an explicit change proposal. -1 for the Likert scale.
  620. # [23:51] <DanC> another Disagree that says "it depends"
  621. # [23:52] * Philip` updates http://wiki.whatwg.org/wiki/Parser_tests#Tokenizer_Tests to be hopefully correct
  622. # [23:53] <DanC> hmm... various people express concerns; few suggest text changes. given large numbers of agree/strongly agree, it seems clear that the burden is on those with concerns to suggest text that would address them.
  623. # [23:53] <DanC> wild... even Hixie says "Recommend that this be completely restated." without saying how.
  624. # [23:56] <DanC> hmm... "No one joins a WG and volunteers their time to solve fantasy problems. " I think I'm guilty of doing that in a few cases.
  625. # [23:57] <Philip`> "as written it [Support Existing Content] implies support for HTML 1.0 as well" - HTML5 even has support for features that were considered obsolete in HTML 1.0
  626. # Session Close: Sat Aug 18 00:00:01 2007

The end :)