/irc-logs / freenode / #whatwg / 2009-10-20 / end

Options:

  1. # Session Start: Tue Oct 20 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:01] * Quits: jdouglas (n=jason@nat09.metaweb.com)
  4. # [00:01] * Joins: doublec_ (n=doublec@203.97.204.82)
  5. # [00:02] * Quits: doublec_ (n=doublec@203.97.204.82) (Client Quit)
  6. # [00:02] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  7. # [00:02] * Joins: doublec_ (n=doublec@203.97.204.82)
  8. # [00:02] * Joins: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
  9. # [00:03] * Quits: doublec_ (n=doublec@203.97.204.82) (Client Quit)
  10. # [00:16] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  11. # [00:16] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  12. # [00:17] * Joins: BlurstOf_ (n=blurstof@75.150.78.69)
  13. # [00:18] * Joins: sylvaing (n=sylvaing@nat/microsoft/x-osrjasihtnodifph)
  14. # [00:19] * Joins: BlurstO__ (n=blurstof@168.203.103.101)
  15. # [00:21] * Quits: BlurstOf_ (n=blurstof@75.150.78.69) (Read error: 60 (Operation timed out))
  16. # [00:25] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  17. # [00:28] * Quits: BlurstO__ (n=blurstof@168.203.103.101) (Read error: 131 (Connection reset by peer))
  18. # [00:28] * Joins: BlurstOf_ (n=blurstof@75.150.78.69)
  19. # [00:29] * Quits: sylvaing (n=sylvaing@nat/microsoft/x-osrjasihtnodifph) (Read error: 60 (Operation timed out))
  20. # [00:30] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 113 (No route to host))
  21. # [00:30] * lmorchard|away is now known as lmorchard
  22. # [00:30] * Joins: BlurstO__ (n=blurstof@168.203.117.66)
  23. # [00:32] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) (Read error: 104 (Connection reset by peer))
  24. # [00:32] * Joins: Hixie (i=ianh@trivini.no)
  25. # [00:34] * Joins: jdouglas (n=jason@nat11.metaweb.com)
  26. # [00:35] * Joins: dglazkov (n=dglazkov@nat/google/x-hzeaojyswzsfxals)
  27. # [00:36] * Joins: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
  28. # [00:37] * Quits: BlurstO__ (n=blurstof@168.203.117.66) ("Leaving...")
  29. # [00:45] * Quits: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
  30. # [00:47] * Quits: BlurstOf_ (n=blurstof@75.150.78.69) (Read error: 110 (Connection timed out))
  31. # [01:00] * Quits: jdouglas (n=jason@nat11.metaweb.com)
  32. # [01:01] * Joins: MikeSmith (n=MikeSmit@EM114-48-5-97.pool.e-mobile.ne.jp)
  33. # [01:03] * Joins: jdouglas (n=jason@nat11.metaweb.com)
  34. # [01:03] * Quits: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  35. # [01:11] * Joins: MikeSmithX (n=MikeSmit@EM114-48-54-222.pool.e-mobile.ne.jp)
  36. # [01:21] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  37. # [01:22] * Quits: jwalden (n=waldo@nat/mozilla/x-hpyfedshymeivufj) (Read error: 60 (Operation timed out))
  38. # [01:26] * Joins: jwalden (n=waldo@63.245.220.240)
  39. # [01:27] * Quits: MikeSmithX (n=MikeSmit@EM114-48-54-222.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  40. # [01:28] * Quits: MikeSmith (n=MikeSmit@EM114-48-5-97.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  41. # [01:28] * Joins: MikeSmith (n=MikeSmit@114.48.54.222)
  42. # [01:29] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  43. # [01:37] * Quits: jdouglas (n=jason@nat11.metaweb.com)
  44. # [01:39] * Joins: jdouglas (n=jason@nat09.metaweb.com)
  45. # [01:39] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  46. # [01:40] * Joins: cpharmston (n=cpharmst@68.48.43.198)
  47. # [01:45] * Joins: yutak_home (n=kee@61.117.6.79)
  48. # [01:48] * Joins: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  49. # [01:48] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  50. # [01:51] * Quits: jdouglas (n=jason@nat09.metaweb.com)
  51. # [01:52] * Quits: cpharmston (n=cpharmst@68.48.43.198) ("Leaving.")
  52. # [02:06] * Quits: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  53. # [02:11] <Hixie> sweet mother of kittens
  54. # [02:11] <Hixie> i sure hope zcorpan and hsivonen are sure about this
  55. # [02:14] * Joins: fishd (n=darin@nat/google/x-hfvaczzivcafbizl)
  56. # [02:21] * Joins: erlehmann_ (n=erlehman@82.113.106.0)
  57. # [02:22] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  58. # [02:29] * Quits: dglazkov (n=dglazkov@nat/google/x-hzeaojyswzsfxals)
  59. # [02:30] * Joins: gsnedders (n=gsnedder@c83-252-236-39.bredband.comhem.se)
  60. # [02:30] * Joins: wakaba_ (n=wakaba_@122.221.184.68)
  61. # [02:30] * Quits: bgalbraith (n=bgalbrai@palm-64-28-152-140.palm.com)
  62. # [02:30] * Quits: wakaba_ (n=wakaba_@122.221.184.68) (Client Quit)
  63. # [02:31] * Joins: wakaba_ (n=wakaba_@122.221.184.68)
  64. # [02:35] * Joins: sylvaing (n=sylvaing@c-98-232-19-82.hsd1.wa.comcast.net)
  65. # [02:35] * Joins: miketaylr (n=miketayl@24.42.95.234)
  66. # [02:36] * Quits: miketaylr (n=miketayl@24.42.95.234) (Remote closed the connection)
  67. # [02:36] * Joins: miketaylr (n=miketayl@24.42.95.234)
  68. # [02:37] * Quits: fishd (n=darin@nat/google/x-hfvaczzivcafbizl) (Read error: 110 (Connection timed out))
  69. # [02:38] * Quits: erlehmann (n=erlehman@82.113.121.5) (Read error: 110 (Connection timed out))
  70. # [02:47] * Quits: MikeSmith (n=MikeSmit@114.48.54.222) ("Tomorrow to fresh woods, and pastures new.")
  71. # [02:47] * tkent_afk is now known as tkent
  72. # [02:51] * Quits: yutak_home (n=kee@61.117.6.79) ("Ex-Chat")
  73. # [02:53] * Quits: jwalden (n=waldo@63.245.220.240) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.1.3/20090909051541]")
  74. # [02:53] * Quits: pmuellr (n=pmuellr@69.61.162.35)
  75. # [02:56] * Quits: gsnedders (n=gsnedder@c83-252-236-39.bredband.comhem.se)
  76. # [03:12] * Joins: fishd (n=darin@67.180.164.209)
  77. # [03:26] * Quits: hober (n=ted@unaffiliated/hober) (Remote closed the connection)
  78. # [03:26] * Joins: MikeSmith (n=MikeSmit@EM114-48-225-89.pool.e-mobile.ne.jp)
  79. # [03:27] * Quits: cying (n=cying@70.90.171.153)
  80. # [03:29] * Joins: meoblast001 (n=meoblast@dynamic-acs-24-101-148-112.zoominternet.net)
  81. # [03:30] <meoblast001> HTML5 here?
  82. # [03:33] <Hixie> yep
  83. # [03:33] <Hixie> right here on the mantelpiece
  84. # [03:33] <Hixie> above our roaring fire
  85. # [03:33] <Hixie> do you like the frame?
  86. # [03:34] * Hixie goes off to dinner
  87. # [03:36] <meoblast001> how do you loop audio
  88. # [03:36] <meoblast001> playcount won't do it
  89. # [03:36] * Joins: avidvivid (n=avidvivi@209-180-139-110.phnx.qwest.net)
  90. # [03:36] <meoblast001> i have Firefox
  91. # [03:36] <meoblast001> for GNU/Linux
  92. # [03:40] <MikeSmith> meoblast001: loop attribute?
  93. # [03:40] <meoblast001> there's one of those?
  94. # [03:40] <meoblast001> i only saw playcount
  95. # [03:40] * Joins: nessy (n=Adium@203-158-45-196.dyn.iinet.net.au)
  96. # [03:41] * Quits: sicking (n=chatzill@63.245.220.240) (Read error: 145 (Connection timed out))
  97. # [03:41] <MikeSmith> meoblast001: I think playcount was removed from the spec long ago
  98. # [03:41] <meoblast001> loop is not doing anything
  99. # [03:42] <kinetik> the loop attribute isn't implemented in firefox yet (bug 449157)
  100. # [03:42] <meoblast001> wtf :/
  101. # [03:42] <kinetik> you can get roughly the same behaviour by calling play() when the ended event fires
  102. # [03:43] <kinetik> in script
  103. # [03:49] * Quits: syp (n=syp@lasigpc9.epfl.ch) (Read error: 60 (Operation timed out))
  104. # [03:49] * Joins: syp (n=syp@lasigpc9.epfl.ch)
  105. # [03:53] * Quits: avidvivid (n=avidvivi@209-180-139-110.phnx.qwest.net) (Client Quit)
  106. # [03:53] * Joins: avidvivid (n=avidvivi@209-180-139-110.phnx.qwest.net)
  107. # [04:07] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  108. # [04:08] * Joins: yatil (n=Adium@78.104.102.186)
  109. # [04:10] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  110. # [04:12] <AryehGregor> Hixie, you didn't think it was reasonable for a standard to permit something like X-UA-Compatible where there wouldn't be multiple interoperable implementations in practice. But isn't <object> a lot like that? An HTML page including Flash via <object> is valid HTML, right?
  111. # [04:13] * Quits: MikeSmith (n=MikeSmit@EM114-48-225-89.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  112. # [04:16] * Quits: miketaylr (n=miketayl@24.42.95.234) ("Leaving...")
  113. # [04:23] * Quits: yatil (n=Adium@78.104.102.186) ("Leaving.")
  114. # [04:24] * Joins: miketaylr (n=miketayl@24.42.95.234)
  115. # [04:30] * Joins: svtech (n=stanv@83.228.56.37)
  116. # [04:37] * Quits: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Read error: 60 (Operation timed out))
  117. # [04:38] * Quits: weinig (n=weinig@17.246.17.253)
  118. # [04:39] <meoblast001> kinetik: how do you "play()"?
  119. # [04:40] <meoblast001> javascript?
  120. # [04:40] <kinetik> yes, call play() on the element in script
  121. # [04:41] <meoblast001> kinetik: document.getElementById('object').play();?
  122. # [04:41] <meoblast001> and the event is onabort?
  123. # [04:42] <kinetik> the event is 'ended'
  124. # [04:43] <meoblast001> kinetik: onended?
  125. # [04:43] <roc> you can just write <video ... onended="event.target.play()">
  126. # [04:43] * Joins: paul_irish (n=paul_iri@12.182.97.2)
  127. # [04:44] * Joins: erikvvold (n=erikvvol@S01060024012860e9.gv.shawcable.net)
  128. # [04:54] * Quits: erikvold (n=erikvvol@S01060024012860e9.gv.shawcable.net) (Read error: 110 (Connection timed out))
  129. # [04:59] * Joins: cying (n=cying@adsl-75-18-219-50.dsl.pltn13.sbcglobal.net)
  130. # [05:05] * Joins: Rodi01 (n=irchon@cpe-98-154-249-109.socal.res.rr.com)
  131. # [05:06] * Quits: Rodi01 (n=irchon@cpe-98-154-249-109.socal.res.rr.com) (Remote closed the connection)
  132. # [05:07] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) ("Leaving...")
  133. # [05:11] * Quits: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
  134. # [05:12] * Quits: paul_irish (n=paul_iri@12.182.97.2) (Remote closed the connection)
  135. # [05:12] * Joins: paul_irish (n=paul_iri@12.182.97.2)
  136. # [05:12] * Quits: miketaylr (n=miketayl@24.42.95.234)
  137. # [05:25] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
  138. # [05:26] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  139. # [05:27] * Quits: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  140. # [05:27] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  141. # [05:33] * Quits: svtech (n=stanv@83.228.56.37)
  142. # [05:33] * Quits: avidvivid (n=avidvivi@209-180-139-110.phnx.qwest.net) (Client Quit)
  143. # [05:37] * Joins: hober (n=ted@unaffiliated/hober)
  144. # [05:40] * Quits: fishd (n=darin@67.180.164.209) (Read error: 145 (Connection timed out))
  145. # [05:48] * Joins: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  146. # [05:54] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  147. # [05:54] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) (Read error: 104 (Connection reset by peer))
  148. # [05:54] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  149. # [06:02] * Quits: meoblast001 (n=meoblast@dynamic-acs-24-101-148-112.zoominternet.net) ("meoquit")
  150. # [06:04] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  151. # [06:09] * Joins: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  152. # [06:09] * Quits: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net) (Remote closed the connection)
  153. # [06:10] * Joins: svtech (n=stanv@83.228.56.37)
  154. # [06:16] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  155. # [06:18] * Joins: slightlyoff (n=slightly@204.14.154.228)
  156. # [06:19] * Joins: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  157. # [06:20] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
  158. # [06:21] * Quits: bgalbraith (n=bgalbrai@71.202.109.116)
  159. # [06:23] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  160. # [06:25] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) (Read error: 113 (No route to host))
  161. # [06:28] * Quits: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
  162. # [06:30] * Joins: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  163. # [06:33] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  164. # [06:34] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  165. # [06:35] * Quits: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net) ("Colloquy more like Coolloquy")
  166. # [06:35] * Joins: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
  167. # [06:38] * Quits: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net) (Client Quit)
  168. # [06:38] * Joins: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
  169. # [06:39] * Joins: slightlyoff_ (n=slightly@72.14.224.1)
  170. # [06:41] * Joins: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net)
  171. # [06:41] * Quits: roc (n=roc@203.97.204.82)
  172. # [06:42] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  173. # [06:42] * dglazkov_ is now known as dglazkov
  174. # [06:47] * Quits: slightlyoff (n=slightly@204.14.154.228) (Read error: 145 (Connection timed out))
  175. # [06:47] * slightlyoff_ is now known as slightlyoff
  176. # [06:48] * Quits: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Read error: 110 (Connection timed out))
  177. # [06:54] * Joins: sicking (n=chatzill@c-69-181-197-163.hsd1.ca.comcast.net)
  178. # [07:06] * Quits: sylvaing (n=sylvaing@c-98-232-19-82.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  179. # [07:18] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  180. # [07:19] * Quits: dglazkov (n=dglazkov@72.14.224.1)
  181. # [07:20] <zcorpan_> "script data double escaped dash dash state"
  182. # [07:22] <zcorpan_> could we rename it to script data double escaped double dash state? :)
  183. # [07:23] * Quits: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  184. # [07:32] * Joins: fishd (n=darin@67.180.164.209)
  185. # [07:37] <zcorpan_> script data states outnumber the doctype states
  186. # [07:41] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  187. # [07:43] <zcorpan_> does the abnf allow things like <!--<!--<script><script></script>-->?
  188. # [07:44] <Hixie> i hope so
  189. # [07:44] <Hixie> shouldn't it?
  190. # [07:44] <Hixie> jgraham: dude, pms is being really slow
  191. # [07:44] <zcorpan_> yeah it should
  192. # [07:45] <zcorpan_> on a first pass reading, the spec looks good
  193. # [07:45] <Hixie> cool
  194. # [07:46] <zcorpan_> maybe there should be some more cases that should trigger a parse error, though i didn't think about that while reading
  195. # [07:47] <Hixie> i think we don't need any parse errors, given the script abnf nonsense
  196. # [07:47] <zcorpan_> ah, the abnf applies to conformance checkers?
  197. # [07:48] <Hixie> it's intended to
  198. # [07:48] <Hixie> if i missed the "must", let me know
  199. # [07:49] * Quits: erlehmann_ (n=erlehman@82.113.106.0) ("Ex-Chat")
  200. # [07:49] <zcorpan_> i thought it was in the syntax section at first. just read the diff with not enough context :)
  201. # [07:55] <MikeSmith> tyoshino: you around?
  202. # [07:56] <zcorpan_> sicking: i've filed a bug on removing tags() in opera
  203. # [07:56] <MikeSmith> ukai: ping
  204. # [07:56] <sicking> zcorpan_: yay, sweet!
  205. # [07:57] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  206. # [08:00] <tyoshino> hi
  207. # [08:00] <tyoshino> MIkeSmith: hi
  208. # [08:01] * Quits: dave_levin (n=dave_lev@74.125.59.73)
  209. # [08:04] <ukai> MikeSmith: hi
  210. # [08:13] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  211. # [08:13] * Joins: yatil (n=Adium@78.104.102.186)
  212. # [08:13] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  213. # [08:19] * Joins: fishd_ (n=darin@216.239.45.130)
  214. # [08:19] * Joins: sirdarckcat (n=sdc@unaffiliated/sirdarckcat)
  215. # [08:20] <sirdarckcat> hey! one question
  216. # [08:20] <sirdarckcat> <script src="something.js"></script><link href="something.css" rel="stylesheet" type="text/css">
  217. # [08:21] <sirdarckcat> should the browser start the request to something.css before executing the JS of something.js?
  218. # [08:21] <sirdarckcat> since something.js may have document.write("<plaintext>") or whatever
  219. # [08:22] <hsivonen> annevk: no, I didn't get around to filing a bug about <base>. I'll file one now.
  220. # [08:23] <hsivonen> annevk: I see you filed one already. Thanks
  221. # [08:24] <hsivonen> sirdarckcat: Gecko will start requesting the style sheet but may not end up applying it
  222. # [08:24] <sirdarckcat> :(
  223. # [08:24] <sirdarckcat> also IE
  224. # [08:25] <sirdarckcat> and chrome
  225. # [08:25] <sirdarckcat> opera and safari wont
  226. # [08:25] <hsivonen> sirdarckcat: however, you should not rely on script-set cookies to take effect for requesting later resources on the same page
  227. # [08:25] <hsivonen> sirdarckcat: why :-( ? It's an awesome optimization.
  228. # [08:26] * Quits: svtech (n=stanv@83.228.56.37)
  229. # [08:26] <hsivonen> I'm surprised if Safari doesn't prefetch, too, in that case
  230. # [08:27] * Quits: fishd (n=darin@67.180.164.209) (Read error: 145 (Connection timed out))
  231. # [08:27] <sirdarckcat> because I was relying that was not going to happen
  232. # [08:27] <sirdarckcat> there are several reasons but
  233. # [08:27] <hsivonen> it would also be odd if Opera didn't start prefetching in order to be competitive perf-wise
  234. # [08:28] <sirdarckcat> but how the browser knows?
  235. # [08:28] <sirdarckcat> what if the script makes a
  236. # [08:28] <sirdarckcat> document.write(base)
  237. # [08:28] <sirdarckcat> well
  238. # [08:28] <sirdarckcat> <base href="">
  239. # [08:28] <sirdarckcat> they dont know the real location
  240. # [08:28] <sirdarckcat> "yet"
  241. # [08:29] <sirdarckcat> I'll try to make some tests, maybe I can disable it with a <plaintext> or something like that
  242. # [08:30] <zcorpan_> how did you rely on it not going to happen?
  243. # [08:31] <sirdarckcat> since I dont want the referrer to be leaked
  244. # [08:31] <sirdarckcat> anyway, I think I can fix it with a <plaintext> after the <script>
  245. # [08:33] * Joins: cedricv (n=cedric@116.197.243.177)
  246. # [08:35] <zcorpan_> do you have document.write('<plaintext>') now?
  247. # [08:36] <sirdarckcat> yes
  248. # [08:36] <sirdarckcat> <script src="..."></script><script>document.write("<plaintext>")</script>
  249. # [08:37] <sirdarckcat> anyway, is this standarized or is just a defacto optimisation?
  250. # [08:37] <zcorpan_> defacto
  251. # [08:37] <sirdarckcat> hmm I see
  252. # [08:37] <sirdarckcat> well.. I see why browsers would like to do it
  253. # [08:37] <sirdarckcat> :) thanks zcorpan
  254. # [08:37] <sirdarckcat> and hsivoben
  255. # [08:37] <sirdarckcat> hsivonen
  256. # [08:37] <hsivonen> sirdarckcat: if you have <base> at all, Gecko just makes bogus speculative GETs
  257. # [08:38] <hsivonen> sirdarckcat: GET is idempotent and safe, so it only wastes bits
  258. # [08:38] <hsivonen> if you want your site to be fast, don't use <base>
  259. # [08:38] <sirdarckcat> oh, I dont want to use base
  260. # [08:38] <hsivonen> (I might fix that some day, but it's not a priority.)
  261. # [08:38] <sirdarckcat> but I should support sites that use it
  262. # [08:39] <sirdarckcat> there are a lot of things that shouldnt exist, multiple <base> tags being one of them
  263. # [08:39] <hsivonen> Support for multiple <base> tags is on its way out, IIRC.
  264. # [08:39] <sirdarckcat> haha its gonna be standard?
  265. # [08:39] <sirdarckcat> no way!
  266. # [08:40] <sirdarckcat> xDDD
  267. # [08:40] <sirdarckcat> that sucks
  268. # [08:40] <sirdarckcat> well
  269. # [08:40] <sirdarckcat> what problem does that solve?
  270. # [08:40] <sirdarckcat> I can only think on xss
  271. # [08:40] <zcorpan_> ie only uses the first <base>
  272. # [08:40] <sirdarckcat> yeah
  273. # [08:40] <zcorpan_> html5 matches ie
  274. # [08:40] <sirdarckcat> I think that's the way to go
  275. # [08:40] <sirdarckcat> yeah I agree
  276. # [08:40] <sirdarckcat> but then, what do u mean with
  277. # [08:41] <sirdarckcat> oh
  278. # [08:41] <sirdarckcat> wait
  279. # [08:41] <sirdarckcat> wait
  280. # [08:41] <sirdarckcat> you said
  281. # [08:41] <hsivonen> zcorpan_: I think HTML5 is silent ATM
  282. # [08:41] <sirdarckcat> "on its way out"
  283. # [08:41] <sirdarckcat> ohhh sorry
  284. # [08:41] <sirdarckcat> haha, I misunderstood u
  285. # [08:41] <zcorpan_> hsivonen: no it isn't :)
  286. # [08:41] <sirdarckcat> :)
  287. # [08:41] <hsivonen> zcorpan_: where's the normative text?
  288. # [08:41] <hsivonen> zcorpan_: I only saw an informative note
  289. # [08:42] <sirdarckcat> I filled a bug on the multiple base tags on webkit&mozilla 2 days ago
  290. # [08:42] <sirdarckcat> https://bugzilla.mozilla.org/show_bug.cgi?id=522658
  291. # [08:42] <zcorpan_> oh maybe it was removed as part of URLs
  292. # [08:43] <sirdarckcat> informative note means its optional?
  293. # [08:43] <hsivonen> sirdarckcat: yeah, the spec bug exists because I was unable to determine the spec-compliance status of the Gecko bug you filed
  294. # [08:43] <hsivonen> sirdarckcat: informative note means the editor goofed
  295. # [08:43] * lmorchard is now known as lmorchard|away
  296. # [08:44] <zcorpan_> hsivonen: "The document base URL of a Document object is the document base Web address as defined by the Web addresses specification. [WEBADDRESSES]"
  297. # [08:44] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  298. # [08:45] <sirdarckcat> hmm mmm
  299. # [08:45] <sirdarckcat> Contexts in which this element may be used:
  300. # [08:45] <sirdarckcat> In a head element containing no other base elements.
  301. # [08:45] <sirdarckcat> whats the informative note?
  302. # [08:45] <sirdarckcat> http://www.whatwg.org/specs/web-apps/current-work/#the-base-element
  303. # [08:45] <zcorpan_> the note is "Note: If there are multiple base elements with href attributes, all but the first are ignored."
  304. # [08:46] <hsivonen> zcorpan_: does [WEBADDRESSES] deal with multiple <base>s and script-inserted bases?
  305. # [08:46] <sirdarckcat> AH RIGHT
  306. # [08:47] <zcorpan_> hsivonen: yes. "Otherwise, let w be the value of the href attribute of the first such element."
  307. # [08:47] <hsivonen> zcorpan_: oh ok. thanks
  308. # [08:48] <hsivonen> ok so Hixie didn't good. sorry. but it would sure be clearer to have the <base> processing model in HTML5
  309. # [08:48] <sirdarckcat> mmm well webkit says they wont fix it unless gecko does it.. =/
  310. # [08:48] <sirdarckcat> https://bugs.webkit.org/show_bug.cgi?id=30432#c3
  311. # [08:48] <sirdarckcat> anyway
  312. # [08:48] <sirdarckcat> maybe
  313. # [08:48] <zcorpan_> webaddress doesn't define what "the head element" is
  314. # [08:54] <hsivonen> duped the bug against https://bugzilla.mozilla.org/show_bug.cgi?id=515401 ; see sicking's comment #13 there.
  315. # [08:59] * Quits: yatil (n=Adium@78.104.102.186) ("Leaving.")
  316. # [08:59] * Joins: yatil (n=Adium@78.104.102.186)
  317. # [09:04] * Joins: virtuelv (n=virtuelv@213.236.208.22)
  318. # [09:04] * Quits: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com) (Read error: 104 (Connection reset by peer))
  319. # [09:05] * Joins: JoePeck (n=JoePeck@74.69.85.249)
  320. # [09:11] <sirdarckcat> @hsivone thnx
  321. # [09:11] <sirdarckcat> what's the meaning of Whiteboard: [good first bug] ?
  322. # [09:14] * Joins: erlehmann (n=erlehman@82.113.106.0)
  323. # [09:18] * Joins: zalan (n=zalan@89.135.144.122)
  324. # [09:25] <sirdarckcat> oh nvm, http://www-archive.mozilla.org/contribute/hacking/first-bugs/
  325. # [09:28] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  326. # [09:33] * Quits: hober (n=ted@unaffiliated/hober) (Remote closed the connection)
  327. # [09:33] * Joins: hober (n=ted@unaffiliated/hober)
  328. # [09:36] <erlehmann> more HTML5 on your console browser, coming soon: http://img3.imageshack.us/img3/1247/bildschirmfoto2eb.png
  329. # [09:38] <zcorpan_> erlehmann: cool
  330. # [09:38] <zcorpan_> erlehmann: does it use an html5 parser?
  331. # [09:39] <erlehmann> zcorpan_, haha, no. the source is a mess, as far as i can tell.
  332. # [09:39] <jgraham> Hixie: Is pms being more reliable? I made a small change that may improve reliability at the expense of a little speed, but it may not have helped
  333. # [09:39] <jgraham> erlehmann: Those things are not mutually exclusive...
  334. # [09:39] <zcorpan_> erlehmann: do you support <video><source src>?
  335. # [09:40] <erlehmann> zcorpan_, no. there are three bugs i will probably fix in the next days.
  336. # [09:40] <Hixie> jgraham: it was significantly slower earlier, but yes, it was eventually completing. However, the slowness was for everything, not just the W3C copy.
  337. # [09:40] <erlehmann> first, no <source> element parsing
  338. # [09:40] <Hixie> jgraham: haven't tried in the last few hours.
  339. # [09:40] <erlehmann> second, element contents are still displayed
  340. # [09:40] <jgraham> Hixie: Might just have been a server problem then
  341. # [09:41] <erlehmann> third, the poster attribute. inserting a fake image before the video link will do it.
  342. # [09:41] <Hixie> jgraham: yeah
  343. # [09:41] <hsivonen> years ago, when I still thought XHTML was the Right Thing for the Web, I wanted to add expat to Lynx as a weekend hack
  344. # [09:41] <erlehmann> zcorpan_, if you want to add the javascript interface for media elements in elinks, good luck with that :D
  345. # [09:42] <zcorpan_> erlehmann: heh
  346. # [09:42] <hsivonen> I looked at the source and it was a bunch of undocumented pointer magic
  347. # [09:42] <hsivonen> then I turned to links
  348. # [09:42] <hsivonen> and it looked similar
  349. # [09:42] <hsivonen> so I gave up
  350. # [09:42] <hsivonen> maybe elinks is better now
  351. # [09:43] <Hixie> hsivonen: i was hoping one day to make an aalib GFX for Gecko
  352. # [09:43] <zcorpan_> would be cool to asciify the rendered output of a modern rendering engine
  353. # [09:43] <erlehmann> Hixie, better make embedded aalib rendering for elinks ;)
  354. # [09:44] <zcorpan_> with <video> playing as ascii art
  355. # [09:44] <hsivonen> Hixie: these days, I think TTY browsers should put a TTY presentation layer on a mainstead browser engine impl
  356. # [09:44] <erlehmann> i think that too btw
  357. # [09:44] <Hixie> yeah, i don't think using elinks would be worth it
  358. # [09:44] <Hixie> you want all the CSS support, etc
  359. # [09:46] <erlehmann> i thought elinks does some CSS
  360. # [09:48] <zcorpan_> the html5 doctors are a bit slow at fixing their templates
  361. # [09:48] <zcorpan_> wonder if someone can help
  362. # [09:51] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  363. # [09:57] * tkent is now known as tkent_afk
  364. # [10:07] * Joins: harig (n=harig@213.236.208.22)
  365. # [10:09] * Joins: svtech (n=stanv@83.228.56.37)
  366. # [10:13] * Quits: webben1 (n=benh@dip5-fw.corp.ukl.yahoo.com) ("Leaving.")
  367. # [10:13] * Quits: sicking (n=chatzill@c-69-181-197-163.hsd1.ca.comcast.net) (Remote closed the connection)
  368. # [10:24] <jgraham> So one reason that clashing html/non-html tag names in foreign content is bad is the need for the breaking out of foreign content mode stuff. Were the other reasons mostly increased implementation complexity?
  369. # [10:25] <zcorpan_> v=document.createElement('video'); v.src='foo'; v.load();
  370. # [10:25] <zcorpan_> will fire an emptied event, right?
  371. # [10:25] <erlehmann> zcorpan_, elinks uses spidermonkey, so if you can get that to work, i't would be cool
  372. # [10:26] <zcorpan_> because setting src invokes the load algorithm, which invokes resource selection, which sets networkState to NETWORK_NO_SOURCE
  373. # [10:27] <zcorpan_> then calling load() will run the load algorithm again, see that networkState is not NETWORK_EMPTY, and thus fire 'emptied'
  374. # [10:29] <zcorpan_> seems a bit annoying
  375. # [10:35] <mikekelly> hi fans
  376. # [10:36] <zcorpan_> foolip: ping
  377. # [10:36] <mikekelly> are there any javascript/browser geniuses around?
  378. # [10:36] <mikekelly> :P
  379. # [10:37] * Joins: mpt (n=mpt@canonical/mpt)
  380. # [10:38] * Joins: gsnedders (n=gsnedder@c83-252-239-221.bredband.comhem.se)
  381. # [10:38] <mikekelly> I need to figure out if it is possible to shift browser location to a new URL and add custom headers to the request
  382. # [10:38] <Philip`> mikekelly: Use XHR and then document.write the responseText, maybe?
  383. # [10:38] * Philip` doesn't know what else could work
  384. # [10:39] <mikekelly> hmm
  385. # [10:39] <mikekelly> presumably that doesn't work for docs like pdf, or images
  386. # [10:39] <Philip`> Use XHR and then convert the responseText into a data: URI and load that, maybe
  387. # [10:40] <Philip`> That might not work at all
  388. # [10:41] * Joins: mat_t (n=mattomas@91.189.88.12)
  389. # [10:44] <zcorpan_> so should we limit document.all to quirks mode?
  390. # [10:45] * Joins: ROBOd (n=robod@89.122.216.38)
  391. # [10:57] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
  392. # [10:57] * Joins: Phae (n=phaeness@gatea.mh.bbc.co.uk)
  393. # [10:57] <jgraham> zcorpan_: It seems like it might be OK
  394. # [10:58] <jgraham> I mean it is already such a disaster that no one should be using it. And Mozilla seem to get away with it
  395. # [10:58] <jgraham> s/using it/using it in new code/
  396. # [10:59] <jgraham> The main arguments against are: it is added complexity which is bad, and there is a possibility that other browsers will have more compat problems than Mozilla (e.g. because they get a differnt codpath due to a different level of IE emulation)
  397. # [11:01] <zcorpan_> yeah, we probably need to investigate the compat situation
  398. # [11:02] <zcorpan_> opera more often gets to the ie code path than mozilla
  399. # [11:02] <zcorpan_> so if we remove document.all from standards mode, sites might break in opera but continue to work in ie and moz
  400. # [11:04] <jgraham> I guess the other fix is to emulate less of IE in Opera :)
  401. # [11:04] <zcorpan_> sure
  402. # [11:05] <Hixie> p4200
  403. # [11:05] <Hixie> er
  404. # [11:05] <Hixie> r4200
  405. # [11:06] <jgraham> But yes it would be good to get an idea of compat
  406. # [11:06] * Quits: gsnedders (n=gsnedder@c83-252-239-221.bredband.comhem.se)
  407. # [11:06] <jgraham> Hixie: just for the nice number?
  408. # [11:07] <zcorpan_> we should rename the spec to HTML4200
  409. # [11:08] * tkent_afk is now known as tkent
  410. # [11:08] <zcorpan_> and change it every revision
  411. # [11:08] <Philip`> That would be a good way to demonstrate the meaninglessness of version numbers
  412. # [11:09] <erlehmann> <DOCTYPE html4321> :D
  413. # [11:09] * Quits: bgalbraith (n=bgalbrai@71.202.109.116)
  414. # [11:09] <Hixie> jgraham: yeah
  415. # [11:09] <jgraham> Ah, how I pine for the days of HTML4198
  416. # [11:10] * Joins: foolip_ (n=philip@pat.se.opera.com)
  417. # [11:10] <Hixie> i'm amused that the ietf people keep being shocked that websocket is at r48
  418. # [11:10] * foolip_ is now known as foolip|work
  419. # [11:10] <Hixie> 48! shocking! such a high number of revisions!
  420. # [11:11] * zcorpan_ hears Hixie go lalala complete.html gets like 48 revisions a day
  421. # [11:13] <erlehmann> i guess charces stross was wrong about the IETF being capable of coping with the coming singularity
  422. # [11:13] * jgraham feels zcorpan might be immortalised in the html5lib code for the Script data double escaped dash dash state
  423. # [11:13] <foolip|work> zcorpan_: you rang?
  424. # [11:14] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  425. # [11:14] * Joins: webben (n=benh@nat/yahoo/x-xlrklcmiylsfwhdn)
  426. # [11:14] <zcorpan_> foolip|work: what do you think about the load algorithm being invoked twice in v=document.createElement('video'); v.src='foo'; v.load(); ?
  427. # [11:14] <zcorpan_> foolip|work: and thus firing 'emptied' afaict
  428. # [11:15] <erlehmann> "Rachel grinned humorlessly as she held up a warrant card. Her head, surrounded by the UN three-W logo on a background of stars."
  429. # [11:15] <foolip|work> zcorpan_: don't call load() ?
  430. # [11:15] <erlehmann> in the next revision of iron sunrise it will be a green question mark, i bet ;)
  431. # [11:15] <webben> erlehmann: It does (do some CSS).
  432. # [11:16] <zcorpan_> foolip|work: sure but then it wouldn't load in older browsers
  433. # [11:17] <annevk> seems like a short term problem not worth fixing
  434. # [11:18] <zcorpan_> v=document.createElement('video'); v.src='foo'; v.load(); doesn't look wrong, so people will probably do it even though load() isn't necessary, and would maybe be surprised when it fires an 'emptied' event
  435. # [11:19] <foolip|work> zcorpan_: I'm not sure this is a problem, why would anyone listen to the emptied event to begin with?
  436. # [11:20] <zcorpan_> i don't know. what's the use case for the event?
  437. # [11:21] <foolip|work> beats me :)
  438. # [11:23] * zcorpan_ files a spec bug
  439. # [11:27] <foolip|work> Hixie: re: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7843 no other event on media elements can be trusted to be in sync with the state of the element, why would it be important for abort or emptied?
  440. # [11:28] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  441. # [11:29] <hsivonen> hmm. type="x-shader/x-fragment"
  442. # [11:29] <hsivonen> on <script>
  443. # [11:30] <foolip|work> especially since the state of the element in 'abort' or emptied' is reset, there's nothing interesting for the script to check on the element anyway
  444. # [11:30] <hsivonen> maybe in the future I should special-case those not to create speculative futures
  445. # [11:30] <zcorpan_> hsivonen: we probably need an official type that authors can use for their script data blocks
  446. # [11:30] <Hixie> foolip|work: i dunno, maybe. i'm scared of race conditions. feel free to reopen the bug.
  447. # [11:31] <foolip|work> Hixie: ok, will do :)
  448. # [11:37] * Quits: fishd_ (n=darin@216.239.45.130) (Read error: 110 (Connection timed out))
  449. # [11:39] <Hixie> foolip|work: while you're here, http://www.w3.org/Bugs/Public/show_bug.cgi?id=7844
  450. # [11:40] <zcorpan_> Hixie: i filed that bug
  451. # [11:41] <Hixie> zcorpan_: cool, you can answer my question too then :-)
  452. # [11:41] <Hixie> anyway, my question is: do we want media elements to be live after being created?
  453. # [11:41] <Hixie> it seems weird that one wouldn't be able to construct an <audio> while it's dead, and invoke the loading later
  454. # [11:42] <Philip`> hsivonen: Shouldn't you special case text/javascript and similar things that will get executed, rather than special-casing a few of the infinitely many types that won't get executed?
  455. # [11:43] <hsivonen> Philip`: Gecko has this extensibility thing going...
  456. # [11:44] <hsivonen> Philip`: so the parser would have to know that it's doing exactly the same comparisons as the script loader when Python etc. is loaded
  457. # [11:44] <hsivonen> and IIRC, Python is chrome-only, etc.
  458. # [11:44] <hsivonen> and the parser doesn't know if it is parsing a chrome doc, etc.
  459. # [11:45] <Philip`> hsivonen: I thought speculative parsing was only particularly useful for high-latency web documents, so you can pre-fetch resources, and would have minimal effect in chrome
  460. # [11:45] <zcorpan_> Hixie: hmm, not sure when one would want to have a dead <audio>
  461. # [11:46] <Hixie> zcorpan_: precreating a number of videos, say, so they can be inserted when desired? dunno
  462. # [11:46] <zcorpan_> maybe
  463. # [11:47] <zcorpan_> but you'd have to use <source> as the spec is now
  464. # [11:48] <zcorpan_> it's not the most obvious thing that it loads automatically when you set src and when you insert a <source> when it's in a document but not when you insert a <source> when it's not in a document
  465. # [11:48] <Hixie> yeah i agree we should make that consistent
  466. # [11:49] <zcorpan_> if there's a need for dead media elements, maybe a new attribute or something?
  467. # [11:50] * Quits: erlehmann (n=erlehman@82.113.106.0) ("Ex-Chat")
  468. # [11:50] <zcorpan_> <video loadondemand>?
  469. # [11:50] <Hixie> it's not important enough to have its own feature, imho
  470. # [11:51] <zcorpan_> yeah
  471. # [11:55] * Joins: harig_ (n=harig@213.236.208.22)
  472. # [11:56] * harig_ is now known as harig`
  473. # [12:01] * Quits: harig (n=harig@213.236.208.22) (Read error: 145 (Connection timed out))
  474. # [12:03] * Quits: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
  475. # [12:06] <Hixie> what should location.search do in data: pages...?
  476. # [12:09] * Joins: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
  477. # [12:12] <Lachy> are data URLs not allowed to have query components?
  478. # [12:12] <Hixie> no
  479. # [12:12] <Hixie> nor pathname
  480. # [12:12] <Hixie> looks like i just overlooked this
  481. # [12:12] <Hixie> i'll make them just ignore .pathname and .search
  482. # [12:12] <Lachy> then do what Mozilla does and return an empty string
  483. # [12:13] <Hixie> yeah
  484. # [12:15] * Quits: Super-Dot (n=Super-Do@adsl-76-231-44-247.dsl.pltn13.sbcglobal.net)
  485. # [12:15] <Lachy> data:text/html,<!DOCTYPE html><script>if(location.search===""){document.write("PASS");}else{document.write(location.search)}</script><!--?FAIL
  486. # [12:16] <Lachy> Opera outputs "?FAIL"
  487. # [12:16] <Lachy> woah, Safari outputs "?FAIL?FAIL"
  488. # [12:16] <Hixie> yeah i tested the browsers before asking :-)
  489. # [12:17] <Lachy> ok
  490. # [12:17] <Lachy> oh, Safari does that cause it reparses the comment
  491. # [12:18] <Hixie> reparses?
  492. # [12:19] <Lachy> yeah, when it sees <!--XXX with no closing -->, doesn't it do reparsing to handle the error?
  493. # [12:19] <Hixie> why would that make it say ?FAIL?FAIL ?
  494. # [12:19] <Hixie> it doesn't affect the URL
  495. # [12:20] <Lachy> because the first one is the result of the document.write(), the latter is a result of it actually being part of the page content.
  496. # [12:20] <Lachy> the result is the same as doing this: <script>document.write("?FAIL");</script>?FAIL
  497. # [12:21] <Hixie> oh, right
  498. # [12:26] * Quits: sirdarckcat (n=sdc@unaffiliated/sirdarckcat) (Read error: 104 (Connection reset by peer))
  499. # [12:28] <Hixie> is "decentralized extension" newspeak for non-standard extension? http://www.w3.org/Bugs/Public/show_bug.cgi?id=7855
  500. # [12:35] * Quits: cedricv (n=cedric@116.197.243.177) (Read error: 145 (Connection timed out))
  501. # [12:38] * Joins: ppattern (n=pattern_@ppp-58-8-117-195.revip2.asianet.co.th)
  502. # [12:38] * Joins: cedricv (n=cedric@116.197.207.149)
  503. # [12:38] * Quits: virtuelv (n=virtuelv@213.236.208.22) ("Ex-Chat")
  504. # [12:39] * Joins: virtuelv (n=virtuelv@213.236.208.22)
  505. # [12:40] <zcorpan_> a standard is centralized, so it probably follows that non-standard is decentralized
  506. # [12:43] * Joins: roc (n=roc@121.72.198.60)
  507. # [12:57] <zcorpan_> hmm
  508. # [12:57] <zcorpan_> if a browser supports video formats A and B
  509. # [12:57] <zcorpan_> and a video using format A is labeled as content-type: B
  510. # [12:58] <zcorpan_> should the video be played?
  511. # [13:01] <zcorpan_> i think the spec says yes, because the algorithm only fails if the mime type is unsupported or the video can't be decoded
  512. # [13:01] <annevk> that depends on whether you want to enforce some additional pedantic check
  513. # [13:03] <Hixie> yes, the spec says that the MIME type has to be supported, but it doesn't say the MIME type has to match the content
  514. # [13:04] <zcorpan_> yep
  515. # [13:04] <Hixie> wasn't really what i meant to spec, but i don't propose changing it :-)
  516. # [13:05] <zcorpan_> i think it's fine
  517. # [13:05] <zcorpan_> makes it easier to test, too
  518. # [13:06] <zcorpan_> also matches how <img> works
  519. # [13:06] * Quits: roc (n=roc@121.72.198.60)
  520. # [13:06] <zcorpan_> except for SVG vs PNG i guess
  521. # [13:07] <zcorpan_> haven't tested though
  522. # [13:08] <Philip`> zcorpan_: Why are standards centralized?
  523. # [13:08] <Philip`> It seems quite common for independent groups to spring up and make standards, without being part of the existing centralized standards organisations
  524. # [13:09] <zcorpan_> maybe
  525. # [13:14] <jgraham> Why are existing organisations making standards centralized but new organisations doing the same thing decentralised?
  526. # [13:14] <jgraham> e.g. I wouldn't describe what the WHATWG did as "decentralised extensibility"
  527. # [13:16] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  528. # [13:17] <Philip`> They become centres of standardisation after existing for a while and being successful
  529. # [13:17] <Philip`> jgraham: That's because HTML didn't support distributed extensibility, and the realistic option was to start from scratch instead of extending it
  530. # [13:18] <jgraham> Philip`: I doubt we would have had {http://whatwg.org/ns/webapps}video even if it had been possible
  531. # [13:19] <Philip`> In the magical world of distributed extensibility, I suppose the idea is some random group of people could form a WHYWG and define a video element without needing to get approval from existing standard organisations (though still needing cooperation from browser vendors)
  532. # [13:20] <Philip`> but presumably that'd only work if features using the extension mechanism were as good as 'native' non-extension features
  533. # [13:21] <Philip`> (and it wouldn't work if extension features had to use complex namespaces while native feature didn't)
  534. # [13:21] * Joins: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net)
  535. # [13:23] <jgraham> Maybe fans of namespaces in html should set up the Web Hypertext Extensibility Namespaces Working Group
  536. # [13:27] * Quits: smaug (n=chatzill@82.181.150.24) (Remote closed the connection)
  537. # [13:28] * Joins: payman (n=payman@pat.se.opera.com)
  538. # [13:29] <zcorpan_> foolip: reopened the bug and gave you permissions to edit bugs and give other people permissions
  539. # [13:32] * Joins: remysharp (n=remyshar@80.229.253.218)
  540. # [13:34] <gsnedders|work> jgraham: You aware that html5lib.parse("foo", "etree") will never work?
  541. # [13:35] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  542. # [13:38] <zcorpan_> application/octet-stream; codecs=foobar
  543. # [13:38] <zcorpan_> is that a type that the ua knows it cannot render?
  544. # [13:39] * Quits: svtech (n=stanv@83.228.56.37)
  545. # [13:41] * Quits: remysharp (n=remyshar@80.229.253.218) ("Gotta shoot - "peeyaow"")
  546. # [13:45] <zcorpan_> Hixie: does the term "MIME type" include parameters or not?
  547. # [13:46] * Joins: smaug (n=chatzill@82.181.150.24)
  548. # [13:47] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  549. # [13:48] <zcorpan_> "valid MIME type" seems to include parameters, so i guess "MIME type" does too
  550. # [13:48] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
  551. # [13:49] * Joins: mat_t (n=mattomas@91.189.88.12)
  552. # [13:53] <hsivonen> how does WebKit deal with https://bugzilla.mozilla.org/show_bug.cgi?id=510063 ?
  553. # [13:54] <zcorpan_> hsivonen: by not foster parenting forms
  554. # [13:57] <hsivonen> zcorpan_: does that lead to bad craziness?
  555. # [13:57] <hsivonen> zcorpan_: if not, why doesn't HTML5 copy WebKit here?
  556. # [13:57] <zcorpan_> i guess Hixie didn't think it was needed for compat and didn't want to add unneeded complexity
  557. # [13:57] <zcorpan_> but clearly it's a bug in html5
  558. # [13:58] <zcorpan_> old gecko also doesn't foster parent forms
  559. # [14:06] <zcorpan_> maybe the quirks mode form margin could be zapped, but presumably it's there for compat with content and not just a leftover from netscape?
  560. # [14:07] <hsivonen> I have no idea
  561. # [14:08] <zcorpan_> hmm opera has the margin in standards mode too
  562. # [14:09] <zcorpan_> does ie have the margin in standards mode?
  563. # [14:12] * Quits: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  564. # [14:19] * Quits: zalan (n=zalan@89.135.144.122)
  565. # [14:19] * Quits: paul_irish (n=paul_iri@12.182.97.2) (Remote closed the connection)
  566. # [14:22] * Joins: ttepasse (n=ttepas--@p5B0154BE.dip.t-dialin.net)
  567. # [14:23] * Quits: wakaba_ (n=wakaba_@122.221.184.68) ("Leaving...")
  568. # [14:26] * Joins: zcorpan_ (n=zcorpan@pat.se.opera.com)
  569. # [14:27] * hsivonen wonders if Opera does the reloading charset switch in mid-parse
  570. # [14:33] <annevk> should createHTMLDocument talk about quirks mode?
  571. # [14:34] <annevk> or is that implied from createDocument() somehow?
  572. # [14:34] <gsnedders|work> I thought the spec said that all documents were by default in no-quirks
  573. # [14:34] <gsnedders|work> So unless it is explicitly set to quirks/limited-quirks, it's in no-quirks
  574. # [14:34] <hsivonen> gsnedders|work is right
  575. # [14:35] <hsivonen> an informative note wouldn't hurt, though
  576. # [14:45] * Joins: myakura (n=myakura@p2102-ipbf6805marunouchi.tokyo.ocn.ne.jp)
  577. # [14:47] <annevk> fair enough
  578. # [14:49] <zcorpan_> hsivonen: http://simon.html5.org/test/html/parsing/encoding/charset-reload-2k.htm http://simon.html5.org/test/html/parsing/encoding/charset-reload-200k.htm
  579. # [14:49] <zcorpan_> apparently we don't reload, we just give up trying to find the encoding at some point
  580. # [14:50] <zcorpan_> possibly based on a timer, because i needed more bytes when testing locally
  581. # [14:50] <zcorpan_> that or my test is bogus
  582. # [14:51] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 113 (No route to host))
  583. # [14:51] <annevk> Hixie, onload can also be specified for a lot of elements besides body
  584. # [14:51] <hsivonen> ok. so Opera doesn't reparse, WebKit doesn't reparse
  585. # [14:51] <hsivonen> does IE reparse?
  586. # [14:51] <annevk> (same for other such restricted elements)
  587. # [14:51] <zcorpan_> ie reparses
  588. # [14:52] <hsivonen> I've spent way too much time tweaking reparsing
  589. # [14:54] * Joins: mpt (n=mpt@canonical/mpt)
  590. # [14:54] * Joins: pmuellr (n=pmuellr@69.61.162.35)
  591. # [14:55] <zcorpan_> but webkit doesn't give up trying to find the encoding, or does it?
  592. # [14:55] <hsivonen> IIRC, WebKit prescans 1KB and that's it
  593. # [14:56] <zcorpan_> i get an Ђ in chrome with a meta after 2MB
  594. # [14:57] <hsivonen> oh
  595. # [14:57] * Quits: virtuelv (n=virtuelv@213.236.208.22) (Read error: 145 (Connection timed out))
  596. # [14:57] <hsivonen> I wonder if they write the charset to the cache entry like Gecko does
  597. # [15:02] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  598. # [15:21] * Joins: cedric__ (n=cedric@116.197.197.197)
  599. # [15:23] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  600. # [15:24] * Quits: cedricv (n=cedric@116.197.207.149) (Read error: 145 (Connection timed out))
  601. # [15:28] * Joins: BlurstOfTimes (n=blurstof@168.203.117.66)
  602. # [15:30] * Quits: cedric__ (n=cedric@116.197.197.197) (Read error: 145 (Connection timed out))
  603. # [15:31] * Joins: miketaylr (n=miketayl@38.117.156.163)
  604. # [15:31] * Quits: miketaylr (n=miketayl@38.117.156.163) (Remote closed the connection)
  605. # [15:32] * Joins: miketaylr (n=miketayl@38.117.156.163)
  606. # [15:33] * Joins: cedricv (n=cedric@112.199.179.83)
  607. # [15:35] * Joins: fishd_ (n=darin@67.180.164.209)
  608. # [15:37] <TabAtkins> Can anyone give an estimate of how much time is required, on a modern website, to download + parse the page, versus downloading all linked resources, execute scripts, apply css, and render?
  609. # [15:37] <TabAtkins> Intuitively I'd expect it to be a very small part of the overall time.
  610. # [15:37] * gsnedders|work points out that some resources block parsing
  611. # [15:37] <Philip`> What's a modern website?
  612. # [15:37] <Philip`> You can't parse the page without executing scripts anyway, since modern websites use document.write
  613. # [15:37] <gsnedders|work> (if you ignore the parser being blocked by other resources, then it's almost no cost at all)
  614. # [15:37] <TabAtkins> gsnedders|work: Assume no scripts are run at all, so parsing can proceed without dealing with that (as happens when an XHR is parsed into responseXML).
  615. # [15:38] * Joins: svtech (n=stanv@83.228.56.37)
  616. # [15:39] <TabAtkins> Would it be realistic to assume that, when XHR2 is implemented and HTML pages are allowed to be fetched and parsed into responseXML, scripts still won't run?
  617. # [15:39] <jgraham> Well downloading can be pretty slow of course
  618. # [15:39] <Philip`> You should be able to measure download times easily using any kind of web profiler
  619. # [15:39] <jgraham> Basically parsing is fast compared to layout
  620. # [15:39] <gsnedders|work> TabAtkins: HTML 5 takes a while to download and parse
  621. # [15:39] <Philip`> (and compare time for initial page download vs total download time)
  622. # [15:39] <TabAtkins> I think html5 is an edge case. ^_^
  623. # [15:40] <Philip`> HTML5 only takes fractions of a second to parse, if I remember correctly
  624. # [15:40] <jgraham> (in most cases)
  625. # [15:40] <jgraham> (although you can probably create pathological testcases with mesnested formatting elements and so on)
  626. # [15:41] <gsnedders|work> Philip`: The download time is more than that, though
  627. # [15:41] <Philip`> gsnedders|work: That's why I said "parse", not "download" :-p
  628. # [15:41] * Quits: cedricv (n=cedric@112.199.179.83) (Connection reset by peer)
  629. # [15:41] <jgraham> gsnedders|work: Not if you load it from file:// pointing to a ram disk
  630. # [15:41] <jgraham> ;p
  631. # [15:41] <TabAtkins> "Average" website being 30k-40k of page, at most.
  632. # [15:42] <gsnedders|work> jgraham: I don't normally keep HTML 5 on a RAM-disk backed place accessible by file:// ;P
  633. # [15:42] <Philip`> Load the HTML5 spec from a data: URL and then there's no IO at all
  634. # [15:42] <jgraham> gsnedders|work: Your problem, not mine ;)
  635. # [15:44] <TabAtkins> Hmm, I could have sworn YSlow gav a nice litte graph showing a visual timeline of the resource requests. I can't find anything like it now.
  636. # [15:45] <jgraham> TabAtkins: Firebug and Web Inspector both do that don't they>
  637. # [15:45] <jgraham> s/>/?/
  638. # [15:45] * Joins: sylvaing (n=sylvaing@c-98-232-19-82.hsd1.wa.comcast.net)
  639. # [15:45] <TabAtkins> Firebug doesn't do it by itself, but the YSlow extension used to. I don't use Web Inspector.
  640. # [15:46] <TabAtkins> Oh, nm. It was the Net panel. My current system colors make it *really* hard to see disabled tabs.
  641. # [15:47] * Philip` is fairly sure Firebug does it by itself
  642. # [15:48] * Joins: cedricv (n=cedric@124.197.116.36)
  643. # [15:51] * Quits: fishd_ (n=darin@67.180.164.209) (Read error: 145 (Connection timed out))
  644. # [15:53] * Quits: nessy (n=Adium@203-158-45-196.dyn.iinet.net.au) ("Leaving.")
  645. # [15:53] <TabAtkins> Philip`: Yeah, you're right. Okay, so it takes about 200ms to completely receive the request for my company's home page.
  646. # [15:55] <TabAtkins> Scripts *aren't* parsed currently when building responseXML's DOM in an XHR, right?
  647. # [15:56] <TabAtkins> (Can document.write() even be used in XML?)
  648. # [15:56] <jgraham> No
  649. # [15:56] * Quits: cedricv (n=cedric@124.197.116.36) (Connection timed out)
  650. # [15:57] <TabAtkins> Do you think scripts *will* be parsed once XHR2 is implemented and responseXML can contain HTML documents?
  651. # [16:01] <gsnedders|work> TabAtkins: Only in the case that they are HTML documents
  652. # [16:01] <gsnedders|work> (and not XML ones, of any sort, inc. XHTML ones)
  653. # [16:02] <TabAtkins> Yeah, assumed that much. Hrm.
  654. # [16:02] <TabAtkins> I'm trying to gauge how much time it will take for an average document to be checked for the relevant #ids in my <a onlyreplace> proposal.
  655. # [16:03] <gsnedders|work> document.getElementsById is cheap.
  656. # [16:03] <gsnedders|work> Like, really cheap.
  657. # [16:03] <TabAtkins> Yeah, but you have to build the document first.
  658. # [16:03] <gsnedders|work> Yeah, so?
  659. # [16:03] <TabAtkins> I know it's nearly free, since you keep a hash of elements by id.
  660. # [16:03] <TabAtkins> So if there are slow scripts involved, it can still be slow to build the DOM and decide that you need to fail and render the whole page.
  661. # [16:04] <TabAtkins> From my data here, it doesn't look *that* slow, though. The only slow scripts are the external customer tracking ones. Everything else completes downloading in another 200ms.
  662. # [16:05] <annevk> my plan was to parse assuming scripts were disabled
  663. # [16:05] <annevk> i guess we could execute them but it seems weird
  664. # [16:06] <TabAtkins> Yay! That was my hope.
  665. # [16:06] <annevk> we also don't want to load external resources and all
  666. # [16:06] * Joins: MikeSmith (n=MikeSmit@EM114-49-129-87.pool.e-mobile.ne.jp)
  667. # [16:06] <TabAtkins> k, so worst case there are some document.write() embedded directly in the page. That shouldn't be at all significant.
  668. # [16:08] * Joins: yutak_home (n=kee@61.117.6.79)
  669. # [16:12] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  670. # [16:14] * Quits: pmuellr (n=pmuellr@69.61.162.35)
  671. # [16:14] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
  672. # [16:15] * Joins: pmuellr (n=pmuellr@69.61.162.35)
  673. # [16:16] * Joins: cedricv (n=cedric@116.197.222.9)
  674. # [16:20] * Quits: zcorpan_ (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
  675. # [16:24] * Quits: pmuellr (n=pmuellr@69.61.162.35)
  676. # [16:25] * Joins: Midler (n=midler@212.37.124.243)
  677. # [16:31] <annevk> argh, how do you write that :nth-child(4n+0) serializes to :nth-child(4n)
  678. # [16:32] <TabAtkins> Can you just outright state that +0 is dropped when there's a non-zero n term?
  679. # [16:33] <annevk> maybe, now I wonder what happens for 0n
  680. # [16:33] <TabAtkins> Preferably it would serialize to :nth-child(0).
  681. # [16:34] <annevk> Firefox does that
  682. # [16:34] <annevk> WebKit gives 0n
  683. # [16:34] <annevk> I guess Firefox wins
  684. # [16:34] <TabAtkins> What about 0n+2?
  685. # [16:34] <annevk> any idea why I can't have a space after n?
  686. # [16:34] <annevk> after ( I mean, e.g. in :not( [foo] )
  687. # [16:35] <TabAtkins> Huh? You can't? That's bizarre. Sounds like a spec bug.
  688. # [16:35] <annevk> it fails to parse in WebKit/Opera
  689. # [16:35] <annevk> not in Gecko though
  690. # [16:35] <TabAtkins> How strange.
  691. # [16:35] <TabAtkins> I doubt that it's correct to fail there.
  692. # [16:35] <annevk> 0n +2 gives 2 in Gecko
  693. # [16:36] <annevk> also gives 2 in Opera
  694. # [16:36] <annevk> Opera drops 0n on the floor
  695. # [16:36] <annevk> which might make sense because it never matches
  696. # [16:36] <TabAtkins> Yeah.
  697. # [16:36] <TabAtkins> I like that behavior.
  698. # [16:37] <annevk> WebKit also fails to parse for 0n+ 2 (note the space)
  699. # [16:37] <annevk> 0n+2 gives 0n+2
  700. # [16:37] * Joins: borismus (n=borismus@CMU-348674.WV.CC.CMU.EDU)
  701. # [16:38] <annevk> leading and trailing whitespace is allowed per CSS
  702. # [16:39] <TabAtkins> Yeah, just an under-permissive parser there then. Those need bugs.
  703. # [16:39] * Quits: dbgi2IAm (n=benny@cpe-65-185-164-233.neo.res.rr.com) (Read error: 104 (Connection reset by peer))
  704. # [16:39] * Joins: dbgi (n=benny@cpe-65-185-164-233.neo.res.rr.com)
  705. # [16:40] <annevk> odd becomes 2n+1
  706. # [16:40] <annevk> except in WebKit
  707. # [16:41] <TabAtkins> I forget - does n start at 0?
  708. # [16:41] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  709. # [16:41] <annevk> you found a spec bug
  710. # [16:41] <TabAtkins> Heh, ok.
  711. # [16:42] <annevk> the spec says 1, but the definition of odd/even assume 0
  712. # [16:42] <annevk> i think authors also assume 0
  713. # [16:42] <TabAtkins> I think everyone assumes 0, yeah.
  714. # [16:42] <Lachy> annevk, TabAtkins, you can't have spaces in :not( [foo] ) because a simple selector can't contain leading or trailing whitespace
  715. # [16:42] <annevk> TabAtkins, will you file a comment?
  716. # [16:42] * lmorchard|away is now known as lmorchard
  717. # [16:42] <TabAtkins> annevk: Where do I do so? Just the mailing list?
  718. # [16:42] <annevk> www-style
  719. # [16:43] <annevk> [css3-selectors] as subject
  720. # [16:43] <Lachy> oh, actually. The space says S* is allowed
  721. # [16:43] <TabAtkins> Yeah, I'll do so. One moment.
  722. # [16:43] <Lachy> The *spec* says...
  723. # [16:43] <annevk> also for :not?
  724. # [16:43] <annevk> hmm
  725. # [16:44] <Lachy> yeah, it says:
  726. # [16:44] <Lachy> negation
  727. # [16:44] <Lachy> : NOT S* negation_arg S* ')'
  728. # [16:44] <annevk> ah ok
  729. # [16:44] * Joins: borismus_ (n=borismus@CMU-348674.WV.CC.CMU.EDU)
  730. # [16:44] * Quits: borismus_ (n=borismus@CMU-348674.WV.CC.CMU.EDU) (Client Quit)
  731. # [16:45] <annevk> I guess I should file a bug on 0 -> ignored/error
  732. # [16:45] <TabAtkins> Hmm, you sure that it's a spec bug, annevk? It says that the index of the first element is 1, but that doesn't bear on the values used for n.
  733. # [16:45] * Quits: borismus (n=borismus@CMU-348674.WV.CC.CMU.EDU) (Read error: 54 (Connection reset by peer))
  734. # [16:46] <annevk> oh no, it's not
  735. # [16:46] <annevk> my bad
  736. # [16:46] * Quits: daedb (n=daed@h11n1fls34o986.telia.com) (Read error: 104 (Connection reset by peer))
  737. # [16:46] <TabAtkins> Ah, but it *does* say that an+b matches the bth element in each group of a elements. That's assuming 0-numbering.
  738. # [16:46] <annevk> though if you're writing an email now maybe you can bring up the :nth-child(0) issue
  739. # [16:46] <TabAtkins> Which then contradicts the "first element is 1" bit.
  740. # [16:46] <annevk> it also says "for a given positive integer or zero value of n"
  741. # [16:47] * Joins: daedb (n=daed@h11n1fls34o986.telia.com)
  742. # [16:47] * Quits: cedricv (n=cedric@116.197.222.9) (Read error: 131 (Connection reset by peer))
  743. # [16:47] <annevk> I guess it should say that a/b cannot be both zero at the same time
  744. # [16:47] <TabAtkins> Hmm, I think it's fine if they are, as long as it's clear that it means "0", which doesn't match anything.
  745. # [16:48] * Parts: ppattern (n=pattern_@ppp-58-8-117-195.revip2.asianet.co.th)
  746. # [16:48] <annevk> since it indicates an authoring error I think what Opera does (dropping the rule) makes more sense
  747. # [16:48] <TabAtkins> ... :nth-child(0) *doesn't* match anything, right? It shouldn't, per spec.
  748. # [16:50] <TabAtkins> Is there a difference between dropping it and just leaving it around as a non-matching rule?
  749. # [16:50] <annevk> yes
  750. # [16:51] <annevk> I thought you said CSS was easy? :p
  751. # [16:51] <TabAtkins> Arcana is never easy. ^_^
  752. # [16:52] <TabAtkins> I guess the difference is in, say, :not(:nth-child(0))?
  753. # [16:52] <annevk> difference is in the CSSOM, it is in whether :nth-child(0), p {} will match p elements, etc.
  754. # [16:53] <TabAtkins> Oh, I assumed that a dropped rule didn't invalidate the whole block.
  755. # [16:54] <MikeSmith> it will be interesting to see how CSSOM progresses
  756. # [16:54] <MikeSmith> annevk: you planning specific CSSOM discussion for CSS WG f2f at TPAC?
  757. # [16:54] <annevk> yeah, so far the chapters on Media Queries and Style Sheets in http://dev.w3.org/csswg/cssom/ are somewhat adequate
  758. # [16:54] <annevk> the rest needs work
  759. # [16:55] <annevk> MikeSmith, I can't attend the CSS WG meeting
  760. # [16:55] <Philip`> '":{N}{O}{T}(" return NOT;' - surely that should be ":"{N}{O}{T}"(" ?
  761. # [16:55] <MikeSmith> hmm
  762. # [16:55] <annevk> Philip`, prolly, email www-style
  763. # [16:55] * Quits: webben (n=benh@nat/yahoo/x-xlrklcmiylsfwhdn) (Remote closed the connection)
  764. # [16:55] <MikeSmith> sometimes I think CSS WG just has too much on its plate
  765. # [16:55] * Philip` is too lazy
  766. # [16:56] <annevk> CSS grammar is a gigantic pain
  767. # [16:56] * Joins: webben (n=benh@nat/yahoo/x-xpmkpozdrcqazqbq)
  768. # [16:56] <annevk> MikeSmith, it's not exactly clear to me how you'd split it up
  769. # [16:56] <MikeSmith> I guess we have too much too (as far as a API side)
  770. # [16:57] <annevk> I guess you could have syntax / object model vs layout vs text or some such
  771. # [16:57] <annevk> but they are something intertwined
  772. # [16:57] <annevk> s/something/somewhat/
  773. # [16:58] <annevk> and there's only a limited people with sufficient knowledge on all those topics anyway
  774. # [16:58] <annevk> number of people*
  775. # [16:58] <TabAtkins> Yeah, finding good editors is always the problem.
  776. # [16:58] <annevk> so whether they meet in three different groups or one really doesn't matter, you'll end up with the same 10 persons :)
  777. # [17:01] <TabAtkins> So it's like saying that HTML5 is too big, so we should split it up?
  778. # [17:01] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
  779. # [17:01] <Philip`> Maybe it's like saying the web is too big, so we should split it up into markup and styling and scripting etc in different groups
  780. # [17:02] * Joins: mat_t (n=mattomas@91.189.88.12)
  781. # [17:02] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  782. # [17:02] <TabAtkins> But that's clearly a silly idea, Philip`.
  783. # [17:02] <annevk> Philip`, emailed the grammar issue to www-style
  784. # [17:03] <TabAtkins> d'oh, Anne, I already sent a message about a=b=0, since you asked me too.
  785. # [17:04] <annevk> the orthogonality works to some extent except you do need to remember to build the bridges (e.g. the rendering section in HTML5)
  786. # [17:04] * Joins: zdobersek (n=zan@cpe-92-37-71-88.dynamic.amis.net)
  787. # [17:04] <annevk> TabAtkins, oh, I thought you didn't want to, sorry
  788. # [17:04] <TabAtkins> It's cool. It just means fantasai has to read both of our messages.
  789. # [17:05] <Philip`> annevk: Thanks
  790. # [17:05] <annevk> not a huge burden
  791. # [17:05] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  792. # [17:05] * Joins: ttepass- (n=ttepas--@p5B014821.dip.t-dialin.net)
  793. # [17:06] * Quits: yutak_home (n=kee@61.117.6.79) ("Ex-Chat")
  794. # [17:06] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Client Quit)
  795. # [17:13] * Quits: sylvaing (n=sylvaing@c-98-232-19-82.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  796. # [17:14] * Joins: ROBOd2 (n=robod@89.122.216.38)
  797. # [17:15] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  798. # [17:18] * Quits: ttepasse (n=ttepas--@p5B0154BE.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  799. # [17:31] * Quits: ROBOd (n=robod@89.122.216.38) (Read error: 110 (Connection timed out))
  800. # [17:36] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  801. # [17:53] * Joins: fishd_ (n=darin@nat/google/x-rnnbbktzhwngqtwz)
  802. # [17:53] * Joins: dglazkov (n=dglazkov@nat/google/x-sujoahpmeajgyndy)
  803. # [18:06] * Joins: gunderwonder (n=gunderwo@84.49.178.140)
  804. # [18:06] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  805. # [18:09] * Joins: bgalbraith (n=bgalbrai@palm-64-28-152-140.palm.com)
  806. # [18:11] * Joins: erlehmann (n=erlehman@82.113.106.0)
  807. # [18:17] * Joins: Lachy (n=Lachlan@85.196.122.246)
  808. # [18:20] * Joins: ap (n=ap@17.246.19.174)
  809. # [18:31] * Joins: pmuellr (n=pmuellr@69.61.162.35)
  810. # [18:33] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  811. # [18:35] * Quits: Phae (n=phaeness@gatea.mh.bbc.co.uk)
  812. # [18:37] * Joins: sylvaing (n=sylvaing@72-62-232-24.pools.spcsdns.net)
  813. # [18:37] <TabAtkins> Man, why does jQuery still use eval for JSON, when IE and FF (and maybe others?) have native JSON parsing now?
  814. # [18:38] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) ("Verlassend")
  815. # [18:54] * Joins: slightlyoff_ (n=slightly@204.14.154.228)
  816. # [18:55] * Quits: slightlyoff_ (n=slightly@204.14.154.228) (Client Quit)
  817. # [18:55] * Quits: slightlyoff (n=slightly@72.14.224.1) (Read error: 60 (Operation timed out))
  818. # [19:00] * Joins: jdouglas (n=jason@nat10.metaweb.com)
  819. # [19:01] * Joins: dave_levin (n=dave_lev@74.125.59.65)
  820. # [19:03] * Joins: mpt_ (n=mpt@canonical/mpt)
  821. # [19:05] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
  822. # [19:06] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 113 (No route to host))
  823. # [19:07] * Joins: mat_t (n=mattomas@91.189.88.12)
  824. # [19:10] * Joins: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
  825. # [19:12] * Quits: mat_t (n=mattomas@91.189.88.12) (Client Quit)
  826. # [19:12] * Parts: miketaylr (n=miketayl@38.117.156.163)
  827. # [19:15] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-cofxadiybxywqgkv)
  828. # [19:20] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  829. # [19:21] * Quits: sylvaing (n=sylvaing@72-62-232-24.pools.spcsdns.net) (Read error: 110 (Connection timed out))
  830. # [19:23] * Quits: yatil (n=Adium@78.104.102.186) ("Leaving.")
  831. # [19:24] * Joins: zdobersek1 (n=zan@cpe-92-37-67-178.dynamic.amis.net)
  832. # [19:25] * Quits: myakura (n=myakura@p2102-ipbf6805marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  833. # [19:30] * Quits: harig` (n=harig@213.236.208.22)
  834. # [19:34] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  835. # [19:35] * Joins: zdobersek2 (n=zan@cpe-92-37-74-96.dynamic.amis.net)
  836. # [19:36] * Joins: Lachy (n=Lachlan@85.196.122.246)
  837. # [19:39] * Quits: mpt_ (n=mpt@canonical/mpt) ("Ex-Chat")
  838. # [19:39] * Quits: zdobersek (n=zan@cpe-92-37-71-88.dynamic.amis.net) (Read error: 110 (Connection timed out))
  839. # [19:40] * Joins: roc (n=roc@121.72.198.60)
  840. # [19:46] * Joins: weinig (n=weinig@17.246.17.253)
  841. # [19:48] * Quits: smaug (n=chatzill@82.181.150.24) (Remote closed the connection)
  842. # [19:49] * Joins: smaug (n=chatzill@cs181150024.pp.htv.fi)
  843. # [19:49] * Quits: zdobersek1 (n=zan@cpe-92-37-67-178.dynamic.amis.net) (Read error: 110 (Connection timed out))
  844. # [19:51] * Joins: jwalden (n=waldo@nat/mozilla/x-uuhnfsblgsictfna)
  845. # [19:57] * Quits: foolip|work (n=philip@pat.se.opera.com) (Read error: 104 (Connection reset by peer))
  846. # [20:06] * Quits: weinig (n=weinig@17.246.17.253)
  847. # [20:06] * Joins: rubys1 (n=rubys@cpe-065-190-139-141.nc.res.rr.com)
  848. # [20:07] * Joins: weinig (n=weinig@17.203.15.239)
  849. # [20:09] * Joins: cying_ (n=cying@70.90.171.153)
  850. # [20:15] * Joins: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
  851. # [20:32] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  852. # [20:33] * Joins: annevk42 (n=annevk@c-c604e353.13-500-64736c15.cust.bredbandsbolaget.se)
  853. # [20:36] * Joins: maikmerten (n=maikmert@U021c.u.pppool.de)
  854. # [20:36] * Joins: maikmerten_ (n=maikmert@U021c.u.pppool.de)
  855. # [20:44] * Quits: maikmerten (n=maikmert@U021c.u.pppool.de) ("Leaving")
  856. # [20:48] * Parts: rubys1 (n=rubys@cpe-065-190-139-141.nc.res.rr.com)
  857. # [20:48] * Joins: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  858. # [20:50] * Joins: weinig_ (n=weinig@17.246.17.253)
  859. # [20:51] * Quits: weinig_ (n=weinig@17.246.17.253) (Client Quit)
  860. # [20:56] * Quits: svtech (n=stanv@83.228.56.37) (Read error: 113 (No route to host))
  861. # [20:59] * Joins: rodi_ (n=rodi01@cpe-98-154-249-109.socal.res.rr.com)
  862. # [21:03] <jgraham> Did we already have a discussion about the confusion that will arise when authors try to do document.createElement("svg") and expect it to work?
  863. # [21:04] * Quits: zdobersek2 (n=zan@cpe-92-37-74-96.dynamic.amis.net) (Read error: 104 (Connection reset by peer))
  864. # [21:05] * Quits: JoePeck (n=JoePeck@74.69.85.249) (Read error: 131 (Connection reset by peer))
  865. # [21:05] <annevk42> yes, we decided it was not worth the complexity of making it work
  866. # [21:05] * Joins: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  867. # [21:05] * Quits: bgalbraith (n=bgalbrai@palm-64-28-152-140.palm.com)
  868. # [21:05] * Joins: zdobersek (n=zan@cpe-92-37-74-96.dynamic.amis.net)
  869. # [21:06] * Parts: rodi_ (n=rodi01@cpe-98-154-249-109.socal.res.rr.com)
  870. # [21:06] <zcorpan_> the right solution for now is probably to have js libraries to paper over the confusingness
  871. # [21:07] * Quits: weinig (n=weinig@17.203.15.239) (Read error: 110 (Connection timed out))
  872. # [21:09] <jgraham> Right I don't really see how you woulf make it work in general
  873. # [21:09] <jgraham> All I can imagine is having createSVGElement and so on
  874. # [21:09] <jgraham> Which would mean that you didn't have to remember the namespace at least
  875. # [21:09] <zcorpan_> doug had an idea of Element.createElement
  876. # [21:09] <annevk42> the SVG WG has some plan on adding a bunch of constructors I believe
  877. # [21:10] <zcorpan_> which would use the same namespace as the element you're calling it on
  878. # [21:10] <jgraham> Interesting
  879. # [21:10] <jgraham> I guess that might help
  880. # [21:11] <zcorpan_> doesn't help if you want to create a new <svg> root in an html document
  881. # [21:11] <jgraham> Indeed
  882. # [21:12] <jgraham> I guess javascript libraries can just have tagname->namspace mappings
  883. # [21:12] <jgraham> which will almost-always work
  884. # [21:13] <zcorpan_> i think we should wait and see how js libraries solve this before extending dom core
  885. # [21:13] <annevk42> I sort of doubt they'll solve this on the element-level
  886. # [21:14] <annevk42> JS libraries that create SVG today have more high-level functionality
  887. # [21:15] <zcorpan_> if authors don't feel the need to solve it on the element level, we shouldn't extend dom core to solve it
  888. # [21:20] * Quits: roc (n=roc@121.72.198.60)
  889. # [21:23] * Quits: erlehmann (n=erlehman@82.113.106.0) ("Ex-Chat")
  890. # [21:24] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  891. # [21:26] * Quits: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) ("Leaving")
  892. # [21:29] * Joins: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi)
  893. # [21:29] * Joins: weinig (n=weinig@17.246.17.253)
  894. # [21:32] * Quits: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  895. # [21:35] <annevk42> jgraham, you really think the way the HTML parser works is a bug?
  896. # [21:35] * annevk42 kind of likes it
  897. # [21:44] * Quits: zdobersek (n=zan@cpe-92-37-74-96.dynamic.amis.net) (Remote closed the connection)
  898. # [21:45] * Quits: maikmerten_ (n=maikmert@U021c.u.pppool.de) (Remote closed the connection)
  899. # [21:54] * Quits: jwalden (n=waldo@nat/mozilla/x-uuhnfsblgsictfna) (Read error: 60 (Operation timed out))
  900. # [21:55] <deltab> TabAtkins: JSON.parse not in jQuery? it's release lag — the development version has it: http://code.jquery.com/jquery-nightly.js
  901. # [21:58] <jgraham> annevk42: I think the way the DOM layer works is unfortunate
  902. # [22:01] <annevk42> how should it work instead?
  903. # [22:03] <jgraham> In a way that doesn't require authors o understand XML namespaces
  904. # [22:03] <jgraham> (I don 't know if we could have done better in the circumstances though)
  905. # [22:04] <annevk42> ah ok
  906. # [22:04] <annevk42> yeah it would've been nicer if markup had been a bit more coordinated
  907. # [22:06] * Philip` notes that nobody has shipped SVG in text/html and so it wouldn't be too late to change that
  908. # [22:06] <annevk42> it would require changing how MathML and SVG work in XML and all
  909. # [22:06] <annevk42> at least, if I understand what jgraham is saying
  910. # [22:06] <Philip`> That part might be more of a problem
  911. # [22:07] <jgraham> I'm not really saying anything concrete
  912. # [22:07] <jgraham> I'm just saying that what we have is bad
  913. # [22:08] <jgraham> (and that we shouldn't use use this badness as an excuse for introducing more pervasive forms of the same badness)
  914. # [22:08] <annevk42> seems that Julian took it the wrong way
  915. # [22:09] * Quits: ROBOd2 (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  916. # [22:09] <jgraham> Oh I should check my email then
  917. # [22:15] * Joins: roc (n=roc@203.97.204.82)
  918. # [22:17] * Joins: zdobersek (n=zan@cpe-92-37-74-96.dynamic.amis.net)
  919. # [22:17] <TabAtkins> deltab: Ah, k. It's been around for a while, so I would have thought it'd be in 1.3.2. Shrug.
  920. # [22:18] <deltab> TabAtkins: 1.3.2 is ten months old! JSON.parse was added five months ago
  921. # [22:19] <TabAtkins> !_! really? Never mind, then.
  922. # [22:20] * Joins: othermaciej (n=mjs@17.203.15.188)
  923. # [22:20] <deltab> there's no newer release, mind — you have to use the svn version for something more up-to-date
  924. # [22:21] <TabAtkins> Yeah, I just wait for releases.
  925. # [22:25] * Quits: fishd_ (n=darin@nat/google/x-rnnbbktzhwngqtwz) (Read error: 60 (Operation timed out))
  926. # [22:27] * Quits: sebmarkbage (n=miranda@c29.a108.sto.bahnhof.net) (Read error: 104 (Connection reset by peer))
  927. # [22:28] * Quits: MikeSmith (n=MikeSmit@EM114-49-129-87.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  928. # [22:32] * Joins: jdouglas_ (n=jason@nat11.metaweb.com)
  929. # [22:33] * Joins: othermaciej_ (n=mjs@17.246.18.103)
  930. # [22:37] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  931. # [22:43] * Parts: zdobersek (n=zan@cpe-92-37-74-96.dynamic.amis.net)
  932. # [22:43] * Joins: cying__ (n=cying@70.90.171.153)
  933. # [22:46] * Quits: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote closed the connection)
  934. # [22:47] * Quits: jdouglas (n=jason@nat10.metaweb.com) (Read error: 110 (Connection timed out))
  935. # [22:47] * jdouglas_ is now known as jdouglas
  936. # [22:50] * Quits: othermaciej (n=mjs@17.203.15.188) (Read error: 110 (Connection timed out))
  937. # [22:50] * othermaciej_ is now known as othermaciej
  938. # [22:51] * Quits: othermaciej (n=mjs@17.246.18.103) (Remote closed the connection)
  939. # [22:51] * Joins: othermaciej (n=mjs@17.203.15.188)
  940. # [22:52] * Quits: cying_ (n=cying@70.90.171.153) (Read error: 145 (Connection timed out))
  941. # [23:04] * Joins: fishd_ (n=darin@nat/google/x-xtofrhiljebngfvc)
  942. # [23:04] * Joins: dglazkov_ (n=dglazkov@nat/google/x-ppjogmrkejqyonpo)
  943. # [23:05] * Quits: dglazkov_ (n=dglazkov@nat/google/x-ppjogmrkejqyonpo) (Client Quit)
  944. # [23:06] * Quits: dglazkov (n=dglazkov@nat/google/x-sujoahpmeajgyndy) (Read error: 60 (Operation timed out))
  945. # [23:08] * Joins: jwalden (n=waldo@nat/mozilla/x-nuyxvmwplpshekyp)
  946. # [23:11] * Joins: dglazkov (n=dglazkov@nat/google/x-edtaermubqcjdntg)
  947. # [23:13] * Quits: dglazkov (n=dglazkov@nat/google/x-edtaermubqcjdntg) (Read error: 54 (Connection reset by peer))
  948. # [23:13] * Joins: dglazkov (n=dglazkov@216.239.45.4)
  949. # [23:13] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) ("Leaving...")
  950. # [23:13] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  951. # [23:14] * Quits: cying__ (n=cying@70.90.171.153) (Read error: 131 (Connection reset by peer))
  952. # [23:14] * Joins: cying_ (n=cying@70.90.171.153)
  953. # [23:16] * Quits: jdouglas (n=jason@nat11.metaweb.com)
  954. # [23:18] * Joins: jdouglas (n=jason@nat10.metaweb.com)
  955. # [23:22] * Quits: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  956. # [23:28] * Joins: erlehmann (n=erlehman@82.113.106.0)
  957. # [23:29] * Quits: webben (n=benh@nat/yahoo/x-xpmkpozdrcqazqbq) (Read error: 110 (Connection timed out))
  958. # [23:31] * Joins: gsnedders (n=gsnedder@c83-252-237-97.bredband.comhem.se)
  959. # [23:32] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-cofxadiybxywqgkv) (Read error: 110 (Connection timed out))
  960. # [23:38] * Joins: bgalbraith (n=bgalbrai@palm-64-28-152-140.palm.com)
  961. # [23:38] * Quits: fishd_ (n=darin@nat/google/x-xtofrhiljebngfvc) (Connection timed out)
  962. # [23:42] * Quits: Midler (n=midler@212.37.124.243) ("Leaving.")
  963. # [23:42] * Joins: yael (i=d0309a43@gateway/web/freenode/x-kginxvphzprqbxnb)
  964. # [23:47] * Quits: dglazkov (n=dglazkov@216.239.45.4)
  965. # [23:49] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  966. # [23:51] * Joins: webben (n=benh@82.152.151.107)
  967. # [23:53] * Quits: webben (n=benh@82.152.151.107) (Client Quit)
  968. # [23:53] * Joins: dglazkov (n=dglazkov@nat/google/x-llvydowgewiktdej)
  969. # [23:56] * Joins: yatil (n=Adium@78.104.102.186)
  970. # Session Close: Wed Oct 21 00:00:00 2009

The end :)