/irc-logs / w3c / #html-wg / 2009-03-16 / end

Options:

  1. # Session Start: Mon Mar 16 00:00:00 2009
  2. # Session Ident: #html-wg
  3. # [00:51] * Disconnected
  4. # [00:51] * Attempting to rejoin channel #html-wg
  5. # [00:51] * Rejoined channel #html-wg
  6. # [00:51] * Topic is 'HTML WG 12 Mar http://lists.w3.org/Archives/Public/public-html-wg-announce/2009JanMar/0041.html (This channel is logged: http://krijnhoetmer.nl/irc-logs/ )'
  7. # [00:51] * Set by DanC on Thu Mar 12 17:00:49
  8. # [00:54] * Quits: xover (xover@193.157.66.22) (Quit: Leaving)
  9. # [01:04] * Joins: xover (xover@193.157.66.22)
  10. # [01:16] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  11. # [01:21] * Joins: gavin_ (gavin@99.226.207.11)
  12. # [01:56] * Quits: karl (karlcow@128.30.54.58) (Ping timeout)
  13. # [02:01] * Quits: maddiin (mc@87.185.217.112) (Quit: maddiin)
  14. # [02:06] * Quits: annevk (opera@77.163.243.203) (Ping timeout)
  15. # [02:11] * Joins: karl (karlcow@128.30.54.58)
  16. # [02:22] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  17. # [02:24] * Quits: karl (karlcow@128.30.54.58) (Client exited)
  18. # [02:53] * Joins: dbaron (dbaron@216.132.92.66)
  19. # [03:02] * Joins: karl (karlcow@128.30.54.58)
  20. # [03:05] * Quits: dbaron (dbaron@216.132.92.66) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  21. # [03:16] * Joins: DanC (connolly@128.30.52.30)
  22. # [03:26] * Quits: tH (Rob@129.11.83.14) (Quit: ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.1/2008072406])
  23. # [03:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  24. # [04:30] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  25. # [04:47] * Joins: karl (karlcow@128.30.54.58)
  26. # [05:18] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  27. # [05:22] * Parts: heycam (cam@124.168.80.126) (bye)
  28. # [05:22] * Joins: heycam (cam@124.168.80.126)
  29. # [07:28] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  30. # [07:34] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  31. # [08:35] * Joins: Zeros (Zeros-Elip@68.50.195.181)
  32. # [09:29] * Quits: Zeros (Zeros-Elip@68.50.195.181) (Quit: Leaving)
  33. # [10:02] * Quits: Lachy (Lachlan@85.196.122.246) (Connection reset by peer)
  34. # [10:02] * Joins: Lachy (Lachlan@85.196.122.246)
  35. # [10:18] <krijnh> Test
  36. # [10:24] <Philip> Tests passed: 1/1 (100%)
  37. # [10:25] * Joins: rubys (rubys@75.182.92.38)
  38. # [10:30] * MikeSmith wrapping up a day attending a semantic web event in Tokyo
  39. # [10:33] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  40. # [10:35] <jgraham> I hate wrapping up days, the corners are so fiddly do neatly
  41. # [10:40] <Philip> Web 2.0 days are much harder, since they have rounded corners and you have to kind of scrunch up the paper to make it fit
  42. # [10:54] * Joins: ROBOd (robod@89.122.216.38)
  43. # [11:10] <rubys> hsivonen: ping?
  44. # [11:10] <hsivonen> pong
  45. # [11:11] <rubys> I responded to your comment on my blog. As to the email you just sent me, are you ok with me copying www-archive on the reply?
  46. # [11:13] <hsivonen> rubys: for the first paragraph, yes. For the second, I sent it in private email because I referred to Member archives
  47. # [11:14] * rubys wishes that the W3C would get "openness"
  48. # [11:22] <jgraham> rubys: At the 2007 TPAC there were a number of voices saying things that amount to "if the W3C is open then why would we bother paying our membership fees?". So I think W3C percieves closedness as being in its best interests
  49. # [11:23] <hsivonen> interestingly, if the W3C becomes more open, the main value proposition would be protection against inter-Member patent litigation
  50. # [11:27] <jgraham> hsivonen: Really? I don't remember the details of the patent policy but I don't recall a reason that Members would do better out of it than anyone else
  51. # [11:28] <hsivonen> jgraham: parties who don't contribute to the W3C aren't bound by the patent policy
  52. # [11:28] <hsivonen> jgraham: so the policy only protects against patent aggression from parties that do contribute to the W3C
  53. # [11:28] <jgraham> hsivonen: Sure
  54. # [11:29] <hsivonen> jgraham: so it seems to me that the patent policy value to a member is protection against other members--not protection against everyone
  55. # [11:29] <jgraham> hsivonen: So how would you structure things so that everything was open but companies still had to pay a fee?
  56. # [11:29] * Joins: maddiin (mc@87.185.223.36)
  57. # [11:30] <rubys> jgraham: I can generally cite a "number of voices" which support *ANY* conclusion. (1) unless you have names, it doesn't mean anything to me, and (2) beyond that, don't jump to conclusions.
  58. # [11:30] <Philip> jgraham: Rely on Paypal donations from individual supporters
  59. # [11:30] <rubys> I never paid a dime or traveled when I worked on Atom at the IETF
  60. # [11:31] <hsivonen> rubys: did Tim Bray have to travel to an initial F2F BOF, though?
  61. # [11:31] <rubys> I don't believe so, but I could be wrong.
  62. # [11:31] <Philip> Advertise with "Your donation of $10 will support our DTD servers for a day", etc
  63. # [11:31] <rubys> Paul Hoffman certainly did.
  64. # [11:32] <hsivonen> jgraham: I suppose the structure would be roughly a public mailing list server and spec HTTP server and fees for lawyers who look after the patent policy
  65. # [11:32] <hsivonen> jgraham: where does the Open Web Foundation get their lawyer money?
  66. # [11:32] <jgraham> rubys: 1) It was two years ago, and I doubt I knew names at the time anyway. But it did come up more than once. 2) I'm not sure I'm jumping to conclusions. If I presented the hypothesis as fact then I apologise, it was unintentional
  67. # [11:33] <hsivonen> jgraham, rubys: the openness panel at TPAC 2007 was not confidential and was minuted
  68. # [11:33] * hsivonen tries to find the minutes
  69. # [11:34] <hsivonen> http://media.w3.org/2007/11/w3c_tpac_session5.oga
  70. # [11:34] <jgraham> Philip: Would the W3C get comedians to do a biannual TV telathon in support of W3C?
  71. # [11:34] <hsivonen> http://esw.w3.org/topic/TPAC2007Session5
  72. # [11:34] <pimpbot> Title: TPAC2007Session5 - ESW Wiki (at esw.w3.org)
  73. # [11:36] <Philip> jgraham: That would be an excellent
  74. # [11:37] <Philip> jgraham: We could send TBL on a sponsored mountain climb
  75. # [11:37] <Philip> s/excellent/excellent idea/
  76. # [11:39] <jgraham> "Just $5 of your money buys a staff contact a burrito lunch at a face to face meeting"
  77. # [11:40] <hsivonen> I wonder if the transcript is all there was to the openness panel
  78. # [11:40] <hsivonen> I don't have the time to listen to the audio file now
  79. # [11:41] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  80. # [11:46] <rubys> http://lists.w3.org/Archives/Public/www-archive/2009Mar/0058.html
  81. # [11:46] <pimpbot> Title: Re: On merging XHTML2 WG and the HTML WG from Sam Ruby on 2009-03-16 (www-archive@w3.org from March 2009) (at lists.w3.org)
  82. # [11:48] * Joins: tH (Rob@129.11.83.14)
  83. # [11:50] <hsivonen> rubys: thanks for your replies, both on the blog and in email
  84. # [11:51] <rubys> I very much want to push the envelope in terms of radical transparency. What I published in "HTML5 Evolution", "Wii Fit Update", and "Interesting Times" are all examples of this.
  85. # [11:53] * Joins: tlr (tlr@128.30.52.30)
  86. # [11:55] <jgraham> rubys: That sounds good. What about openness?
  87. # [11:56] <rubys> jgraham, I don't understand the question.
  88. # [11:56] <jgraham> Well maybe I don't understand the statement
  89. # [11:57] <rubys> which statement?
  90. # [11:57] * Joins: annevk (opera@77.163.243.203)
  91. # [11:58] <jgraham> When you say you want to "push the envelope in terms of radical transparency" do you mean for you personally or in some broader context e.g. W3C
  92. # [11:58] <rubys> yes, to both.
  93. # [11:58] * Joins: Lachy (Lachlan@213.236.208.22)
  94. # [11:59] <jgraham> Right, so in the broader context, the difference between transparency and openness is the difference between being able to see what is happening and being able to affect it
  95. # [12:00] <rubys> ah, like the relationship we all have with Ian? (caption for the humor impaired: it's a JOKE!)
  96. # [12:01] * rubys notes that jgraham did not ask a question
  97. # [12:03] <jgraham> So the question is the original one. Are you mainly interested in making it easier to see what is going on ("cleaning the windows") or in making it possible for outsiders to affect what is going on ("opening the door")?
  98. # [12:03] <jgraham> I guess s/mainly/just/ and /or in/or also in/
  99. # [12:03] <rubys> +1 to also
  100. # [12:04] <rubys> biggest concerns are non-constructive "contributions"
  101. # [12:04] <rubys> I want the spec to be under the W3C license, and people who are serious about wanting to contribute to do so by contributing tangible spec text.
  102. # [12:05] <rubys> Many people around here (notably, the W3C and Ian) are uncomfortable with one or the ohter.
  103. # [12:05] <rubys> s/ohter/other/
  104. # [12:05] <rubys> s/W3C license/MIT license/
  105. # [12:05] <jgraham> rubys: Can you end up with a coherent spec written by a mishmash of people
  106. # [12:05] <rubys> gah.
  107. # [12:05] <jgraham> rubys: That makes more sense :)
  108. # [12:06] * jgraham is not saying you can't
  109. # [12:06] <rubys> jgraham: editors don't simply copy/paste. They actually edit.
  110. # [12:06] <rubys> Is the Atom spec coherent? MNot and RSayer were the editors.
  111. # [12:06] <rubys> People actually contributed actual spec text.
  112. # [12:07] <jgraham> Right, so the model would be that people write what they want in the spec as text and then the editors work it in to the text?
  113. # [12:07] <jgraham> make that last "text" "overall document"
  114. # [12:07] <rubys> yes. It is amazing what happens when you tell somebody who has an abstract and unworkable idea that they are pushing to make a coherent and workable proposal.
  115. # [12:08] * jgraham doesn't quite understand that last sentnence
  116. # [12:09] <jgraham> You mean when you tell them they have to make a coherent and workable proposal?
  117. # [12:09] <rubys> yes
  118. # [12:09] <jgraham> That sounds good, but it is unclear that it would solve some of the biggest problems that we have had with HTML
  119. # [12:10] <jgraham> For example any number of people would be happy to write mutually contradictory spec text about @alt or @summary
  120. # [12:10] <rubys> that statement sounds like it came straight from hixie's bible...
  121. # [12:10] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  122. # [12:10] <jgraham> The one case where I remember something similar happening (because I was involved) was the table headers stuff
  123. # [12:11] <jgraham> which did work quite well
  124. # [12:11] <annevk> I thought the current idea of proposing new functionality already asks for a coherent proposal...
  125. # [12:12] <rubys> no, it asks for use cases.
  126. # [12:15] * rubys is heading off to exercise... back in a bit
  127. # [12:15] <annevk> not just use cases: http://blog.whatwg.org/proposing-features
  128. # [12:16] <pimpbot> Title: The WHATWG Blog » Blog Archive » Proposing features (at blog.whatwg.org)
  129. # [12:16] <annevk> (people generally not get past use cases, but that's not all there is to it...)
  130. # [12:18] <rubys> My observations as to how the WHATWG operates and what is expressed on that page do not match.
  131. # [12:19] <jgraham> rubys: I'm not sure what I am supposed to take from the comparison to Hixie's Bible (presumably you mean the handling people page)
  132. # [12:20] <annevk> guess our experiences differ then
  133. # [12:20] <rubys> jgraham: it wasn't flattering :-). "...but it is unclear..." is often a great way to derail a discussion.
  134. # [12:20] <jgraham> rubys: I realise it wasn't flattering :)
  135. # [12:21] <jgraham> Shall I rephrase
  136. # [12:21] <rubys> annevk: concrete example: RDFa. I'm not a fan of RDF in any form, but when they tried to propose a concrete proposal, they were clearly and unambiguously told not to.
  137. # [12:21] <rubys> jgraham: not necessary.
  138. # [12:22] <rubys> annevk: but I will accept "our experiences differ"
  139. # [12:22] <jgraham> Do you think this will help with the most obvious problems that the public-html list has been having (those that have generated the largest volume of email e.g. @alt, @summary) or is this designed to deal with some other set of problems?
  140. # [12:22] <annevk> I thought they got stuck on "» What is the problem you are trying to solve?" initially but that it improved afterwards
  141. # [12:22] <annevk> I wasn't aware that RDFa was completely rejected. AFAIK it was still under consideration
  142. # [12:23] <annevk> Didn't Hixie say it was scheduled for April?
  143. # [12:23] <rubys> jgraham: "most obvious problems", yes. "alt", perhaps not.
  144. # [12:24] <rubys> annevk: lets just say that those who are pushing RDFa tend to be a bit cynical about what Hixie means by his schedule, and I can definitely see how they have come to feel that way.
  145. # [12:24] * jgraham notes he said "the most obvious problems" which is slghtly different to "most obvious problems"
  146. # [12:25] <rubys> I don't think alt is the biggest problem; and concrete proposals aren't sufficient to tackle that particular one.
  147. # [12:26] <annevk> rubys, I think that might go for most controversial suggestions, e.g. />
  148. # [12:26] <rubys> <cynic> Bah, /> is not controversial. It is only brought up when one wants to portray Ian as being open </cynic>
  149. # [12:27] <annevk> well, I thought it was controversial anyway :)
  150. # [12:28] <rubys> alt and /> both have a lot in common. From a consumer perspective, alt is completely optional, and /> on empty elements cause absolutely no problem. The only controversy comes in to play is when people get religious and wish to push their own ideas of morality onto other people.
  151. # [12:30] <rubys> now I am really leaving for a bit. I mean it this time.
  152. # [12:42] <Philip> When I've emailed specific spec text for changes to existing sections, Hixie has usually said to not do that because it makes his job much harder, because it's hard to work out what the intended diff was and to merge it with any other people's suggested changes over the same time period
  153. # [12:43] <Philip> But I think I often find it personally useful to try writing spec-like text anyway, because it makes me think about my suggestions in a way that often reveals problems
  154. # [12:44] * jgraham has the same experience documenting the Smart Headers algorithm
  155. # [12:49] <Philip> http://lists.w3.org/Archives/Public/public-html/2008Jun/0186.html
  156. # [12:49] <pimpbot> Title: Re: Canvas shadows should not be optional from Ian Hickson on 2008-06-12 (public-html@w3.org from June 2008) (at lists.w3.org)
  157. # [12:52] <Philip> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-January/013821.html (last paragraph)
  158. # [12:52] <pimpbot> Title: [whatwg] Canvas arcTo (at lists.whatwg.org)
  159. # [12:52] <Philip> "I recommend against suggesting replacement text as I mostly ignore it anyway (if I pay attention to it, I tend to forget to do a thorough job -- for example, in this particular case I would have missed the corresponding changes to the Drawing Model section)."
  160. # [12:52] <Philip> "it's actually easier for me to end up rewriting the text in response to feedback, than it is for me to handle suggested replacement text. One major reason for this is that if the text has been changed in response to other feedback, I risk losing those changes if I just replace it."
  161. # [13:05] * Joins: jre (chatzilla@217.91.35.233)
  162. # [13:06] * jre is now known as Julian
  163. # [13:34] <hsivonen> rubys: I think the main cultural difference compared to Atom is that Hixie specifically asks people not to put forward concrete solutions
  164. # [13:36] <hsivonen> also, Atom feeds are less intertwingled with random legacy things than the HTML processing model is
  165. # [13:37] <rubys> I want to change that culture.
  166. # [13:40] <rubys> annevk: "asks for a coherent proposal..."; hsivonen: "asks people not to put forward concrete solutions"; my experience matches hsivonen's.
  167. # [13:40] * Joins: karl (karlcow@128.30.54.58)
  168. # [13:49] <Lachy> rubys, my experience is that Hixie wants coherent proposals, but doesn't particularly want the proposals to include spec text intended for direct inclusion, and would rather write the spec in his own words based on the proposal
  169. # [13:51] <hsivonen> rubys: as I understand it, the main problems with RDFa are:
  170. # [13:51] <hsivonen> 1) RDFa prioritizes data model compatibility with RDF over use cases
  171. # [13:51] <hsivonen> 2) RDFa is very complex considering the use cases
  172. # [13:52] <hsivonen> 3) Many of the use cases are themselves questionable
  173. # [13:52] <hsivonen> 4) The proposed syntax violates HTML Design Principles (unless text/html parsing is changed)
  174. # [13:53] <hsivonen> about complexity: RDF is simple in the way Go is simpler than Chess
  175. # [13:54] <hsivonen> also: it seems implausible that the stated use cases would be addressed well on the Web scale
  176. # [13:55] <hsivonen> and HTML5 is about doing things on the Web scale
  177. # [13:55] <hsivonen> which does antagonize small community or intranet use cases sometimes
  178. # [14:11] * Philip wonders what the Web scale
  179. # [14:13] <Philip> (Features like SQL databases are there for maybe a few dozen expert developers across the whole world, so presumably it doesn't mean features should be widely used by authors)
  180. # [14:13] <hsivonen> Philip: the Web scale is deployment all around the public browsable Web with untrusted people like spammers, black-hat SEO, etc. in the mix
  181. # [14:13] <jgraham> Philip: You think? I guess that will be much more popular than that
  182. # [14:14] <rubys> Provocative question: We should standardize it now because jgraham guesses that it will be much more popular at some point?
  183. # [14:14] <hsivonen> Philip: I don't mean deployment on every site, though
  184. # [14:15] <jgraham> rubys: Obviously you should put limited weight by my opinion alone :)
  185. # [14:15] <Philip> (Oops, I meant "what the Web scale is" but got distracted before the last word)
  186. # [14:15] <hsivonen> rubys: I don't care so much about standardizing it, but I care about having it specced if there's a chance that a late-mover browser needs to interoperate with the first-mover
  187. # [14:16] <jgraham> But the more serious answer is that there is a careful tightrope between too-early standardisation and too-late standardisation
  188. # [14:16] <Philip> Also the tightrope is invisible and we won't realise if we've fallen off it until years later
  189. # [14:16] <rubys> jgraham: yup. My preference is to move to a release early and often mode. SQL in HTML6 in 2012.
  190. # [14:17] <jgraham> rubys: I don't really understand what you mean
  191. # [14:18] <jgraham> I mean I understand that you want to release HTML more often
  192. # [14:18] <rubys> https://bugzilla.mozilla.org/show_bug.cgi?id=478665 and http://groups.google.com/group/mozilla.dev.platform/msg/a298577d55dbcfe4?pli=1
  193. # [14:18] <pimpbot> Title: Bug 478665 HTML5 spec without all the new features (at bugzilla.mozilla.org)
  194. # [14:19] <Philip> The current situation has SQL in HTML5 in 2008, which seems more like "release early" than waiting until 2012
  195. # [14:19] <jgraham> You mean you want to delay SQL from standarisation today because it wasn't in HTML4?
  196. # [14:19] <rubys> The current situation has SQL in HTML5 in Reissued Last Call Working Draft in 2020
  197. # [14:19] <jgraham> Even though it is already shipping in browsers
  198. # [14:20] <rubys> Canvas belongs in HTML5. It wasn't in HTML4.
  199. # [14:20] <jgraham> Why is canvas differnet to SQL?
  200. # [14:21] <hsivonen> jgraham: canvas has a markup integration point?
  201. # [14:21] * Joins: myakura (myakura@122.29.116.63)
  202. # [14:21] <hsivonen> jgraham: different in "HTML5" even if not in "Web Apps 1.0"
  203. # [14:21] <Philip> rubys: The current situation has the official status of the spec being pretty much irrelevant, so "release" corresponds roughly to when it's written into the editor's draft and someone starts implementing it
  204. # [14:21] <jgraham> hsivonen: It's not clear to me why that means it should be specified now rather than pushed to some undefined point in the future
  205. # [14:22] <rubys> Philip: the current spec is still changing rapidly.
  206. # [14:22] <hsivonen> jgraham: since SQL is shipping now, it should have been specced yesterday, in my opinion
  207. # [14:22] <annevk> rubys, what Lachy said is my understanding as well
  208. # [14:22] <jgraham> I don't see how it is possible to get away from the market-driven situation where actual implementations determine what is stable
  209. # [14:23] <jgraham> Saying "HTML 5 is evolving rapidy" is misleading. Parts of HTML 5 are evolving rapidly
  210. # [14:23] <rubys> jgraham: bingo
  211. # [14:23] <jgraham> The parts that have shipped already, not so much
  212. # [14:24] <jgraham> SQL has shipped
  213. # [14:24] <Philip> rubys: Is your preference that features won't be implemented in released browsers until they've been in the spec for a few years and have stabilised? (in which case we would then need to make that stabilisation process as fast as possible)
  214. # [14:24] <rubys> I would prefer to split out the parts that aren't changing rapidly. If SQL meets that bar, that's fine with me.
  215. # [14:25] <rubys> Philip: no
  216. # [14:25] <hsivonen> I guess one big question is whether one thinks specs need releases or only nightly builds
  217. # [14:25] <rubys> Philip: I'm OK with browsers inventing blink, marquee and even canvas tags occasionally. Some will catch on, others, not so much.
  218. # [14:28] <hsivonen> aside: http://lists.w3.org/Archives/Public/www-archive/2009Mar/0057.html is interesting re: RDFa
  219. # [14:28] <pimpbot> Title: stuff goes away from Larry Masinter on 2009-03-16 (www-archive@w3.org from March 2009) (at lists.w3.org)
  220. # [14:30] <Philip> rubys: Do you mean you're okay with browsers inventing those things without any standardisation occurring until years later (as part of HTML6)?
  221. # [14:30] <hsivonen> I'd like to ask the same question as Philip except with s/standardisation/speccing/
  222. # [14:32] <jgraham> rubys: I guess if you went through the draft and cut all the things that are not currently implemented or being implemented you could get rid of a few things like <datagrid> and <bb>.
  223. # [14:32] <jgraham> But not lots and lots
  224. # [14:32] <rubys> "any" is such an extreme word in both cases. XHR effectively was implemented, improved, and later spec'ed and standardized. Is that optimal? No. Am I OK with it? Yes.
  225. # [14:34] <Philip> It seems the WHATWG philosophy is that it's significantly better for features to be developed in browsers and specs in parallel, rather than letting browser developers do all the design work
  226. # [14:35] <hsivonen> http://blog.wolfram.com/2009/03/05/wolframalpha-is-coming/
  227. # [14:35] <pimpbot> Title: Wolfram Blog : Wolfram|Alpha Is Coming! (at blog.wolfram.com)
  228. # [14:35] <rubys> browsers and specs in parallel: good; holding back standardization until literally everything is ready all at once: not so good
  229. # [14:36] <hsivonen> I remember attending a presentation by TimBL where a member of the audience started ranting how Mathematica was much better at KR than RDF
  230. # [14:36] <Philip> (...because browser developers haven't demonstrated an ability to produce designs of adequate quality, e.g. they leave lots of things undefined or implementation-defined and miss various design considerations that someone else might notice)
  231. # [14:36] <takkaria> oh, someone embracing the impermanance of all things, even URIs
  232. # [14:39] * annevk is not quite ok with how XMLHttpRequest or e.g. <canvas> went down
  233. # [14:39] <jgraham> hsivonen: KR?
  234. # [14:40] <hsivonen> jgraham: Knowledge Representation
  235. # [14:43] <jgraham> Ah. Well it sounds like the UI will be better than the mathematica one anyway
  236. # [14:43] <hsivonen> jgraham: actually, Mathematica's UI has a nice feature I'd like markup editors to have
  237. # [14:44] <hsivonen> jgraham: but I've been told it's too difficult for J. Random User
  238. # [14:44] <Lachy> hsivonen, what's the feature?
  239. # [14:44] <hsivonen> jgraham: I like it how Mathematica visualizes block nesting in the right margin
  240. # [14:44] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  241. # [14:45] * jgraham never found that very useful
  242. # [14:45] <jgraham> I mean it wasn't bad but it didn't seem special
  243. # [14:47] <Lachy> hsivonen, do you mean the square brackets shown on the right of this screenshot? http://opennfo.files.wordpress.com/2007/10/fedora_mathematica.png
  244. # [14:48] <hsivonen> Lachy: yes
  245. # [14:53] <hsivonen> was Macromedia ever a W3C Member?
  246. # [14:57] <annevk> yes
  247. # [14:57] <annevk> see e.g. http://www.w3.org/Submission/1998/08/
  248. # [14:58] <hsivonen> annevk: thanks. I just observed that Macromedia didn't send a paper to The Workshop
  249. # [14:59] <hsivonen> looks like one of the co-signatories of that submission has been bought by MS subsequently
  250. # [15:00] <annevk> the title casing makes me cringe
  251. # [15:00] * hsivonen finds http://www.w3.org/TR/1998/NOTE-PGML-19980410
  252. # [17:04] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  253. # [17:08] * Joins: dbaron (dbaron@66.194.95.219)
  254. # [17:21] * Parts: rubys (rubys@75.182.92.38)
  255. # [17:34] * Joins: Lachy (Lachlan@85.196.122.246)
  256. # [17:40] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  257. # [17:42] * Joins: Lachy (Lachlan@85.196.122.246)
  258. # [17:46] * Joins: aroben (aroben@71.58.77.15)
  259. # [17:47] * Quits: dbaron (dbaron@66.194.95.219) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  260. # [17:49] * Quits: myakura (myakura@122.29.116.63) (Quit: Leaving...)
  261. # [18:03] * Joins: dsinger (dsinger@17.202.35.52)
  262. # [18:04] * Quits: hsivonen (hsivonen@130.233.41.50) (Ping timeout)
  263. # [18:13] * Joins: hsivonen (hsivonen@130.233.41.50)
  264. # [18:19] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  265. # [18:21] * Joins: gavin_ (gavin@99.226.207.11)
  266. # [18:36] * Quits: xover (xover@193.157.66.22) (Ping timeout)
  267. # [18:59] * Joins: adele (adele@17.246.16.223)
  268. # [19:15] * Joins: tlr (tlr@128.30.52.30)
  269. # [19:22] * Joins: smedero (smedero@192.223.6.251)
  270. # [19:22] <Hixie> "RDF is simple in the way Go is simpler than Chess" is surprisingly accurate
  271. # [19:23] <gsnedders> Heh.
  272. # [19:24] <gsnedders> Hixie: Where is that from?
  273. # [19:24] <Hixie> hsivonen, earlier in this channel
  274. # [19:45] * Quits: adele (adele@17.246.16.223) (Quit: adele)
  275. # [19:50] * Joins: adele (adele@17.203.15.219)
  276. # [19:50] * Quits: dsinger (dsinger@17.202.35.52) (Quit: dsinger)
  277. # [19:53] * Quits: adele (adele@17.203.15.219) (Quit: adele)
  278. # [20:18] * Joins: ddailey (david_dail@24.144.172.117)
  279. # [20:18] * Parts: ddailey (david_dail@24.144.172.117)
  280. # [20:26] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  281. # [20:45] <annevk> "XForms will be part of XHTML5 namespace" -- http://www.w3.org/2009/03/10-xhtml-minutes.html#item01
  282. # [20:45] <annevk> typo?
  283. # [20:45] <pimpbot> Title: XHTML2 WG Virtual FtF -- 10 Mar 2009 (at www.w3.org)
  284. # [20:52] * Joins: adele (adele@17.203.15.219)
  285. # [21:00] * Joins: Sander (svl@86.87.68.167)
  286. # [21:08] * Quits: DanC (connolly@128.30.52.30) (Client exited)
  287. # [21:41] * Quits: maddiin (mc@87.185.223.36) (Quit: maddiin)
  288. # [22:13] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  289. # [22:30] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  290. # [22:30] * Quits: heycam (cam@124.168.80.126) (Quit: bye)
  291. # [23:07] * Quits: smedero (smedero@192.223.6.251) (Quit: smedero)
  292. # [23:15] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  293. # [23:27] * RRSAgent excuses himself; his presence no longer seems to be needed
  294. # [23:27] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
  295. # [23:27] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  296. # [23:30] * Quits: pimpbot (pimpbot@80.68.92.65) (Ping timeout)
  297. # [23:31] * Joins: pimpbot (pimpbot@80.68.92.65)
  298. # Session Close: Tue Mar 17 00:00:00 2009

The end :)