/irc-logs / freenode / #whatwg / 2010-09-13 / end

Options:

  1. # Session Start: Mon Sep 13 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:03] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Read error: No route to host)
  4. # [00:22] * Quits: MikeSmith (~MikeSmith@EM114-48-14-249.pool.e-mobile.ne.jp) (Ping timeout: 272 seconds)
  5. # [00:22] * Joins: mischat (~mischat@78-86-167-133.zone2.bethere.co.uk)
  6. # [00:24] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  7. # [00:25] * Joins: MikeSmith (~MikeSmith@EM114-48-14-249.pool.e-mobile.ne.jp)
  8. # [00:27] <hober> hsivonen: re: emacs comment earlier, I've started work on one
  9. # [00:27] <hober> (an html parser in elisp that impls the html5 algorithm)
  10. # [00:28] <hober> it's nowhere near usable; I'll let you know when it gets to the point where it's worth looking at
  11. # [00:32] * Quits: mischat (~mischat@78-86-167-133.zone2.bethere.co.uk) (Quit: mischat)
  12. # [00:36] * Quits: mihaip (~mihaip@nat/google/x-vusmfmwxkeazoiyn) (Remote host closed the connection)
  13. # [00:36] * Joins: mihaip (~mihaip@nat/google/x-mwtgolgkysfyfjhq)
  14. # [00:38] * Quits: mihaip (~mihaip@nat/google/x-mwtgolgkysfyfjhq) (Remote host closed the connection)
  15. # [00:38] * Joins: mihaip (~mihaip@nat/google/x-lhifdpxxdwlwodrb)
  16. # [00:41] * Joins: mpt (~mpt@canonical/mpt)
  17. # [00:43] * Joins: dpranke (~Adium@nat/google/x-zkjovsavkhvqreic)
  18. # [00:43] * Joins: mischat (~mischat@78-86-167-133.zone2.bethere.co.uk)
  19. # [00:44] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  20. # [00:47] <jgraham> hober: Awesome
  21. # [00:47] <jgraham> hsivonen: No
  22. # [00:48] <jgraham> anne: (for the logs) the test cndition is just wrong. I will check in a fix at some point
  23. # [00:48] <jgraham> (i.e. the way that assert_throws determines pass/failiure in that case)
  24. # [00:50] * Joins: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams)
  25. # [00:55] * Joins: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net)
  26. # [01:00] * Quits: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net) (Ping timeout: 240 seconds)
  27. # [01:01] * Joins: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net)
  28. # [01:03] * Quits: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net) (Read error: Connection reset by peer)
  29. # [01:05] * Joins: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net)
  30. # [01:12] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  31. # [01:16] * Joins: boblet (~boblet@p2103-ipbf21osakakita.osaka.ocn.ne.jp)
  32. # [01:17] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  33. # [01:19] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  34. # [01:32] * Joins: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net)
  35. # [01:35] * Quits: jrgarrison (~garrison@wikiotics/jrgarrison) (Quit: Ex-Chat)
  36. # [01:37] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Disconnected by services)
  37. # [01:37] * Joins: gavin__ (~gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com)
  38. # [01:41] * Quits: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net) (Ping timeout: 240 seconds)
  39. # [01:42] * Joins: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net)
  40. # [01:49] * Joins: estes (~aestes@17.246.16.91)
  41. # [01:51] * Quits: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net) (Ping timeout: 272 seconds)
  42. # [01:53] * Joins: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net)
  43. # [01:56] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Quit: GarethAdams|Home)
  44. # [01:58] * Joins: 92AAA3Z8I (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  45. # [02:01] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 252 seconds)
  46. # [02:06] * Joins: kennyluck (~kennyluck@EM114-48-153-255.pool.e-mobile.ne.jp)
  47. # [02:06] * Quits: kennyluck (~kennyluck@EM114-48-153-255.pool.e-mobile.ne.jp) (Excess Flood)
  48. # [02:06] * Joins: kennyluck (~kennyluck@EM114-48-153-255.pool.e-mobile.ne.jp)
  49. # [02:09] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
  50. # [02:18] <AryehGregor> "The following extract shows how a messaging client's text entry could be arbitrarily restricted to a fixed number of characters, thus forcing any conversation through this medium to be terse and discouraging intelligent discourse.
  51. # [02:18] <AryehGregor> What are you doing? <input name=status maxlength=140>"
  52. # [02:18] <AryehGregor> I love these little things.
  53. # [02:18] <AryehGregor> Hope the W3C crowd that spotted the jab at Flash doesn't demand this be removed too. :)
  54. # [02:23] * Quits: boogyman (~boogy@unaffiliated/boogyman) (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
  55. # [02:23] * Joins: jacobolu_ (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net)
  56. # [02:25] * Quits: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net) (Ping timeout: 252 seconds)
  57. # [02:37] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  58. # [02:41] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  59. # [02:44] * Joins: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  60. # [02:47] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  61. # [02:48] * Joins: variable (~variable@unaffiliated/variable)
  62. # [02:55] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 255 seconds)
  63. # [02:55] <Dashiva> AryehGregor: They will now
  64. # [02:55] <Dashiva> Thanks a lot!
  65. # [02:55] <AryehGregor> :)
  66. # [02:55] <Dashiva> :P
  67. # [02:59] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  68. # [03:02] * Quits: 92AAA3Z8I (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  69. # [03:04] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
  70. # [03:08] * Joins: ojan_away (~ojan@nat/google/x-eniklzsdahkexndl)
  71. # [03:09] * Joins: takkaria (~takkaria@isparp.co.uk)
  72. # [03:09] * Parts: takkaria (~takkaria@isparp.co.uk)
  73. # [03:14] * Joins: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net)
  74. # [03:14] * Quits: jacobolu_ (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net) (Read error: Connection reset by peer)
  75. # [03:26] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  76. # [03:28] * Quits: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  77. # [03:30] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  78. # [03:30] * Quits: kennyluck (~kennyluck@EM114-48-153-255.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
  79. # [03:32] * Joins: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net)
  80. # [03:35] * Joins: 92AAA30VZ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  81. # [03:39] * Quits: Martijnc (~Martijnc@91.176.0.153) (Ping timeout: 276 seconds)
  82. # [03:39] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 265 seconds)
  83. # [03:39] <AryehGregor> "We’re excited that other browsers are starting to optimize for the Windows platform. Taking advantage of the PC’s hardware through the Windows APIs makes browsing on Windows better than browsing on other systems."
  84. # [03:39] <AryehGregor> I totally called that one.
  85. # [03:40] <AryehGregor> I said months ago that when other browsers supported acceleration, the IE team would say "Yeah, but it's way better when they run on Windows."
  86. # [03:40] <AryehGregor> (which it is)
  87. # [03:40] <AryehGregor> (my Linux machine doesn't even support hardware acceleration on my hardware yet unless I install unstable proprietary drivers)
  88. # [03:44] * Joins: Martijnc (~Martijnc@91.176.9.221)
  89. # [03:47] * Quits: variable (~variable@unaffiliated/variable) (Remote host closed the connection)
  90. # [04:01] * Joins: variable (~variable@unaffiliated/variable)
  91. # [04:07] * Quits: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net) (Quit: zzzzz)
  92. # [04:21] * Joins: macpherson (~macpherso@nat/google/x-zkpnjnqlkidcbnpu)
  93. # [04:27] * Quits: macpherson (~macpherso@nat/google/x-zkpnjnqlkidcbnpu) (Remote host closed the connection)
  94. # [04:27] * Joins: macpherson (~macpherso@nat/google/x-ahigvnkbqzvdoapy)
  95. # [04:51] * Joins: kevo_tool (~Kevin@97-83-177-130.dhcp.stpt.wi.charter.com)
  96. # [04:52] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  97. # [04:54] * Joins: roc (~roc@209.118.182.194)
  98. # [04:59] * Quits: jacobolus (~jacobolus@c-66-31-201-117.hsd1.ma.comcast.net) (Remote host closed the connection)
  99. # [05:00] * Quits: roc (~roc@209.118.182.194) (Quit: roc)
  100. # [05:01] * Joins: roc (~roc@209.118.182.194)
  101. # [05:04] * Quits: roc (~roc@209.118.182.194) (Read error: Connection reset by peer)
  102. # [05:06] * Joins: roc (~roc@209.118.182.194)
  103. # [05:08] <MikeSmith> AryehGregor: about that potentially objectionable part of the spec, I think in this particular case, anybody who wants to have it removed must be required to provide a careful, thorough argument via a single tweet.
  104. # [05:08] <MikeSmith> hober: cool to hear about initial work on the html parser in elisp
  105. # [05:09] <kevo_tool> What part?
  106. # [05:10] <MikeSmith> kevo_tool: eh?
  107. # [05:10] <kevo_tool> Objectional part of the spec
  108. # [05:11] <MikeSmith> kevo_tool: see the logs
  109. # [05:12] <MikeSmith> would give Chinese speakers a huge advantage
  110. # [05:13] <MikeSmith> or I guess anybody could write their argument in their own language, use Google translate or whatever to translate it to Chinese
  111. # [05:14] <MikeSmith> we should all do that for all our tweets, actually
  112. # [05:14] <MikeSmith> and have twitter auto-translate them back to whatever native language you want
  113. # [05:20] * Joins: davidwalsh (~davidwals@75-134-27-91.dhcp.mdsn.wi.charter.com)
  114. # [05:22] <MikeSmith> http://twitter.com/sideshowbarker/status/24349057841
  115. # [05:22] * abarth|afk is now known as abarth
  116. # [05:22] <MikeSmith> 如果我用中文写我的Twitter的消息,那么我可以说更多的,具有更少的字符。因此,从现在起,我会用中文写我的Twitter的所有邮件。
  117. # [05:24] <MikeSmith> to express that in English takes me 180 characters
  118. # [05:24] <MikeSmith> to express it in Chinese takes 67
  119. # [05:25] <jcranmer> but each Chinese character is several bytes in most charsets
  120. # [05:25] <MikeSmith> that sucks for those charsets
  121. # [05:25] <jcranmer> English is 1 byte/character in any sane charset
  122. # [05:26] <jcranmer> and no, UTF-16/UCS-2 and UTF-32 are not sane
  123. # [05:26] <MikeSmith> my message to those charsets is: Suck it up and find something else to complain about.
  124. # [05:26] <jcranmer> and UTF-9 is out of the question
  125. # [05:28] <MikeSmith> that's why this whole twit-tarded 140-character-limit thing is so senseless
  126. # [05:28] <MikeSmith> hence the editiorial comment in the spec, which is speaking gospel truth
  127. # [05:28] <jcranmer> does it count characters or bytes?
  128. # [05:29] <MikeSmith> twitter counts characters, not bytes
  129. # [05:29] <MikeSmith> to in the world of twitter, Chinese is king
  130. # [05:30] <jcranmer> characters as in Unicode codepoints?
  131. # [05:30] <MikeSmith> yeah, I reckon so
  132. # [05:31] <MikeSmith> with perhaps the usual exceptions
  133. # [05:31] <MikeSmith> surrogate pairs or whatever
  134. # [05:31] <jcranmer> so a + ` would be two characters
  135. # [05:40] * Quits: estes (~aestes@17.246.16.91) (Quit: estes)
  136. # [05:40] * Joins: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net)
  137. # [05:45] * Joins: jacobolu_ (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net)
  138. # [05:47] * Quits: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net) (Ping timeout: 245 seconds)
  139. # [05:48] * Quits: MikeSmith (~MikeSmith@EM114-48-14-249.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  140. # [05:54] * Joins: MikeSmith (~MikeSmith@EM111-188-191-231.pool.e-mobile.ne.jp)
  141. # [05:55] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 264 seconds)
  142. # [06:00] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  143. # [06:02] * Quits: gavin__ (~gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com) (Ping timeout: 272 seconds)
  144. # [06:07] * Quits: davidwalsh (~davidwals@75-134-27-91.dhcp.mdsn.wi.charter.com) (Quit: Reading http://davidwalsh.name)
  145. # [06:11] * Joins: GPHemsley (~GPHemsley@ool-45719f33.dyn.optonline.net)
  146. # [06:11] * Quits: GPHemsley (~GPHemsley@ool-45719f33.dyn.optonline.net) (Changing host)
  147. # [06:11] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
  148. # [06:31] * ojan_away is now known as ojan_syd
  149. # [06:33] * Quits: dpranke (~Adium@nat/google/x-zkjovsavkhvqreic) (Quit: Leaving.)
  150. # [06:34] * Joins: estes (~aestes@76-220-34-58.lightspeed.sntcca.sbcglobal.net)
  151. # [06:40] <MikeSmith> d'oh
  152. # [06:40] * MikeSmith remembers that the number box tells me how many characters I have left before I reach the limit
  153. # [06:41] * Quits: kevo_tool (~Kevin@97-83-177-130.dhcp.stpt.wi.charter.com) (Quit: Leaving)
  154. # [06:45] * Quits: MikeSmith (~MikeSmith@EM111-188-191-231.pool.e-mobile.ne.jp) (Ping timeout: 264 seconds)
  155. # [06:52] * Joins: MikeSmith (~MikeSmith@EM114-48-201-182.pool.e-mobile.ne.jp)
  156. # [07:02] * Quits: hamcore (rhythm@unaffiliated/msmosso)
  157. # [07:24] * Joins: rimantas (~rimliu@lan-84-240-20-219.vln.skynet.lt)
  158. # [07:28] * Joins: Ankheg (~Miranda@fs91-201-3-30.dubna-net.ru)
  159. # [07:47] * Joins: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu)
  160. # [07:48] * Quits: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu) (Client Quit)
  161. # [07:49] * Joins: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu)
  162. # [07:59] * Joins: [newbie] (~zalan@catv-89-135-140-7.catv.broadband.hu)
  163. # [08:00] * Quits: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu) (Ping timeout: 245 seconds)
  164. # [08:10] * Joins: mokush (~quassel@79.116.74.55)
  165. # [08:13] * Joins: FireFly (~firefly@unaffiliated/firefly)
  166. # [08:13] * Joins: kennyluck (~kennyluck@EM114-48-23-237.pool.e-mobile.ne.jp)
  167. # [08:13] * Quits: kennyluck (~kennyluck@EM114-48-23-237.pool.e-mobile.ne.jp) (Excess Flood)
  168. # [08:36] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
  169. # [08:38] * Joins: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams)
  170. # [08:40] <hsivonen> hober: cool (re: emacs)
  171. # [08:41] <annevk> jgraham, what is wrong about it?
  172. # [08:42] <annevk> jgraham, and why does it make Chrome not fail?
  173. # [08:43] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Client Quit)
  174. # [08:45] * Joins: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl)
  175. # [08:49] <annevk> jcranmer, MikeSmith, twitter counts 16-bit code units
  176. # [08:49] <annevk> i.e. str.length
  177. # [08:51] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  178. # [08:51] <MikeSmith> annevk: 喔
  179. # [08:51] <MikeSmith> 谢谢
  180. # [08:59] <webben> AryehGregor: Don't mind the jab myself, but it would be better if the example used a <label>.
  181. # [09:03] <paul_irish> what's the word on using dot notation to access web storage?
  182. # [09:04] <annevk> it's fine
  183. # [09:05] <paul_irish> good. the spec doesnt really mention it at all, so lots of folks think it's a dirty hack to be avoided.
  184. # [09:06] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  185. # [09:06] <annevk> it's part of the IDL
  186. # [09:06] <annevk> I grant you that specs are hard to read :)
  187. # [09:08] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  188. # [09:09] * Quits: Amorphous (jan@unaffiliated/amorphous) (Read error: Operation timed out)
  189. # [09:11] * Quits: paul_irish (~paul_iris@c-76-21-40-62.hsd1.ca.comcast.net) (Remote host closed the connection)
  190. # [09:15] <jgraham> annevk: It tries to check the .name property of the exception, which makes sense for ECMAScript exceptions but not for DOMExceptions
  191. # [09:15] <jgraham> Chrome simply doesn't throw an error in that case
  192. # [09:16] <jgraham> So it fails for an entirely different reason (or at least the version of Chrome I have does)
  193. # [09:17] * Joins: Steve_B (~chatzilla@gatej.thls.bbc.co.uk)
  194. # [09:18] <annevk> DOMExceptions have .name as well
  195. # [09:18] <annevk> or maybe they don't?
  196. # [09:19] <jgraham> annevk: I couldn't see it in the spec
  197. # [09:19] <jgraham> I think they have .name === "Error" from the prototype chain
  198. # [09:19] <annevk> the new spec has it, I assume Simon added it for a reason
  199. # [09:19] <jgraham> but I didn't dig deep enough into spec land to find out
  200. # [09:20] <annevk> oh yeah, it's simply error
  201. # [09:20] <annevk> maybe I should just remove .message and .name from the spec for now
  202. # [09:20] <annevk> DOM3Core only has .code
  203. # [09:21] <annevk> i guess .message and .name are general to exceptions? maybe something for either ECMAScript or Web IDL
  204. # [09:22] <jgraham> .name comes from ECMAScript assuming DOMException inherits from Error
  205. # [09:22] <jgraham> Not sure how I tell that from DOM Core 3
  206. # [09:23] <jgraham> But the name won't be the name of the exception
  207. # [09:23] <MikeSmith> annevk: 15.11.4.3 Error.prototype.message
  208. # [09:23] <MikeSmith> in the ES5 spec
  209. # [09:23] <annevk> ta
  210. # [09:23] <jgraham> Maybe simon trying to make the spec more useful?
  211. # [09:23] <MikeSmith> and 15.11.4.2 Error.prototype.name
  212. # [09:23] <annevk> could be
  213. # [09:23] <jgraham> Anyway, remove that check and it all works as expected
  214. # [09:24] <annevk> but I'm not sure why it would be useful
  215. # [09:24] <annevk> oh wait, that is what WebKit does
  216. # [09:25] <annevk> Mozilla gives back "NS_ERROR_DOM_NAMESPACE_ERR"
  217. # [09:25] <annevk> and Opera just Error
  218. # [09:25] <annevk> (for a NAMESPACE_ERR)
  219. # [09:27] * Joins: Amorphous (jan@unaffiliated/amorphous)
  220. # [09:28] <annevk> but it seems this should be addressed at the binding level somehow
  221. # [09:28] <annevk> since these are ECMAScript exception members
  222. # [09:29] * Joins: matijsb (~matijs@host90-152-76-118.ipv4.regusnet.com)
  223. # [09:29] <othermaciej> Web IDL should let you have an exception interface that inherits from whatever the normal language-native exception interface is
  224. # [09:29] <annevk> right
  225. # [09:30] <annevk> and for ECMAScript some way to set the name attribute
  226. # [09:30] <annevk> or have it map automatically or something
  227. # [09:33] * Joins: mpt (~mpt@canonical/mpt)
  228. # [09:33] <jgraham> annevk: In any case I suggest we remove that from testharness.js and check it as part of the WebIDL testsuite
  229. # [09:34] <annevk> ja
  230. # [09:36] * Quits: mpt (~mpt@canonical/mpt) (Excess Flood)
  231. # [09:37] * Joins: mpt (~mpt@canonical/mpt)
  232. # [09:37] * Joins: micheil (~micheil@124-168-141-29.dyn.iinet.net.au)
  233. # [09:42] * Quits: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net) (Quit: othermaciej)
  234. # [09:43] * Joins: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net)
  235. # [09:43] * Joins: virtuelv (~virtuelv_@65.168.34.95.customer.cdi.no)
  236. # [09:46] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 255 seconds)
  237. # [09:52] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 265 seconds)
  238. # [10:02] * Quits: mischat (~mischat@78-86-167-133.zone2.bethere.co.uk) (Quit: mischat)
  239. # [10:03] * Joins: mpt (~mpt@canonical/mpt)
  240. # [10:08] * Joins: zdenekkostal (~Miranda@ip-89-102-182-215.net.upcbroadband.cz)
  241. # [10:10] <hsivonen> I'd like to get a sanity check on http://www.w3.org/Bugs/Public/show_bug.cgi?id=10589 from a Web designer
  242. # [10:10] * Joins: stalled (~stalled@unaffiliated/stalled)
  243. # [10:11] <hsivonen> (that is, am I arguing for a change that'd make things better for designers)
  244. # [10:11] <hsivonen> (I think I am)
  245. # [10:12] <othermaciej> <figure> in <p> for floating figure makes sense to me
  246. # [10:12] <othermaciej> making <figure> close <p> is less compatible with legacy browsers than not doing so
  247. # [10:13] <MikeSmith> hsivonen: I'm not a designer but I agree with you
  248. # [10:13] <othermaciej> I don't think the rest of us need to be bound by Chrome's release schedule
  249. # [10:13] <othermaciej> if they ship every 4 months, then they'll just ship again before whatever they ship in 7 gets locked in
  250. # [10:14] <othermaciej> and frankly the new HTML5 parser has a number of what I'd consider critical regressions that are not yet fixed
  251. # [10:14] <hsivonen> othermaciej: what kind of critical regressions?
  252. # [10:14] <MikeSmith> I'm sympathetic to abarth point about impact on implementations, but my response about that would be, it's cheaper to change it now than it will be later, so let's make absolutely sure we have it right
  253. # [10:14] <annevk> it's scarily conservative imo
  254. # [10:15] <hsivonen> annevk: what's conservative?
  255. # [10:15] <annevk> not doing any more changes
  256. # [10:15] <abarth> othermaciej: what regressions?
  257. # [10:15] <othermaciej> of course, I am not sure what Adam would consider the same issues critical
  258. # [10:16] <abarth> my concern is that there are lots of dials to twiddle
  259. # [10:16] <othermaciej> we have 7 live regressions in our internal bug tracker that we consider P1; some are originally reported on Apple-internal sites so they have no bugzilla except maybe a scrubbed one
  260. # [10:16] <hsivonen> fwiw, I'm very close to going to the annotation-xml bug and say that it won't make it in by the time for Firefox 4 feature freeze and it's feature-ish
  261. # [10:17] <othermaciej> sure, you *could* fiddle endlessly, but hsivonen in particular has been giving feedback for a long time and the rate of changes he asks for seems to be declining, not increasing
  262. # [10:18] <othermaciej> abarth: here's two in bugzilla that we consider P1: <https://bugs.webkit.org/show_bug.cgi?id=44637> <https://bugs.webkit.org/show_bug.cgi?id=43328>
  263. # [10:18] <abarth> https://bugs.webkit.org/show_bug.cgi?id=44637 is a UA detect
  264. # [10:18] <abarth> it's not clear what we can do to fix it
  265. # [10:18] <othermaciej> we also have 4 bugs in Mail, the AIM client, and Pages
  266. # [10:19] <othermaciej> why would the UA detect start causing failure after the HTML5 parser is enabled?
  267. # [10:19] <MikeSmith> hsivonen: as a courtesy at last, please talk with David Carlisle before making a final decision on implementing it or not for the release
  268. # [10:19] <othermaciej> was that just a misdiagnosis?
  269. # [10:19] <MikeSmith> *at least
  270. # [10:19] <abarth> we started behaving more like other browsers
  271. # [10:19] <othermaciej> we also have two bugs on apple.com which can probably be fixed through evangelism
  272. # [10:19] <abarth> basically, they do a UA detect
  273. # [10:19] <abarth> and based on that
  274. # [10:20] <abarth> they decide which dom element to set to display:none
  275. # [10:20] <othermaciej> er, on internal apple sites rather, not the public apple.com
  276. # [10:20] <abarth> assuming that different UAs will produce different DOMs
  277. # [10:20] <abarth> for https://bugs.webkit.org/show_bug.cgi?id=43328, we have a two-line reduction
  278. # [10:20] <abarth> we just need to get eric's attention to finish the fix
  279. # [10:21] <othermaciej> does that one need a spec change?
  280. # [10:21] <abarth> i can't really help with apple-internal bugs unless someone tells me what the problem is
  281. # [10:22] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: brb)
  282. # [10:22] <othermaciej> for the native apps we may have to add quirks
  283. # [10:22] <othermaciej> we are prepared to handle those ourselves as necessary
  284. # [10:22] <abarth> i imagine https://bugs.webkit.org/show_bug.cgi?id=40961 is something we'll need to add a pref for
  285. # [10:22] <othermaciej> for apple-internal sites, I sure hope evangelism works, cause I'd rather not ship a site-specific hack for an Apple intranet site
  286. # [10:23] <othermaciej> we have some cases of "<style</style>" in Mail messages
  287. # [10:24] <abarth> I don't think bug 43328 will need a spec change. the issue is two async events that are racing
  288. # [10:24] <hsivonen> happily, evangelism has worked for Mozilla's intranet :-)
  289. # [10:24] <othermaciej> probably no way to handle that but an app-specific quirk, since even if we stop sending such content, those emails already exist
  290. # [10:24] <abarth> something subtle changed in the timing that reversed the outcome of the race
  291. # [10:24] <othermaciej> we have one report of unclosed <tilte> eating the page on a real site
  292. # [10:24] <othermaciej> that one should go into bugzilla
  293. # [10:24] <hsivonen> I thought window.location setting and .reload() were supposed to kill the parser synchronously
  294. # [10:25] <hsivonen> at least in Gecko, we have an API for terminating the parser synchronously
  295. # [10:25] <abarth> yes
  296. # [10:25] <hsivonen> at one time, it seemed like and endless pit of trouble
  297. # [10:25] <abarth> that's what we need
  298. # [10:25] <hsivonen> but I think I have it working now
  299. # [10:25] <abarth> AFAIK webkit doesn't/didn't have that
  300. # [10:25] <hsivonen> s/and/an/
  301. # [10:25] <abarth> but the observable results where the same
  302. # [10:26] <hsivonen> MikeSmith: OK.
  303. # [10:26] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
  304. # [10:26] <abarth> othermaciej: the goal of this project (from my point of view) is that we pay these debts now and then never have to worry about this stuff again
  305. # [10:26] <othermaciej> anyway we'll add whatever quirks we need to handle compat with Mac OS X (and maybe iOS) native apps correctly
  306. # [10:26] <annevk> does HTML5 define that?
  307. # [10:26] <annevk> terminating the parser synchronously?
  308. # [10:26] <abarth> othermaciej: ideally, we'd have done this when we had 0% market share
  309. # [10:26] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  310. # [10:26] <othermaciej> abarth: I definitely think it's a worthwhile exercise
  311. # [10:27] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  312. # [10:27] <othermaciej> all I'm saying is that it's not done-and-practically-ready-to-ship from Apple's POV at least
  313. # [10:27] <hsivonen> annevk: I'm not sure if it does now, but at least it did when I was dealing with it
  314. # [10:27] <othermaciej> we are not even necessarily expecting anyone else to fix the bugs we consider showstoppers in it
  315. # [10:28] <hsivonen> annevk: IIRC, at least at the time, Hixie considered forced stopping a stop button thing (i.e. a browser-specific UI issue)
  316. # [10:28] <abarth> i'm happy to do whatever needs to be done, but communication is important
  317. # [10:28] <hsivonen> but window.location makes it a script-exposed issue :-(
  318. # [10:28] <othermaciej> anything that's on public sites, I'm sure we'll put in bugzilla well ahead of time
  319. # [10:29] <othermaciej> I think even for the native app cases, we've communicated the quirks we've hit, though the details of making it an app-specific hack are up to us
  320. # [10:29] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  321. # [10:29] <othermaciej> it looks like <foo</foo> is by far the most common source of problems
  322. # [10:29] <abarth> i'll add a setting for that now
  323. # [10:30] <othermaciej> it's too bad that HTML5 chose to go the Opera/IE way on that one
  324. # [10:30] <othermaciej> but perhaps IE team would be eating this same kind of pain otherwise
  325. # [10:30] <abarth> according to ian, stuff breaks either way
  326. # [10:30] <othermaciej> (though it's harder to imagine content depending on the IE/Opera way)
  327. # [10:31] <othermaciej> I haven't seen the data but I'm ok with just taking it on faith and biting this particular bullet
  328. # [10:31] <hsivonen> othermaciej: IIRC, someone from Opera on this channel has said content does depend on it
  329. # [10:31] <hsivonen> othermaciej: I'm taking the Opera guys' word for this, too
  330. # [10:32] <othermaciej> I have heard that and am mostly willing to believe it though I have not actually seen pointers to actual such content
  331. # [10:32] <abarth> w.r.t. conservatism, i think its easy to lose site of the fact that a stable platform is essential for building complex sites
  332. # [10:32] * Joins: mat_t (~mattomasz@91.189.88.12)
  333. # [10:32] * Joins: ROBOd (~robod@89.123.173.167)
  334. # [10:32] <abarth> in some sense, having IE6 around for so long was very good for the web
  335. # [10:32] <othermaciej> the parsing algorithm is definitely settling down I think
  336. # [10:33] * Joins: ZombieL (~e@c-36d471d5.014-169-73746f28.cust.bredbandsbolaget.se)
  337. # [10:33] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe) (Read error: Connection reset by peer)
  338. # [10:33] <othermaciej> even though its simulated annealing process has not yet quite hit thermal equilibrium with the environment
  339. # [10:33] * Quits: riven (~riven@53518387.cable.casema.nl) (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.)
  340. # [10:33] <hsivonen> abarth: in this particular <p><figure> case, I think it's essential not to make certain useful trees impossible by sprinkling implicit <p> closing around too much
  341. # [10:33] <othermaciej> I do believe HTML5 parsing has fixed more bugs than it has created, even though the latter end up more salient
  342. # [10:34] <othermaciej> abarth: btw, you don't *have* to add the setting - it would be useful for more people to learn the code by actually adding something to it
  343. # [10:34] <hsivonen> abarth: especially when experience with <p><table> suggests that not letting authors put stuff inside <p> isn't exactly helping authors
  344. # [10:34] <othermaciej> abarth: advice may add more value here than code
  345. # [10:34] <annevk> abarth, the problem with completely stable is that the most stupid bugs become platform features - some amount of change is needed to prevent that, I think
  346. # [10:34] <othermaciej> <p><ul> is also clearly fail in retrospect
  347. # [10:34] <hsivonen> othermaciej: yes
  348. # [10:35] <abarth> othermaciej: ok, i'm happy to review adding the setting. it's actually very easy. basically, you make '<' move out of the tag name state and get reconsumed in the data state
  349. # [10:35] <hsivonen> I nowaways think implicit <p> closing is a general fail
  350. # [10:35] <hsivonen> I'm willing to accept it for legacy stuff, but adding it for new stuff is a (small) tragedy if it makes things harder for authors
  351. # [10:36] <annevk> for <section> it makes sense
  352. # [10:36] <annevk> for <figure> not so much
  353. # [10:36] * Joins: peol_ (~peol@unaffiliated/peol)
  354. # [10:37] <abarth> each tweak is made with good intentions
  355. # [10:37] <othermaciej> I think implicit close tags in general might be fail
  356. # [10:37] <hsivonen> annevk: yeah, section makes sense, though I've had disapproving private feedback once about that, too
  357. # [10:37] <abarth> i'm not going to fight about it
  358. # [10:38] <othermaciej> over the next couple of months, changes to the w3c spec at least are going to become process-wise more difficult
  359. # [10:38] <abarth> but i'll be happy when we're done changing the spec :)
  360. # [10:38] <MikeSmith> amen to that
  361. # [10:38] <othermaciej> so it's kind of the last chance to make tweaks before things freeze up
  362. # [10:38] <othermaciej> I wish we could be done already but I feel that hsivonen has the merits of the case on that bug
  363. # [10:39] <othermaciej> because it's an HTML5 behavior that moves away from the behavior of any legacy browser, and is bad on the merits
  364. # [10:39] * Quits: roc (~roc@209.118.182.194) (Quit: roc)
  365. # [10:46] * Joins: Phae (~Phae@chimera.macmillan.com)
  366. # [10:49] * Joins: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams)
  367. # [10:51] * Joins: erlehmann (~erlehmann@89.204.137.102)
  368. # [10:51] * Quits: mpt (~mpt@canonical/mpt) (Quit: Ex-Chat)
  369. # [10:52] * Quits: Rik`_ (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Remote host closed the connection)
  370. # [10:54] * Joins: mpt (~mpt@canonical/mpt)
  371. # [10:55] * Joins: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk)
  372. # [10:56] <hsivonen> given https://bugs.webkit.org/show_bug.cgi?id=44637 , maybe Safari should put "Chrome" in its UA string, too
  373. # [10:56] <hsivonen> "Safari (like Chrome)" and "Chrome (like Safari)"
  374. # [10:57] <abarth> the UA string is the definitely the thing i dislike the most about the web
  375. # [10:57] <abarth> one can only imagine what UA strings will look like 10 years from now
  376. # [10:58] <abarth> hsivonen: you should see the bug where the gtk version of WebKit gets locked out of advanced features because sites (including google) don't realize that it's webkit
  377. # [10:58] * Quits: boblet (~boblet@p2103-ipbf21osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  378. # [10:59] <hsivonen> the root of the problem is that you can't have your UA string cake and eat it too: if you put something in there for marketing statistics, someone *will* sniff it to exclude functionality
  379. # [10:59] <abarth> https://bugs.webkit.org/show_bug.cgi?id=39617
  380. # [10:59] <hsivonen> btw, SeaMonkey is putting "Firefox" in its UA string and providing an advanced pref for the hard-liners to take it out of the UA string
  381. # [11:00] <hsivonen> Open Source prefs...
  382. # [11:00] * Joins: Alistair (Alistair@ppp118-209-28-24.lns20.mel4.internode.on.net)
  383. # [11:02] <hsivonen> abarth: why didn't WebKit GTK just always say "Safari" instead of making it a site-specific hack?
  384. # [11:02] <hsivonen> once you've put "Firefox", "Safari" or "Chrome" in the UA string, making sites sniff for a less obvious name like "Gecko" or "WebKit" is an exercise in futility
  385. # [11:02] <othermaciej> Chrome alrady has Safari in the UA string IIRC
  386. # [11:02] <abarth> it was hard to discuss the issue with the stakeholders
  387. # [11:03] <hsivonen> othermaciej: indeed
  388. # [11:03] <abarth> because they were somewhat emotional about it
  389. # [11:03] * Joins: kennyluck (~kennyluck@2001:200:1c0:3602:225:ff:fe4d:f8c7)
  390. # [11:03] <hsivonen> abarth: I see.
  391. # [11:03] <annevk> yeah, User-Agent is a pain and bloat
  392. # [11:04] <annevk> kudos to Microsoft for promoting good detection practices on their blog
  393. # [11:04] <abarth> the part that gets me about it is how it makes it harder for browsers to fix their bugs
  394. # [11:04] <annevk> if only Google would take note...
  395. # [11:04] <abarth> :)
  396. # [11:05] <hsivonen> which reminds me that one of the things I have on my todo list today is working around GWT's on-by-default UA sniffing in V.nu live dom
  397. # [11:06] <hsivonen> http://groups.google.com/group/mozilla.dev.apps.seamonkey/msg/47f95dafd399495f?pli=1
  398. # [11:07] <jgraham> FWIW I agree with hsivonen about the <p><figure> thing
  399. # [11:07] <abarth> oh that FoxFire
  400. # [11:07] <abarth> always causing trouble
  401. # [11:08] <othermaciej> google sites have in the past had some of the worst UA checks I have ever seen
  402. # [11:09] <hsivonen> fwiw, if Mozilla executes on the currently announced Firefox 5.0 UA string plan, GWT apps would think Firefox 5.0 has Gecko < 1.8
  403. # [11:09] <hsivonen> s/would/will/
  404. # [11:13] <jgraham> GWT is evil
  405. # [11:13] <jgraham> evil
  406. # [11:13] <hsivonen> <svg><foreignObject><div><![CDATA[foo]]>
  407. # [11:14] <hsivonen> why should the CDATA thing parse as a bogus comment per spec?
  408. # [11:14] <hsivonen> (I understand we want it to parse as a bogus comment)
  409. # [11:14] <hsivonen> but I can't derive it from the spec
  410. # [11:14] <jgraham> hsivonen: The parent element is in the HTML namespace
  411. # [11:15] * hsivonen re-checks the tokenizer spec
  412. # [11:15] <abarth> am i confused about http://www.w3.org/Bugs/Public/show_bug.cgi?id=10621 ?
  413. # [11:15] <abarth> i checked in Minefield, but Minefield doesn't seem to pass the tests I wrote about that part of the spec
  414. # [11:16] * Joins: smaug____ (~chatzilla@cs181063178.pp.htv.fi)
  415. # [11:16] * Joins: david_carlisle (~chatzilla@62.231.145.254)
  416. # [11:16] <hsivonen> abarth: I have unreviewed patches sitting in my queue
  417. # [11:17] <hsivonen> jgraham: the spec doesn't check the namespace of the current node. it checks if the tree builder is in the "in foreign content" mode
  418. # [11:17] <jgraham> hsivonen: Did you find it? In the markup declaration open state it says """Otherwise, if the insertion mode is "in foreign content" and the current node is not an element in the HTML namespace and the next seven characters are an case-sensitive match for the string "[CDATA[" (the five uppercase letters "CDATA" with a U+005B LEFT SQUARE BRACKET character before and after), then consume those characters and switch to the CDATA section state."""
  419. # [11:17] <jgraham> note "and the current node is not an element in the HTML namespace"
  420. # [11:18] <hsivonen> jgraham: ooh. when did the "and" part get added there?
  421. # [11:18] * Joins: jeremyselier (~Jeremy@pro75-4-82-238-200-10.fbx.proxad.net)
  422. # [11:18] <hsivonen> jgraham: so why do we have "in foreign content" as a mode again? instead of always checking the namespace of the current node instead
  423. # [11:19] <david_carlisle> hsivonen: annotation-xml bug... Obviously Firefox has to have its production schedule and if that means it needs to go out implementing the currently broken parser specification, so be it, but Firefox having gone out can't then be used as a reason for not fixing this bug in the spec which is pretty critical to MathML usage.
  424. # [11:19] <abarth> yeah, that's one of the annoying leaks of state from tree builder to tokenizer
  425. # [11:19] <jgraham> hsivonen: Ask Hixie :)
  426. # [11:19] <abarth> each one of those is tears
  427. # [11:19] <jgraham> abarth: Didn't hsivonen already file a bug on that?
  428. # [11:19] <abarth> it means things like the preload scanner don't get the right tokenization
  429. # [11:20] <abarth> oh, maybe, not sure
  430. # [11:20] <hsivonen> abarth: in Gecko it does!
  431. # [11:20] <hsivonen> off-the-main-thread parsing FTW!
  432. # [11:20] <abarth> how?
  433. # [11:20] <abarth> you run the whole treebuilder?
  434. # [11:20] <hsivonen> abarth: yes
  435. # [11:20] <hsivonen> abarth: there's no separate prescan
  436. # [11:20] <abarth> any then throw away the work if document.write ?
  437. # [11:20] <hsivonen> abarth: the speculative parse is the prescan
  438. # [11:20] <hsivonen> abarth: only if it's a bad kind of document.write
  439. # [11:21] <hsivonen> abarth: most document.writes are ok
  440. # [11:21] <abarth> do you tokenize for view-source?
  441. # [11:22] <hsivonen> david_carlisle: I have a hard time understanding the criticality, but I'll try again
  442. # [11:22] <hsivonen> abarth: the HTML5 parser isn't used for view source, yet, but the plan is to run the tree builder for view source
  443. # [11:22] <abarth> webkit just tokenizes and uses a different tree builder
  444. # [11:22] <abarth> that builds a colorization of the tokens as a DOM
  445. # [11:23] <david_carlisle> most mathml tools annotate the expressions they write so having annotations break in this frankly bizarre fashion means that it's not possible to use most mathml in html without first hand editing it, that's bad,
  446. # [11:24] <hsivonen> abarth: that's how Gecko does it and will continue to do it
  447. # [11:24] <hsivonen> abarth: but the HTML5 tree building algorithm will have to run to get foreign land coloring right
  448. # [11:24] * Joins: Rik` (~Rik`@mozilla-paris-222-194.cnt.nerim.net)
  449. # [11:24] <abarth> that's true
  450. # [11:25] <abarth> i think we don't colorize that correctly today
  451. # [11:25] <hsivonen> HTML5 view source probably won't make it to Firefox 4
  452. # [11:25] <hsivonen> (unless maybe if the product drivers don't consider it a new feature)
  453. # [11:25] <hsivonen> it's definitely not making it for the feature freeze
  454. # [11:26] <abarth> the firefox release process is very strange
  455. # [11:26] <abarth> betas before feature freezes
  456. # [11:26] <abarth> i guess every browser has a strange release process
  457. # [11:28] <abarth> whoops. we never removed the special case for the sarcasm tag
  458. # [11:28] <hsivonen> david_carlisle: and the tools today say encoding="application/xhtml+xml"?
  459. # [11:28] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: This computer has gone to sleep)
  460. # [11:29] <hsivonen> abarth: how does WebKit take a deep breath? spin the event loop?
  461. # [11:29] <abarth> there's a comment and then a notImplement()
  462. # [11:29] <abarth> which means the end tag is ignored... :(
  463. # [11:31] <annevk> you have a bug in implementing </sarcasm>
  464. # [11:31] <annevk> now that's funny
  465. # [11:31] <abarth> yep
  466. # [11:31] <abarth> and it's going to ship in a stable release :P
  467. # [11:32] <abarth> so silly
  468. # [11:32] <annevk> Chrome 7 -- the one that didn't get </sarcasm> right ;p
  469. # [11:32] * hendry_ is now known as hendry
  470. # [11:33] <abarth> https://bugs.webkit.org/show_bug.cgi?id=45645
  471. # [11:33] * Quits: Alistair (Alistair@ppp118-209-28-24.lns20.mel4.internode.on.net)
  472. # [11:35] <david_carlisle> hsivonen: No of course not, but.. needing to put on an attribute is very much a second choice, but the best we could get out of the bug reporting system it seemed, but tools and people can be instructed to add the attribute and most likely the existing uses of the annotation are unaffected. however if annotation is unusable then tools can't be fixed, the spec is just broken. The current...
  473. # [11:35] <david_carlisle> ...behaviour is just so weird I had a hard time persuading the WG that it was actually specified that way (rather than just a software bug). I can understand product release cycles and code freezes but I can not understand how anyone could possibly try to justify the parse tree that the current parse specification says should be produced. it is simply wrong.
  474. # [11:37] <hsivonen> david_carlisle: I don't see the point of putting HTML in an annotation
  475. # [11:38] <hsivonen> david_carlisle: I expect Hixie didn't, either
  476. # [11:38] <hsivonen> david_carlisle: if it's better expressed as MathML, why have HTML at all there? and if it's better expressed in HTML, why have MathML there?
  477. # [11:42] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  478. # [11:42] <david_carlisle> hsivonen: "I don't see the point" perhaps, but we can't see the point of taking a perfectly well nested set of start and end tags and arbitrarily producing a tree for a completely different structure (that doesn't render at all) , So the "add an attribute" was the uneasy compromise that probably no one really liked that much. The bug needs to be fixed somehow or we are in the nonsense of...
  479. # [11:42] <david_carlisle> ...blocking objections and bureaucratic unpleasantness, which i really hoped we'd avoided.
  480. # [11:43] <hsivonen> david_carlisle: I might be able to suggest something better than "add an attribute" if I understood the existing usage patterns and their motivations
  481. # [11:45] <david_carlisle> hsivonen: maybe the html annotation is a proof step hint that just pops up on user interaction, maybe it's a list of references who knows? annotation are like data- attributes, but allowing structured annotation. the whole point is that you, me, anyone is not supposed to second guess how they are to be used, they are a container for arbitrary user defined data.
  482. # [11:46] <hsivonen> david_carlisle: I see
  483. # [11:46] <hsivonen> and when MathML appears as an annotation, there's no new <math> root in the common case?
  484. # [11:47] <david_carlisle> hsivonen: true
  485. # [11:47] <hsivonen> david_carlisle: ok. "add an attribute" is the best I can suggest
  486. # [11:47] <david_carlisle> hsivonen: :-)
  487. # [11:47] <hsivonen> well, I suppose I should go ahead and implement it soonish
  488. # [11:48] <david_carlisle> hsivonen: stop chatting here and get to work (actually that applies to me too)
  489. # [11:53] <hsivonen> david_carlisle: well, figuring out what makes sense to implement is work, too
  490. # [11:54] <annevk> abarth, "callTheAdoptionAgency" lol
  491. # [11:54] <abarth> eric wanted a wittier name
  492. # [11:55] <abarth> but that's all we could think of
  493. # [11:55] <othermaciej> what does that function do?
  494. # [11:55] <david_carlisle> hsivonen: OK you're forgiven than but probably I won't be, I need to go...
  495. # [11:56] <abarth> othermaciej: it goes and reparents a bunch of nodes
  496. # [11:56] <annevk> othermaciej, implements the adoption agency algorithm
  497. # [11:56] <abarth> othermaciej: to correct for mis-nested tags
  498. # [11:56] <othermaciej> abarth: I was thinking either giveUpForAdoption() or adopt() would be good names
  499. # [11:56] <abarth> its somewhat famous in HTML parsing circles
  500. # [11:56] <othermaciej> but it sounds like it does both, depending on your perspective
  501. # [11:56] <abarth> patches welcome :)
  502. # [11:57] <abarth> the spec sayeth
  503. # [11:57] <othermaciej> I know what the AAA is, I just wasn't sure what the parameters and behavior of this particular function were
  504. # [11:57] <abarth> 'Because of the way this algorithm causes elements to change parents, it has been dubbed the "adoption agency algorithm" (in contrast with other possible algorithms for dealing with misnested content, which included the "incest algorithm", the "secret affair algorithm", and the "Heisenberg algorithm").'
  505. # [11:57] <abarth> it just takes the current token
  506. # [11:57] <annevk> hehe
  507. # [11:57] <abarth> like all the tree builder functions
  508. # [11:57] <othermaciej> I guess it is hard to make it a transitive verb then
  509. # [11:58] <abarth> but that's just how the tree builder works
  510. # [11:58] <annevk> I wonder when I'll forgot how each browser (used to) map to those names
  511. # [11:58] <othermaciej> I can figure out which is which from the names
  512. # [11:59] <othermaciej> maybe someday it won't be a memorable fact
  513. # [11:59] <othermaciej> (WebKit, Trident, Presto, Gecko in order of reference)
  514. # [12:00] <othermaciej> and I even vaguely remember why the other three have those names but even talking about what legacy IE does makes me shudder
  515. # [12:01] <virtuelv> othermaciej: are you implying the IE engine is a weapon?
  516. # [12:01] <hsivonen> btw, I was about to suggest a change to the AAA yesterday. maybe I'll get around to it today
  517. # [12:02] <jgraham> hsivonen: Should I be scared?
  518. # [12:02] <hsivonen> jgraham: no, I'd expect you to be happy about it
  519. # [12:03] <hsivonen> oops. actually my change is for putting stuff in the list of active formatting elements in the first place--not to the AAA
  520. # [12:03] <othermaciej> I wonder how the spec version of AAA avoids O(N^2) behavior in the cases where in the old WebKit parser we had to add hardcoded limits
  521. # [12:03] <jgraham> othermaciej: It doesn't
  522. # [12:03] <othermaciej> or rather I wonder how the WebKit implementation of the spec version does so
  523. # [12:03] <hsivonen> jgraham: I was thinking we should search the list for font elements with the same attributes as the current token
  524. # [12:03] <hsivonen> jgraham: then zap the first one on the list if there's a match
  525. # [12:03] * Quits: smaug____ (~chatzilla@cs181063178.pp.htv.fi) (Ping timeout: 240 seconds)
  526. # [12:03] <hsivonen> but only if the list is longer than n
  527. # [12:04] <hsivonen> for a carefully chosen n
  528. # [12:04] <abarth> othermaciej: we have limits
  529. # [12:04] <hsivonen> abarth: what do you limit?
  530. # [12:04] <othermaciej> I guess those tests are passing so there must be something
  531. # [12:04] <jgraham> hsivonen: Just to reduce the number of elements on the list?
  532. # [12:04] <abarth> the two loops
  533. # [12:04] <hsivonen> Gecko has a limit on the depth of the tree
  534. # [12:05] <abarth> yeah, we don't have that yet, but i expect someone to complain
  535. # [12:05] <hsivonen> jgraham: to stop insane growth when pages open <font> without ever closing
  536. # [12:05] <hsivonen> and opening <font> a zillion times
  537. # [12:06] <othermaciej> I should probably see if I can get O(N^2) with variants of some of the cases I added as layout tests
  538. # [12:06] <hsivonen> so that reconstructing the active formatting elements reconstruct more and more every time
  539. # [12:06] <jgraham> The current gecko behaviour doesn't stop badness for well-chosen input
  540. # [12:06] <hsivonen> jgraham: I know
  541. # [12:06] <jgraham> I haven't tested webkit yet
  542. # [12:06] <jgraham> hsivonen: I know you know :)
  543. # [12:06] <abarth> the limits are different than the old parser
  544. # [12:06] <hsivonen> abarth: the depth limit is needed in Gecko, because Gecko's layout module has algorithms that are recursive along tree depth
  545. # [12:07] <abarth> webkit used to limit to 4k depth
  546. # [12:07] <hsivonen> and Windows has relatively small permitted call stack depth
  547. # [12:08] <othermaciej> WebKit has recursive algorithms too
  548. # [12:08] <hsivonen> othermaciej: interesting. how do you avoid crashing on Windows?
  549. # [12:08] <othermaciej> I kind of wish all recursive algorithms could be rewritten as iterative but it would be quite awkward in the case of layout
  550. # [12:08] <othermaciej> I think in practice other limits would kick in before the depth limit on bad input
  551. # [12:09] <othermaciej> there might also be a separate render tree limit but I don't recall
  552. # [12:09] <othermaciej> my design preference would be to not limit the dom around the render tree's limitations as probably nearly all dom algorithms could be made iterative without much hassle; and then depth limiting can be in the render tree if it exists at all
  553. # [12:10] <othermaciej> but that implies all sorts of nontrivial changes
  554. # [12:16] <hsivonen> abarth: did you check that the early exit from the AAA loops due to the limit doesn't leave the list of active formatting elements in a bad state?
  555. # [12:16] * hsivonen has not gotten around to thinking through the implications
  556. # [12:17] <abarth> what bad states are there?
  557. # [12:17] <hsivonen> abarth: markers getting out of sync, I guess
  558. # [12:18] <hsivonen> but I think the AAA never removes a marker, does it?
  559. # [12:18] <Rik`> Why WebKit browsers add datalist { display: none; } ?
  560. # [12:18] <abarth> dunno. eric wrote the AAA
  561. # [12:19] <hsivonen> maybe we should hard-code 10 as a limit in the spec if 10 is good enough
  562. # [12:20] <Rik`> it makes <datalist> useless for the time being :(
  563. # [12:20] <abarth> 10 lets you build a really big tree
  564. # [12:20] <hsivonen> abarth: have you run this on Google data sets to see how often the limit is hit?
  565. # [12:21] <abarth> http://trac.webkit.org/browser/trunk/LayoutTests/fast/parser/residual-style-dom.html
  566. # [12:21] <abarth> nope
  567. # [12:21] <annevk> Rik`, shouldn't it be display:none?
  568. # [12:21] <Rik`> annevk: not if you don't support @list
  569. # [12:21] <abarth> http://trac.webkit.org/export/67375/trunk/LayoutTests/fast/parser/residual-style-dom-expected.txt
  570. # [12:21] <annevk> Rik`, oh... stupid
  571. # [12:22] <Rik`> annevk: btw, it's also broken in Opera but I can't even set display: block
  572. # [12:22] <hsivonen> abarth: isn't that testing "reconstruct active formatting element" as opposed to testing the AAA?
  573. # [12:23] <annevk> Rik`, data:text/html,<input list=x><datalist id=x><option value=test><option value=grr></datalist> wfm
  574. # [12:23] <Rik`> I'm using <option>test<option>grrr
  575. # [12:23] <annevk> interesting
  576. # [12:23] <abarth> hsivonen: there's no limit on reconstructing the active formatting elements
  577. # [12:24] <annevk> maybe we never supported that
  578. # [12:24] <abarth> hsivonen: i could be wrong about this stuff. AAA is eric's area
  579. # [12:24] <abarth> (i make him do the hard stuff)
  580. # [12:24] <Rik`> annevk: is it supported in HTML5 now ?
  581. # [12:25] <annevk> dunno
  582. # [12:26] <annevk> Rik`, per HTML5 we have a bug yes
  583. # [12:26] <Rik`> annevk: but yeah, at least it's working with value=
  584. # [12:26] <annevk> value of option is either its value attribute or its textContent attribute
  585. # [12:27] <Rik`> I'm really angry at the webforms support in WebKit browsers :(
  586. # [12:27] <hsivonen> https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms#Shipping_Criteria FTW!
  587. # [12:29] <Rik`> this page is a bit out of date
  588. # [12:29] <annevk> yeah, Mozilla is doing it the right way
  589. # [12:30] <Rik`> I really enjoy working with Mounir although he's not in the Paris at the moment
  590. # [12:30] <annevk> Rik`, you work for Mozilla?
  591. # [12:30] <Rik`> currently
  592. # [12:30] <abarth> i might be misremembering, but i think some of the forms work in webkit was done by new contributors
  593. # [12:31] <annevk> ah
  594. # [12:31] <Rik`> my contract ends at the end of this week
  595. # [12:31] <annevk> abarth, someone from Google had the wrong idea too about some stuff iirc
  596. # [12:31] <Rik`> abarth: whoever worked on it, it should have never shipped in this state
  597. # [12:31] <annevk> i.e. that the UI-facing stuff could just be ignored
  598. # [12:32] <hsivonen> http://saintjohnchurchmiddletown.com/default.aspx has markup that exercises "reconstruct the active formatting elements" a lot
  599. # [12:32] <hsivonen> and they actually close </font> eventually!
  600. # [12:33] <annevk> heh
  601. # [12:33] <abarth> hsivonen: hum... that one definitely needs off-the-main-thread parsing
  602. # [12:33] <annevk> they expect logic and get HTML instead ;p
  603. # [12:34] <abarth> ok, bed time for me
  604. # [12:35] <abarth> night all
  605. # [12:35] * abarth is now known as abarth|zZz
  606. # [12:43] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 276 seconds)
  607. # [12:44] * Joins: MikeSmith_ (~MikeSmith@EM114-48-191-219.pool.e-mobile.ne.jp)
  608. # [12:46] * Quits: MikeSmith (~MikeSmith@EM114-48-201-182.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
  609. # [12:46] * MikeSmith_ is now known as MikeSmith
  610. # [12:50] * Joins: henrikbjorn (~henrik@86.58.248.50)
  611. # [12:54] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Quit: GarethAdams|Home)
  612. # [13:02] * Quits: david_carlisle (~chatzilla@62.231.145.254) (Remote host closed the connection)
  613. # [13:03] * Joins: workmad3 (~workmad3@cspool86.cs.man.ac.uk)
  614. # [13:03] * Joins: jorlow (~jorlow@nat/google/x-oyvtsveotuquewnl)
  615. # [13:06] <annevk> I'm starting to think that lots of stuff was kept on Node to make the Java case of casting the exception rather than the rule...
  616. # [13:07] <annevk> e.g. there's no reason for attributes to be on Node, and yet it is
  617. # [13:07] <annevk> or namespaceURI, or localName
  618. # [13:13] <jgraham> Oh, that makes more sense than my previous theory that the WG meeting happened in the same convention centre as a hippy gathering and the DOM WG got served the wrong brownies
  619. # [13:18] * Joins: zcorpan_ (~zcorpan@pat.se.opera.com)
  620. # [13:18] <zcorpan_> annevk: i thought fileapi didn't use domexception?
  621. # [13:19] <annevk> ms2ger wants to keep HTML5 and DOM Core consistent
  622. # [13:19] * Quits: estes (~aestes@76-220-34-58.lightspeed.sntcca.sbcglobal.net) (Quit: estes)
  623. # [13:24] <annevk> jgraham, :)
  624. # [13:24] <annevk> hopefully we can undue some of the Java damage
  625. # [13:25] <annevk> I suppose the web will disagree, but I'm hoping nobody relies on namespaceURI returning null for e.g. Document and that undefined will be fine too
  626. # [13:33] <zcorpan_> if (!('namespaceURI' in document)) { breakPage(); }
  627. # [13:38] * Joins: smaug____ (~chatzilla@vallila-gw.hupnet.helsinki.fi)
  628. # [13:49] <annevk> yeah, those people
  629. # [13:49] * Joins: Ms2ger (~Ms2ger@91.181.38.15)
  630. # [13:55] * Quits: macpherson (~macpherso@nat/google/x-ahigvnkbqzvdoapy) (Remote host closed the connection)
  631. # [13:55] * Joins: macpherson (~macpherso@nat/google/x-mmaudlkfkqgwbmuc)
  632. # [13:55] * Joins: boblet (~boblet@p2103-ipbf21osakakita.osaka.ocn.ne.jp)
  633. # [14:04] * Quits: mokush (~quassel@79.116.74.55) (Read error: Connection reset by peer)
  634. # [14:05] * Quits: ZombieL (~e@c-36d471d5.014-169-73746f28.cust.bredbandsbolaget.se) (Ping timeout: 265 seconds)
  635. # [14:06] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  636. # [14:07] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  637. # [14:14] * Joins: bentruyman (~bentruyma@c-67-163-43-249.hsd1.il.comcast.net)
  638. # [14:15] * Quits: bentruyman (~bentruyma@c-67-163-43-249.hsd1.il.comcast.net) (Client Quit)
  639. # [14:19] * Quits: matjas (~matjas@ip-81-11-180-54.dsl.scarlet.be) (Read error: Connection reset by peer)
  640. # [14:23] * Joins: matjas_ (~matjas@ip-213-49-112-131.dsl.scarlet.be)
  641. # [14:27] * Quits: 92AAA30VZ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
  642. # [14:30] * matjas_ is now known as matjas
  643. # [14:34] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
  644. # [14:34] * Joins: boaz (~boaz@64.119.159.231)
  645. # [14:35] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  646. # [14:35] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Client Quit)
  647. # [14:35] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  648. # [14:36] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  649. # [14:36] * Joins: mischat (~mischat@customer47579.109.kt.cust.t-mobile.co.uk)
  650. # [14:40] * Joins: karlushi (~karlushi@fw.vdl2.ca)
  651. # [14:41] * Quits: mischat (~mischat@customer47579.109.kt.cust.t-mobile.co.uk) (Ping timeout: 240 seconds)
  652. # [14:54] * Quits: zdenekkostal (~Miranda@ip-89-102-182-215.net.upcbroadband.cz) (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
  653. # [14:56] * Quits: smaug____ (~chatzilla@vallila-gw.hupnet.helsinki.fi) (Ping timeout: 240 seconds)
  654. # [14:56] * Joins: BlurstOfTimes (~blurstoft@168.203.117.112)
  655. # [14:58] * Joins: Necrathex (~bleptop@209.Red-213-96-43.staticIP.rima-tde.net)
  656. # [15:02] * Quits: Necrathex (~bleptop@209.Red-213-96-43.staticIP.rima-tde.net) (Client Quit)
  657. # [15:03] * Quits: daedb_ (~daed@78-72-108-100-no178.tbcn.telia.com) (Remote host closed the connection)
  658. # [15:03] * Joins: plainhao (~plainhao@mail.xbiotica.com)
  659. # [15:07] * Quits: karlushi (~karlushi@fw.vdl2.ca) (Quit: Leaving)
  660. # [15:08] * Joins: mpt (~mpt@canonical/mpt)
  661. # [15:11] * Joins: karlushi (~karlushi@fw.vdl2.ca)
  662. # [15:15] * Joins: romeo_ (~romeo__@x1-6-00-02-44-60-6c-8e.k233.webspeed.dk)
  663. # [15:18] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
  664. # [15:24] * Quits: henrikbjorn (~henrik@86.58.248.50) (Quit: henrikbjorn)
  665. # [15:31] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
  666. # [15:31] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  667. # [15:32] * Joins: mpt (~mpt@canonical/mpt)
  668. # [15:38] * Quits: Rik` (~Rik`@mozilla-paris-222-194.cnt.nerim.net) (Read error: Connection reset by peer)
  669. # [15:38] * Joins: Rik` (~Rik`@mozilla-paris-222-194.cnt.nerim.net)
  670. # [15:39] * Quits: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net) (Quit: othermaciej)
  671. # [15:39] * Joins: aroben (~aroben@unaffiliated/aroben)
  672. # [15:40] * Joins: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net)
  673. # [15:44] * Joins: henrikbjorn (~henrik@95.142.153.196)
  674. # [15:47] * Quits: Ankheg (~Miranda@fs91-201-3-30.dubna-net.ru) (Read error: Connection reset by peer)
  675. # [15:47] * Quits: henrikbjorn (~henrik@95.142.153.196) (Read error: Connection reset by peer)
  676. # [15:47] * Joins: henrikbjorn (~henrik@95.142.153.196)
  677. # [15:50] * Joins: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30)
  678. # [15:50] * Quits: henrikbjorn (~henrik@95.142.153.196) (Read error: Connection reset by peer)
  679. # [15:51] * Joins: henrikbjorn (~henrik@95.142.153.196)
  680. # [15:54] * Quits: henrikbjorn (~henrik@95.142.153.196) (Read error: Connection reset by peer)
  681. # [15:55] * Quits: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net) (Quit: othermaciej)
  682. # [15:56] * Joins: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net)
  683. # [15:56] * Quits: s0enke (~soenke@naturalborngrillers.org) (Quit: Coyote finally caught me)
  684. # [16:04] <boblet> any microdata ppl around? random q for ya: why does itemtype not imply itemscope?
  685. # [16:04] <hsivonen> btoa(unescape(encodeURIComponent("\u0000")))
  686. # [16:05] <hsivonen> for the record, that's how to take a JS string and base64-encode the UTF-8 bytes
  687. # [16:05] <zcorpan_> boblet: iirc it did before (it was just called item="" or item="type"), but from the usability study it turned out to be confusing and having two attributes was better understood
  688. # [16:06] <boblet> zcorpan_: aah thanks. yeah I guessed ease of learning/parsing, nice to know I’m not too far off :)
  689. # [16:08] <annevk> did my bug just get hijacked: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10619 ?
  690. # [16:08] <annevk> it clearly says "other" in "component"...
  691. # [16:08] <annevk> oh well
  692. # [16:08] * Joins: jrgarrison (~garrison@wikiotics/jrgarrison)
  693. # [16:09] <hsivonen> MikeSmith: ^
  694. # [16:19] * Quits: matijsb (~matijs@host90-152-76-118.ipv4.regusnet.com) (Quit: Zzzzz)
  695. # [16:20] * MikeSmith takes a lookg
  696. # [16:20] <karlushi> annevk, Bugzilla is confusing in terms of UI and indeed people read too quick sometimes. the Comment #1 seems to be out of scope indeed.
  697. # [16:20] <MikeSmith> btw, I will be turning off all Cc'ing of bug mail to the public-html list
  698. # [16:20] <MikeSmith> PhilippJ is right
  699. # [16:21] * Joins: paul_irish (~paul_iris@c-76-21-40-62.hsd1.ca.comcast.net)
  700. # [16:21] <MikeSmith> we need to find better ways to help WG members stay informed about bugs
  701. # [16:21] <annevk> ideally we'd use public-html for technical discussion
  702. # [16:21] <annevk> but that might be too high a bar
  703. # [16:21] <hsivonen> looks like Gecko doesn't support DONE property on xhr
  704. # [16:21] <hsivonen> need to use 4
  705. # [16:22] <hsivonen> so the examples in the spec don't work
  706. # [16:22] <annevk> I just changed those to use DONE
  707. # [16:22] <annevk> Opera doesn't support it either
  708. # [16:22] <hsivonen> annevk: I've sent a couple of technical emails. let's see how that goes
  709. # [16:22] <karlushi> MikeSmith, something that could be helpful but would take a lot more time and resources is a weekly summary of the bugs
  710. # [16:22] <annevk> I'd appreciate if people start fixing their bugs in http://tc.labs.opera.com/apis/XMLHttpRequest
  711. # [16:23] <MikeSmith> annevk: I don't know what you mean by hijacked -- history of changes to the bug doen't show anything changing in component - http://www.w3.org/Bugs/Public/show_activity.cgi?id=10619
  712. # [16:23] <hsivonen> annevk: anyway, on a more positive note, \0 and CR aren't tampered with
  713. # [16:23] <hsivonen> annevk: http://hsivonen.iki.fi/test/moz/xhr-text.html
  714. # [16:24] <annevk> MikeSmith, oh, nothing like that happened
  715. # [16:24] <MikeSmith> karlushi: probably for some people, but a lot of other people would still not read it
  716. # [16:24] <annevk> hsivonen, cool, I should add that to the testsuite
  717. # [16:24] <annevk> the only interesting bugs are those that affect the big picture
  718. # [16:24] <annevk> and those are no longer filed, afaict
  719. # [16:25] <hsivonen> my priorities probably differ from the priorities of Web developers
  720. # [16:25] <hsivonen> I care more about \0 and CR
  721. # [16:25] <MikeSmith> annevk, hsivonen - just wondering what if anything requires my attention here -- thought Henri was pinging me about that bug
  722. # [16:25] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
  723. # [16:25] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
  724. # [16:26] <annevk> MikeSmith, I was complaining about the comment being added
  725. # [16:26] * Quits: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net) (Quit: othermaciej)
  726. # [16:26] <annevk> MikeSmith, you can go back to sleep :)
  727. # [16:26] <hsivonen> MikeSmith: is it permitted to use that bugzilla component for developing specs that aren't yet at the W3C?
  728. # [16:26] <karlushi> annevk, MikeSmith : In the current design of Bugzilla, what are the labels which are useless? I see things like WhiteBoard
  729. # [16:26] * Joins: davidwalsh (~davidwals@75-134-27-91.dhcp.mdsn.wi.charter.com)
  730. # [16:27] <karlushi> MikeSmith, indeed some people would not read it. :/
  731. # [16:27] * Joins: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net)
  732. # [16:27] <annevk> karlushi, for the HTML WG?
  733. # [16:27] <karlushi> annevk, yes only for the htmlwg bugzilla
  734. # [16:27] <annevk> karlcow, version, platform, target milestone, QA contact
  735. # [16:28] <annevk> importance prolly only needs the text label, not the p1-5
  736. # [16:28] <MikeSmith> hsivonen: yes, it absolutely is.. we set up that bugzilla product for people who want to comment on any online version of the spec
  737. # [16:28] * Quits: erlehmann (~erlehmann@89.204.137.102) (Ping timeout: 265 seconds)
  738. # [16:29] <hsivonen> MikeSmith: thanks. I guess shelley isn't aware
  739. # [16:29] <MikeSmith> yeah, well
  740. # [16:31] <MikeSmith> I leave it to Hixie or anybody else who wants to respond there to clarify that if they want
  741. # [16:31] * Joins: daedb (~daed@78-72-108-100-no178.tbcn.telia.com)
  742. # [16:32] * Quits: Ms2ger (~Ms2ger@91.181.38.15) (Ping timeout: 252 seconds)
  743. # [16:34] <MikeSmith> (not that I'm saying that it actually needs any explicit clarification)
  744. # [16:37] * Joins: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net)
  745. # [16:39] * Joins: chronos (~quassel@unaffiliated/chronos)
  746. # [16:39] <karlushi> http://www.symphonious.net/2010/09/12/content-types-matter/
  747. # [16:39] * Quits: davidwalsh (~davidwals@75-134-27-91.dhcp.mdsn.wi.charter.com) (Quit: Reading http://davidwalsh.name)
  748. # [16:40] * Joins: davidwalsh (~davidwals@75-134-27-91.dhcp.mdsn.wi.charter.com)
  749. # [16:40] * Quits: nessy (~Adium@124-168-60-18.dyn.iinet.net.au) (Quit: Leaving.)
  750. # [16:41] * Joins: erlehmann (~erlehmann@89.204.137.112)
  751. # [16:41] <zcorpan_> Tivoli Access Manager should have used the same sniffing algorithm as browsers (although it might not have helped in that case since <script src> is a specific context that Tivoli Access Manager might not know about)
  752. # [16:43] <hsivonen> zcorpan_: indeed
  753. # [16:43] <hsivonen> I like this bit: "Tivoli Access Manager is an interesting and powerful beast that never seems to be configured right."
  754. # [16:43] <hsivonen> back in 2003 when I was exposed to Tivoli Access Manager, it had a severe pipelining bug
  755. # [16:44] <hsivonen> if you made pipelined requests, it would return the right set of responses, but the responses would be to the wrong requests
  756. # [16:44] <hsivonen> so requesting a bunch of images made the images switch places on the page
  757. # [16:45] * Quits: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net) (Quit: othermaciej)
  758. # [16:45] * Joins: nessy (~Adium@124-168-60-18.dyn.iinet.net.au)
  759. # [16:46] <zcorpan_> heh
  760. # [16:46] <karlushi> http randomizer? :)
  761. # [16:47] <zcorpan_> wonder if we have that in our regression testing system (sometimes it seems like it)
  762. # [16:48] * Joins: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net)
  763. # [16:49] * Quits: paul_irish (~paul_iris@c-76-21-40-62.hsd1.ca.comcast.net) (Remote host closed the connection)
  764. # [16:52] * Quits: nessy (~Adium@124-168-60-18.dyn.iinet.net.au) (Quit: Leaving.)
  765. # [16:54] * Joins: paul_irish (~paul_iris@66.109.104.21)
  766. # [16:55] * Joins: FireFly (~firefly@unaffiliated/firefly)
  767. # [16:58] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  768. # [17:00] * Joins: henrikbjorn (~henrik@c83-249-72-254.bredband.comhem.se)
  769. # [17:03] * Quits: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl) (Quit: Disconnected...)
  770. # [17:04] * Quits: rimantas (~rimliu@lan-84-240-20-219.vln.skynet.lt) (Quit: Leaving)
  771. # [17:06] <annevk> hmm, should DOM Core have contains()?
  772. # [17:10] <hsivonen> fwiw, I think COM / C++ is also to blame for "everything on Node" design. not just Java.
  773. # [17:11] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Ping timeout: 276 seconds)
  774. # [17:11] * Joins: nattokirai (~nattokira@209.118.182.194)
  775. # [17:12] * Quits: nattokirai (~nattokira@209.118.182.194) (Client Quit)
  776. # [17:13] * Joins: hamcore (rhythm@unaffiliated/msmosso)
  777. # [17:13] <MikeSmith> is Node perceived as a negative reaction against Java?
  778. # [17:14] <annevk> well, my theory was that lots of stuff was put on Node to reduce the need for casting in Java
  779. # [17:14] <annevk> e.g. namespaceURI, localName, the works
  780. # [17:14] <Philip`> MikeSmith: Are you talking about the DOM Node interface, or Node.js?
  781. # [17:15] <hsivonen> also for reduced need to call QueryInterface in COM
  782. # [17:15] <MikeSmith> oh
  783. # [17:15] <MikeSmith> Philip`: sorry, I misunderstoo
  784. # [17:15] <MikeSmith> d
  785. # [17:15] <MikeSmith> ignore me
  786. # [17:15] * Quits: peol_ (~peol@unaffiliated/peol) (Quit: Leaving)
  787. # [17:16] * Quits: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net) (Quit: zzzzz)
  788. # [17:21] * Joins: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net)
  789. # [17:28] * Joins: dglazkov (~dglazkov@nat/google/x-zpqeaowczcsqzwip)
  790. # [17:30] <zcorpan_> hsivonen: iirc i have suggested not reconstructing on spaces before (and old gecko ignored linebreaks) although Hixie said the spec is the way it is for compat but didn't have a list of urls
  791. # [17:31] <zcorpan_> hsivonen: i've also seen author confusion at sitepoint forums about reconstructing for whitespace
  792. # [17:31] * Quits: Steve_B (~chatzilla@gatej.thls.bbc.co.uk) (Remote host closed the connection)
  793. # [17:32] * Joins: jgornick (~joe@199.199.212.242)
  794. # [17:33] <hsivonen> zcorpan_: having to have it that way for compat seems odd
  795. # [17:34] <hsivonen> zcorpan_: what are people confused about on sitepoint? I thought the sitepoint folks would have clean enough code not to see it. ;-)
  796. # [17:34] * Quits: plainhao (~plainhao@mail.xbiotica.com) (Read error: Operation timed out)
  797. # [17:34] * Parts: hamcore (rhythm@unaffiliated/msmosso)
  798. # [17:35] <zcorpan_> someone had typoed </a> as <a/> and went WTF about the resulting DOM in webkit and new gecko
  799. # [17:35] <hsivonen> I see
  800. # [17:35] * Joins: plainhao (~plainhao@mail.xbiotica.com)
  801. # [17:40] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
  802. # [17:43] * Joins: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net)
  803. # [17:46] * Quits: jacobolu_ (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net) (Ping timeout: 252 seconds)
  804. # [17:51] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  805. # [17:56] * Quits: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net) (Quit: zzzzz)
  806. # [17:57] <hober> TabAtkins: made several changes to http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-41 over the weekend--added a use case (thanks hsivonen), rejiggered various other bits.
  807. # [17:58] * Quits: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net) (Quit: othermaciej)
  808. # [17:59] * Joins: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net)
  809. # [18:05] * Joins: zdenekkostal (~Miranda@ip-89-102-182-215.net.upcbroadband.cz)
  810. # [18:06] * Quits: paul_irish (~paul_iris@66.109.104.21) (Remote host closed the connection)
  811. # [18:07] * Quits: zdenekkostal (~Miranda@ip-89-102-182-215.net.upcbroadband.cz) (Client Quit)
  812. # [18:08] * Joins: robreact (~chatzilla@smtp1bos1.globalmediaxchange.com)
  813. # [18:10] * Joins: paul_irish (~paul_iris@nat/google/x-usmnhgvtfgqyswae)
  814. # [18:12] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Read error: Connection timed out)
  815. # [18:13] * Joins: nattokirai (~nattokira@nat/mozilla/x-fgnnojgtrwtjsvpq)
  816. # [18:21] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  817. # [18:23] * Quits: mihaip (~mihaip@nat/google/x-lhifdpxxdwlwodrb) (Quit: mihaip)
  818. # [18:24] * Quits: paul_irish (~paul_iris@nat/google/x-usmnhgvtfgqyswae) (Read error: Connection reset by peer)
  819. # [18:25] * Joins: paul_irish (~paul_iris@nat/google/x-hsnrkbxexormjklk)
  820. # [18:25] * Quits: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net) (Ping timeout: 252 seconds)
  821. # [18:27] * Joins: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net)
  822. # [18:27] * Joins: mihaip (~mihaip@nat/google/x-jwpxovpstytvlfhp)
  823. # [18:29] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  824. # [18:32] * Joins: jennb (~jennb@74.125.59.65)
  825. # [18:39] <zcorpan_> if we're going to change the handshake in incompatible ways again, i hope we make it more straightforward to implement so that articles like these don't need to be written http://deusty.blogspot.com/2010/09/websocket-draft-76-algorithm-example.html
  826. # [18:40] * Joins: ap (~ap@17.246.17.176)
  827. # [18:40] * Quits: Phae (~Phae@chimera.macmillan.com) (Quit: Leaving.)
  828. # [18:45] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
  829. # [18:45] * Quits: [newbie] (~zalan@catv-89-135-140-7.catv.broadband.hu)
  830. # [18:46] * Quits: MikeSmith (~MikeSmith@EM114-48-191-219.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
  831. # [18:46] * Joins: smaug____ (~chatzilla@cs181063178.pp.htv.fi)
  832. # [18:48] * Quits: henrikbjorn (~henrik@c83-249-72-254.bredband.comhem.se) (Remote host closed the connection)
  833. # [18:58] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
  834. # [18:59] <TabAtkins> hsivonen: Commented on the <p><figure> bug with support.
  835. # [19:00] <hsivonen> TabAtkins: thanks
  836. # [19:00] <hsivonen> TabAtkins: fwiw, the private feedback I've gotten (1 person) was about the same
  837. # [19:01] * Quits: antti_s (~antti@173-203-97-98.static.cloud-ips.com) (*.net *.split)
  838. # [19:02] * Joins: antti_s (~antti@173-203-97-98.static.cloud-ips.com)
  839. # [19:04] * Joins: MikeSmith (~MikeSmith@EM114-48-50-95.pool.e-mobile.ne.jp)
  840. # [19:06] * Joins: dbaron (~dbaron@nat/mozilla/x-txunwyzsehezdaml)
  841. # [19:07] * Quits: robreact (~chatzilla@smtp1bos1.globalmediaxchange.com) (Read error: Connection reset by peer)
  842. # [19:08] * Quits: mat_t (~mattomasz@91.189.88.12) (Quit: This computer has gone to sleep)
  843. # [19:09] * Joins: mdelaney (~mdelaney@CMU-421941.WV.CC.CMU.EDU)
  844. # [19:09] * Quits: boblet (~boblet@p2103-ipbf21osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  845. # [19:11] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Read error: Operation timed out)
  846. # [19:12] * Quits: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net) (Ping timeout: 252 seconds)
  847. # [19:13] * Joins: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net)
  848. # [19:15] * Quits: workmad3 (~workmad3@cspool86.cs.man.ac.uk) (Remote host closed the connection)
  849. # [19:20] * Joins: roc (~roc@nat/mozilla/x-xdrunenaifcrtqve)
  850. # [19:20] * Joins: aroben_ (~aroben@unaffiliated/aroben)
  851. # [19:21] * Quits: weinig (~weinig@c-76-102-3-160.hsd1.ca.comcast.net) (Quit: weinig)
  852. # [19:21] * Quits: smaug____ (~chatzilla@cs181063178.pp.htv.fi) (Ping timeout: 276 seconds)
  853. # [19:22] * Quits: aroben (~aroben@unaffiliated/aroben) (Read error: Connection reset by peer)
  854. # [19:26] * Quits: aroben_ (~aroben@unaffiliated/aroben) (Read error: No route to host)
  855. # [19:26] * Joins: aroben (~aroben@unaffiliated/aroben)
  856. # [19:27] <hober> I've always emulated <figure> with <div>, not <span>
  857. # [19:27] <hober> so it seems weird to me to want <figure> as a child of <p>
  858. # [19:27] <TabAtkins> I know that I've written plain-text where I have figures inside of paragraphs.
  859. # [19:28] <TabAtkins> In fact, I do it regularly in technical emails, where I'll have a sample of code in the middle of a sentence.
  860. # [19:28] * Quits: MikeSmith (~MikeSmith@EM114-48-50-95.pool.e-mobile.ne.jp) (Quit: The curfew tolls the knell of parting day... the plowman homeward plods his weary way)
  861. # [19:29] * Joins: MikeSmith (~MikeSmith@EM114-48-50-95.pool.e-mobile.ne.jp)
  862. # [19:33] <zcorpan_> TabAtkins: maybe you sometimes also have a list or a table in the middle of a sentence?
  863. # [19:34] <TabAtkins> zcorpan_: Yes, but less commonly. Presumably those have legacy constraints, though.
  864. # [19:35] <annevk> it gets icky when you do <p><figure><ol> though
  865. # [19:35] * Joins: Peter- (~peter@53516FE0.cable.casema.nl)
  866. # [19:35] <annevk> or <p><figure><table>
  867. # [19:35] <TabAtkins> Icky in precisely which way? From a spec-writing standpoint, an implemention standpoint, or an authoring standpoint?
  868. # [19:35] <annevk> hsivonen, so would those have to be disallowed? or do you want to make <figure> scoping which seems kind of hackish...
  869. # [19:35] <annevk> all
  870. # [19:36] <annevk> apart from the first, prolly
  871. # [19:36] <annevk> and the second does not matter much either
  872. # [19:36] <TabAtkins> I don't know about authoring. I mean, the fact that <p><ol> wouldn't work but <p><figure><ol> might is *dumb*, but not a *problem*, per se. It's just a stupid platform quirk.
  873. # [19:38] <annevk> it's not dumb, it's confusing as hell
  874. # [19:40] <hober> the way <p> auto-closes is weird, but it's not going away. given that, it seems like new elements should behave like their closest-analog old elements. so <section> auto-closes <p> because <div> does, etc.
  875. # [19:41] <TabAtkins> I prefer, when legacy behavior is retarded, to instead fix the behavior going forward rather than trying to remain consistent with the retarded behavior. Foolish consistency, hobgoblin, little minds, etc.
  876. # [19:42] <hober> we at least want the language to cohere. given that <div> and the other old "block" elements auto-close <p>, as an author I expect <article> to, and would be (even more) weirded out if it didn't.
  877. # [19:43] * Joins: henrikbjorn (~henrik@c83-249-72-254.bredband.comhem.se)
  878. # [19:43] <hober> I mean, I can at least sort-of make sense of the legacy auto-closing. If <article> didn't auto-close <p>, suddenly the weird-but-kinda-makes-sense auto-closing rules are even less predictable
  879. # [19:47] <annevk> I would not say it is "retarded"
  880. # [19:48] <annevk> and I also do not think that having half the features work one way and half the features work another way is a win
  881. # [19:50] <TabAtkins> On the other hand, neither is having all of the features work the wrong way.
  882. # [19:52] * Quits: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk) (Quit: akamike)
  883. # [19:52] * Joins: sicking (~chatzilla@nat/mozilla/x-qrvqoniygombozon)
  884. # [19:53] <paul_irish> annevk: is window.media.matchMedium gone from the spec?
  885. # [19:54] <paul_irish> gone forever? :'(
  886. # [19:54] * Joins: mokush (~quassel@79.116.66.200)
  887. # [19:55] * Quits: jeremyselier (~Jeremy@pro75-4-82-238-200-10.fbx.proxad.net) (Ping timeout: 272 seconds)
  888. # [19:57] <annevk> euh no?
  889. # [19:57] <annevk> we just redesigned the feature
  890. # [20:00] * Joins: smaug____ (~chatzilla@80-186-156-184.elisa-mobile.fi)
  891. # [20:02] * Joins: dave_levin (~dave_levi@nat/google/x-henmjojcxpuklzkq)
  892. # [20:03] <paul_irish> annevk: good good. where can i find the latest ?
  893. # [20:07] * Quits: nattokirai (~nattokira@nat/mozilla/x-fgnnojgtrwtjsvpq) (Quit: nattokirai)
  894. # [20:08] * Quits: Rik` (~Rik`@mozilla-paris-222-194.cnt.nerim.net) (Remote host closed the connection)
  895. # [20:10] <annevk> same draft?
  896. # [20:10] <annevk> it's called matchMedia and lives on window now
  897. # [20:10] <paul_irish> thx
  898. # [20:10] <annevk> http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia
  899. # [20:10] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  900. # [20:18] * Joins: nattokirai (~nattokira@nat/mozilla/x-xawlnpgaryrvxdru)
  901. # [20:20] * Joins: gerred (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net)
  902. # [20:21] * Quits: nattokirai (~nattokira@nat/mozilla/x-xawlnpgaryrvxdru) (Client Quit)
  903. # [20:24] * Quits: jrgarrison (~garrison@wikiotics/jrgarrison) (Ping timeout: 276 seconds)
  904. # [20:25] * Joins: jrgarrison (~garrison@wikiotics/jrgarrison)
  905. # [20:27] <zcorpan_> does someone have an example at hand of a utf-8 byte sequence of a 3 or 4-byte overlong form?
  906. # [20:27] * Quits: henrikbjorn (~henrik@c83-249-72-254.bredband.comhem.se) (Remote host closed the connection)
  907. # [20:27] <TabAtkins> What's an "overlong form"? Anything that's 3 or 4 bytes in utf-8?
  908. # [20:27] <zcorpan_> "a sequence that decodes to a value that should use a shorter sequence"
  909. # [20:28] * Joins: reni__home (~reni@5403079D.catv.pool.telekom.hu)
  910. # [20:28] <TabAtkins> Oh, gotcha. So called because there are boundary conditions where a value could be validly written with or without the extra byte. Ok.
  911. # [20:28] <annevk> zcorpan_, they're easy to construct from http://en.wikipedia.org/wiki/UTF-8
  912. # [20:29] <TabAtkins> Just look at the end of the ranges for any given byte-length. Anything sufficiently close to the end should be capable of being rewritten as an overlong form, though I'd have to do some work to actually determine what "sufficiently close" is.
  913. # [20:29] <TabAtkins> Probably just the last one or two of each range.
  914. # [20:30] <annevk> e.g. E0 80 80 80
  915. # [20:30] <TabAtkins> Or, no, you can construct an overlong from from any character, right?
  916. # [20:30] <annevk> that latest 80 is out of range
  917. # [20:30] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  918. # [20:31] <annevk> there's also start of 5 and 6 byte sequences but in theory they ought to be treated as a single invalid byte now, I think
  919. # [20:31] <zcorpan_> annevk: E0 is a 3-byte sequence. you gave a 4-byte sequence...
  920. # [20:32] <annevk> oh sorry
  921. # [20:33] * Quits: boaz (~boaz@64.119.159.231) (Quit: boaz)
  922. # [20:33] <annevk> so there are 3/4 byte overlong forms?
  923. # [20:34] <zcorpan_> i'm not sure
  924. # [20:34] <TabAtkins> Would, say, F0 80 80 60 work? (A space, expanded out to 4 bytes.)
  925. # [20:34] <zcorpan_> TabAtkins: 60 isn't a continuation byte
  926. # [20:35] <TabAtkins> Urgh, right. Sorry. I meant A0
  927. # [20:36] <zcorpan_> thanks
  928. # [20:36] <zcorpan_> seems webkit and gecko turn that into a u+fffd but opera doesn't
  929. # [20:37] <annevk>
  930. # [20:37] <annevk> 0xC0 0x8A
  931. # [20:37] <annevk> 0xE0 0x80 0x8A
  932. # [20:37] <annevk> 0xF0 0x80 0x80 0x8A
  933. # [20:37] <annevk> 0xF8 0x80 0x80 0x80 0x8A
  934. # [20:37] <annevk> 0xFC 0x80 0x80 0x80 0x80 0x8A
  935. # [20:37] <annevk> via http://www.cl.cam.ac.uk/~mgk25/unicode.html
  936. # [20:39] * aroben is now known as aroben|lunch
  937. # [20:40] <hsivonen> annevk: I'd prefer to make <figure> scoping, yes.
  938. # [20:43] * Joins: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  939. # [20:46] <annevk> zcorpan_, I think what you wrote there should be part of the "web UTF-8" spec (or just the UTF-8 spec if everyone can agree on decoding worldwide)
  940. # [20:46] * Joins: Ms2ger (~Ms2ger@91.181.38.15)
  941. # [20:46] <annevk> doesn't really make sense to me to handle UTF-8 decoding specifics as part of HTML5
  942. # [20:46] <zcorpan_> annevk: sure
  943. # [20:47] <Hixie> that would make my life so much easier
  944. # [20:48] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Read error: Connection reset by peer)
  945. # [20:48] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
  946. # [20:48] <Hixie> btw i'm officially on vacation for the next two weeks -- i'll be online some of the time but not always
  947. # [20:48] <annevk> it's also a problem for instance for responseText
  948. # [20:49] <annevk> ooh, have fun
  949. # [20:49] <zcorpan_> starting today?
  950. # [20:49] * Joins: boaz (~boaz@64.119.159.231)
  951. # [20:51] * Joins: nattokirai (~nattokira@nat/mozilla/x-kqmkconoqoxzewoy)
  952. # [20:52] * Quits: jrgarrison (~garrison@wikiotics/jrgarrison) (Quit: Ex-Chat)
  953. # [20:54] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
  954. # [20:54] <MikeSmith> so... Philip Jägenstedt has said in the past that he finds the volume of automated bug notifications on the public-html list and the a11y-tf list to be excessive
  955. # [20:55] <hsivonen> Hixie: have a good vacation
  956. # [20:55] <MikeSmith> Hixie: yeah, enjoy your break
  957. # [20:55] <zcorpan_> +1
  958. # [20:56] <hsivonen> I guess this means I'll have to file my pending mailing list questions as bugs in order to have them on file by the cutoff
  959. # [20:56] * Quits: reni__home (~reni@5403079D.catv.pool.telekom.hu) (Ping timeout: 245 seconds)
  960. # [20:56] * Quits: mpt (~mpt@canonical/mpt) (Quit: Ex-Chat)
  961. # [20:56] * Quits: matjas (~matjas@ip-213-49-112-131.dsl.scarlet.be) (Remote host closed the connection)
  962. # [20:57] <annevk> MikeSmith, maybe email should go to public-html once a bug is resolved/reopened?
  963. # [20:57] <annevk> MikeSmith, though then I guess spam that gets closed as INVALID will be emailed too...
  964. # [20:57] <annevk> hmm
  965. # [20:58] <zcorpan_> some bugs are resolved and reopened lots of times
  966. # [20:59] <MikeSmith> annevk: I'm redirecting it to the issue-tracking list
  967. # [20:59] <MikeSmith> which is where we should have had it going to begin with
  968. # [20:59] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  969. # [21:00] <MikeSmith> having bug notifications going to a technical discussion list is an anti-pattern
  970. # [21:00] <annevk> ah, I'm not on that list
  971. # [21:00] * zcorpan_ would prefer to have no bugmail on public-html
  972. # [21:00] <annevk> I think it's great that bugmail goes to public-webapps
  973. # [21:01] <annevk> but it's a very different kind of bugmail
  974. # [21:01] <annevk> much like it's a very different kind of email that goes to public-webapps
  975. # [21:01] <annevk> you know, technical debate :)
  976. # [21:04] * Quits: peol (~andree@unaffiliated/peol) (Remote host closed the connection)
  977. # [21:05] * aroben|lunch is now known as aroben
  978. # [21:06] <annevk> Ms2ger, zcorpan_, gsnedders, for DOM Core you may not get listed as editor unless you somehow join the WG
  979. # [21:06] <annevk> I thought of adding something like this to the acknowledgments instead
  980. # [21:07] <Ms2ger> Fine with me
  981. # [21:07] <zcorpan_> me too
  982. # [21:07] <annevk> "Many thanks to ms2ger, Simon Pieters, and Geoffrey Sneddon for editing the initial 80% of this specification."
  983. # [21:08] <annevk> s/ms2ger/Ms2ger/ I guess
  984. # [21:08] <Ms2ger> Please :)
  985. # [21:12] * Quits: plainhao (~plainhao@mail.xbiotica.com) (Quit: plainhao)
  986. # [21:13] * Joins: reni__home (~reni@5403079D.catv.pool.telekom.hu)
  987. # [21:13] * Quits: boaz (~boaz@64.119.159.231) (Read error: Connection reset by peer)
  988. # [21:13] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Read error: Connection reset by peer)
  989. # [21:15] * Joins: boaz (~boaz@64.119.159.231)
  990. # [21:15] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
  991. # [21:16] * Joins: portenkirchner (~portenkir@p508953A9.dip.t-dialin.net)
  992. # [21:18] * Quits: portenkirchner (~portenkir@p508953A9.dip.t-dialin.net) (Client Quit)
  993. # [21:18] * Joins: portenkirchner (~portenkir@p508953A9.dip.t-dialin.net)
  994. # [21:18] * Quits: portenkirchner (~portenkir@p508953A9.dip.t-dialin.net) (Client Quit)
  995. # [21:20] * Joins: boaz_ (~boaz@64.119.159.231)
  996. # [21:23] * Joins: apucacao (~apucacao@S010600226b6dbc54.vc.shawcable.net)
  997. # [21:23] * Quits: boaz (~boaz@64.119.159.231) (Ping timeout: 252 seconds)
  998. # [21:23] * boaz_ is now known as boaz
  999. # [21:24] <zcorpan_> wonder how i missed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10343 in opera's impl
  1000. # [21:26] * Quits: apucacao (~apucacao@S010600226b6dbc54.vc.shawcable.net) (Client Quit)
  1001. # [21:29] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  1002. # [21:37] <zcorpan_> wonder how many people will file a bug about "outlinee"
  1003. # [21:39] <Ms2ger> Half a dozen so far?
  1004. # [21:40] <zcorpan_> there were probably half a dozen before bugzilla also
  1005. # [21:42] <MikeSmith> about http://hg.diveintohtml5.org/hgweb.cgi/rev/6067cc62b7016825817aa047cef52bc8ee8d7d5f
  1006. # [21:42] <MikeSmith> I thought that some versions of IE would go into quirks mode if you had anything before the doctype
  1007. # [21:42] <MikeSmith> is that not that case?
  1008. # [21:43] <hsivonen> comments, including bogus one like XML decl, are bad in IE6
  1009. # [21:44] <Rik`> I just discovered http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#script-processing-for
  1010. # [21:44] <zcorpan_> comments, including bogus one except the XML decl (if it's on one line, iirc), are bad in IE7-8 (dunno about 9)
  1011. # [21:44] <Rik`> that's kind of weird to only allow one value for this
  1012. # [21:45] <zcorpan_> Rik`: allow? <script for> is invalid
  1013. # [21:45] <Ms2ger> It's the only value that matters for compat
  1014. # [21:45] <Rik`> zcorpan_: I mean you can only use it for window.onload
  1015. # [21:46] <zcorpan_> except it's not equivalent to window.onload at all
  1016. # [21:47] <Rik`> it's just a "check" to abort if those attributes use a different value ?
  1017. # [21:47] <zcorpan_> yeah
  1018. # [21:48] <Rik`> what's the point ?
  1019. # [21:48] <zcorpan_> compat
  1020. # [21:48] <Rik`> which browsers does that ?
  1021. # [21:49] <zcorpan_> gecko and webkit match the spec, i think, and ie ... i don't know what ie does exactly
  1022. # [21:49] <zcorpan_> opera ignores these currently
  1023. # [21:49] <Rik`> Webkit just added it (http://peter.sh/2010/09/last-week-asynchronous-script-execution-and-gpu-acceleration-by-default/)
  1024. # [21:49] <zcorpan_> the attributes that is
  1025. # [21:50] <zcorpan_> yeah, webkit found they needed it for compat a few months ago
  1026. # [21:50] <zcorpan_> which is why it's in the spec now
  1027. # [21:50] <Rik`> who did invented this ?
  1028. # [21:51] <Rik`> that's completely weird
  1029. # [21:51] <Peter-> apparently comedycentral.com was depending on it
  1030. # [21:51] <zcorpan_> i think ie invented it (but with real events), mozilla implemented a hack for compat with something that was ie-only
  1031. # [21:51] <zcorpan_> and now webkit copied mozilla and that's what's in hte spec
  1032. # [21:52] <Peter-> https://bugs.webkit.org/show_bug.cgi?id=45310#c8
  1033. # [21:52] <Rik`> that's a great exemple of how web content is fucked up
  1034. # [21:53] <zcorpan_> you'll get used to it :)
  1035. # [21:53] <Rik`> well, I think that's the weirdest one I've seen
  1036. # [21:54] <annevk> you don't think <table>test -> test<table> is weird?
  1037. # [21:54] <annevk> or <image> -> <img>
  1038. # [21:54] <Rik`> not that much
  1039. # [21:56] <zcorpan_> should we replace 'This section is non-normative' with 'This section has no conformance requirements'?
  1040. # [22:05] <annevk> yeah maybe
  1041. # [22:05] <annevk> conformance requirements is somewhat clearer than non-normative
  1042. # [22:06] * Joins: jrgarrison (~garrison@ResNet-48-249.resnet.ucsb.edu)
  1043. # [22:06] * Quits: jrgarrison (~garrison@ResNet-48-249.resnet.ucsb.edu) (Changing host)
  1044. # [22:06] * Joins: jrgarrison (~garrison@wikiotics/jrgarrison)
  1045. # [22:06] <zcorpan_> i remember at first when i read specs, i didn't understand what normative/informative/non-normative meant
  1046. # [22:07] <annevk> same, i recall being somewhat proud when I got it :)
  1047. # [22:10] * Joins: dpranke (~Adium@nat/google/x-mxbfddkcgcyaavus)
  1048. # [22:19] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1049. # [22:25] * abarth|zZz is now known as abarth
  1050. # [22:26] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
  1051. # [22:26] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1052. # [22:27] <zcorpan_> i remember thinking it was stupid terminology :P
  1053. # [22:28] <annevk> heh
  1054. # [22:29] <annevk> I guess DOM Core does not need to say much about baseURI
  1055. # [22:29] <annevk> hmm, it's on Node again o_O
  1056. # [22:29] <annevk> oh, and it's even readonly...
  1057. # [22:36] <zcorpan_> iirc baseURI needs to be on Node, or at least Element
  1058. # [22:37] <annevk> Element/Document would make sense to me
  1059. # [22:37] * Quits: mokush (~quassel@79.116.66.200) (Read error: Connection reset by peer)
  1060. # [22:39] <annevk> I guess they should be set at the markup language level
  1061. # [22:39] <annevk> so DOM Core just needs to provide some hooks somehow
  1062. # [22:44] <annevk> DOM3Core doesn't even define baseURI in detail for the various node types... I guess it could just inherit, but what about DocumentFragment?
  1063. # [22:44] <zcorpan_> annevk: i didn't realize DOMException inherited from Error when i added name and message to the spec
  1064. # [22:45] * Joins: wakaba_ (~wakaba_@134.157.197.113.dy.bbexcite.jp)
  1065. # [22:45] <annevk> k
  1066. # [22:46] <annevk> I filed the relevant bugs on Web IDL to redo the way we do exceptions
  1067. # [22:48] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
  1068. # [22:49] * Joins: matjas (~matjas@91.182.243.59)
  1069. # [22:49] * Quits: jrgarrison (~garrison@wikiotics/jrgarrison) (Ping timeout: 276 seconds)
  1070. # [22:49] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
  1071. # [22:53] * Joins: jrgarrison (~garrison@wikiotics/jrgarrison)
  1072. # [22:57] * Joins: mdelaney_ (~mdelaney@CMU-421941.WV.CC.CMU.EDU)
  1073. # [22:57] * Quits: mdelaney (~mdelaney@CMU-421941.WV.CC.CMU.EDU) (Read error: Connection reset by peer)
  1074. # [22:57] * mdelaney_ is now known as mdelaney
  1075. # [22:57] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Remote host closed the connection)
  1076. # [22:58] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Quit: annevk)
  1077. # [23:00] * Quits: mdelaney (~mdelaney@CMU-421941.WV.CC.CMU.EDU) (Client Quit)
  1078. # [23:01] <AryehGregor> Hmm, as of last update http://aryeh.name/tests/reflection.html gives a sad tab in Chrome dev. :(
  1079. # [23:02] * Joins: weinig (~weinig@17.203.14.138)
  1080. # [23:04] * Quits: jrgarrison (~garrison@wikiotics/jrgarrison) (Ping timeout: 245 seconds)
  1081. # [23:05] * Quits: aroben (~aroben@unaffiliated/aroben) (Read error: Connection reset by peer)
  1082. # [23:06] * Quits: ROBOd (~robod@89.123.173.167) (Quit: .)
  1083. # [23:06] * Joins: mdelaney (~mdelaney@CMU-421941.WV.CC.CMU.EDU)
  1084. # [23:06] * Joins: jrgarrison (~garrison@wikiotics/jrgarrison)
  1085. # [23:11] * Quits: jrgarrison (~garrison@wikiotics/jrgarrison) (Ping timeout: 240 seconds)
  1086. # [23:18] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1087. # [23:18] * Quits: chronos (~quassel@unaffiliated/chronos) (Remote host closed the connection)
  1088. # [23:19] * Quits: dpranke (~Adium@nat/google/x-mxbfddkcgcyaavus) (Quit: Leaving.)
  1089. # [23:20] * Quits: smaug____ (~chatzilla@80-186-156-184.elisa-mobile.fi) (Ping timeout: 265 seconds)
  1090. # [23:23] * Quits: zcorpan_ (~zcorpan@pat.se.opera.com) (Quit: zcorpan_)
  1091. # [23:24] * Quits: othermaciej (~mjs@c-69-181-196-33.hsd1.ca.comcast.net) (Quit: othermaciej)
  1092. # [23:25] * Quits: BlurstOfTimes (~blurstoft@168.203.117.112) (Remote host closed the connection)
  1093. # [23:33] * Joins: murz (~mmurraywa@wcproxy.msnbc.com)
  1094. # [23:37] * Quits: matjas (~matjas@91.182.243.59) (Remote host closed the connection)
  1095. # [23:39] * Joins: dpranke (~Adium@nat/google/x-hmmdpwepauxmnmkb)
  1096. # [23:39] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  1097. # [23:46] * Quits: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30) (Quit: eric_carlson)
  1098. # [23:52] * Joins: mpt (~mpt@canonical/mpt)
  1099. # [23:54] * Joins: nessy (~Adium@124-168-60-18.dyn.iinet.net.au)
  1100. # [23:56] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  1101. # [23:58] * Quits: nattokirai (~nattokira@nat/mozilla/x-kqmkconoqoxzewoy) (Quit: nattokirai)
  1102. # [23:59] * Quits: wakaba_ (~wakaba_@134.157.197.113.dy.bbexcite.jp) (Quit: Leaving...)
  1103. # Session Close: Tue Sep 14 00:00:00 2010

The end :)