/irc-logs / freenode / #whatwg / 2008-11-12 / end

Options:

  1. # Session Start: Wed Nov 12 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:00] <roc> I wonder if XHR will be enough to drive deployment of AC, or we'll be stuck in a chicken-and-egg situation
  4. # [00:03] <hsivonen> How common is it today with plug-in-based solutions that people have videos neither on same origin nor on a video-specializing site like youtube?
  5. # [00:03] <hsivonen> I wonder how onerous it would be to put AC on Akamai-hosted Stevenotes
  6. # [00:04] <roc> Getting this resolved is a super-high priority issue for us, by the way. We're shipping soon and if we're going to have restrictions, we need to implement them now, or we'll never be able to
  7. # [00:05] <Hixie> i don't think <video> uptake is going to be so fast that we couldn
  8. # [00:05] <Hixie> 't add restrictions in the next cycle
  9. # [00:05] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  10. # [00:05] * Hixie looks at the API to see what is currently exposed
  11. # [00:06] <Hixie> dimensions, size, bit rate, bandwidth to hosting site
  12. # [00:06] <Hixie> and existence
  13. # [00:06] <roc> maybe you're right, we've already identified some sites that would break if we added same-origin restrictions right now, and that's only going to get bigger
  14. # [00:06] <roc> ^ but
  15. # [00:06] <Hixie> sure
  16. # [00:07] <roc> duration
  17. # [00:07] <roc> format
  18. # [00:07] <Hixie> format?
  19. # [00:07] <roc> yeah
  20. # [00:07] <Hixie> i don't think we expose format explicitly in the spec
  21. # [00:07] <roc> I think you can fake it using <source> elements and redirects
  22. # [00:07] <Hixie> true
  23. # [00:07] <roc> er
  24. # [00:07] <roc> no redirects, just use currentSrc
  25. # [00:08] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  26. # [00:08] * Joins: pergj (n=pergj@65.219.59.50)
  27. # [00:08] <doublec> hsivonen, having media upload/download from a subdomain is quite common
  28. # [00:08] <doublec> which breaks without AC
  29. # [00:09] * Quits: webben (n=webben@nat/yahoo/x-c7bed17ddd8821ef) (Read error: 110 (Connection timed out))
  30. # [00:09] <hsivonen> doublec: ok
  31. # [00:14] <Hixie> i guess what we should do is not have cross-site restrictions for now, but when we add them to make it so that if there is AC metadata and it is negative, to block everything
  32. # [00:14] <Hixie> allowing opt-out of all video access, and opt-in to full metadata access
  33. # [00:14] <Hixie> defaulting to basically the current API set
  34. # [00:15] <Hixie> but we should be prepared to block that altogether if someone comes up with an unexpected attack vector
  35. # [00:16] <roc> ok
  36. # [00:16] <roc> so we'll leak all those things you mentioned, for media types?
  37. # [00:16] <Hixie> yeah
  38. # [00:16] <doublec> is it worth not exposing anything about the media until metadata loaded?
  39. # [00:16] <doublec> so progress events, etc don't get fired until after that?
  40. # [00:17] <Hixie> but if you disagree with that, or aren't comfortable with it, then implement AC, and then you'll make the de-facto decision be to have access limitations :-)
  41. # [00:17] <Hixie> and i'll spec that :-)
  42. # [00:17] <Hixie> that's the first mover advantage :-) of course the disadvantage is that you might have to change more later.
  43. # [00:17] <roc> like I said, there isn't even consensus within Mozilla
  44. # [00:18] <Hixie> doublec: what is fired so far? just loadstart and progress?
  45. # [00:18] <doublec> yes
  46. # [00:18] <Hixie> loadstart seems safe, since that'll fire regardless
  47. # [00:18] <doublec> so progress gives filesize, etc for example
  48. # [00:19] <Hixie> i could see omitting progress until you have the headers down, but you can't give the size until you have the headers anyway
  49. # [00:19] <Hixie> so you'd only be able to tell if the site was down or not
  50. # [00:19] <Hixie> which you can already tell using new Image()
  51. # [00:21] <roc> if we use a platform backend, we may not be able to tell whether it's a usable media file immediately after loading the headers
  52. # [00:26] <Hixie> i don't think exposing whether it's valid or not is a problem
  53. # [00:26] <Hixie> the concern is over not exposing that the file is not 404 until we've checked for AC headers
  54. # [00:33] * Quits: malware (n=MikeSmit@EM114-48-19-164.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  55. # [00:43] * Joins: csarven (n=csarven@modemcable150.182-202-24.mc.videotron.ca)
  56. # [00:44] * Quits: eric_carlson (n=ericc@17.203.15.222)
  57. # [00:45] <roc> we don't want to fire progress events before we know it's a media file
  58. # [00:45] <roc> and yes, we need to make sure that non-media files and 404s appear identically to the API user
  59. # [00:49] * Joins: sicking (n=chatzill@corp-242.mountainview.mozilla.com)
  60. # [00:50] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  61. # [00:57] * Joins: Lachy (n=Lachlan@lvcc-66-78-202-169.smartcity.com)
  62. # [01:03] * Quits: sayrer (n=sayrer@user-160ve45.cable.mindspring.com) ("Ex-Chat")
  63. # [01:14] <Hixie> man i wish people would put blank lines between their paragraphs
  64. # [01:15] * Quits: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk) (Read error: 145 (Connection timed out))
  65. # [01:24] <Lachy> I generally don't bother wasting my time trying to read emails that have been formatted poorly
  66. # [01:25] <Hixie> unfortunately i don't have that privilege really
  67. # [01:28] <Hixie> Philip`: fixed set/group for you
  68. # [01:29] <Philip`> Hixie: Thanks - you are too kind
  69. # [01:30] <Lachy> I have too many emails to read. I've been trying to get through my whatwg folder, but given all my travelling and poor quality internet access while not at home, it's difficult to even keep the unread messages below 900 :-(
  70. # [01:31] <Hixie> no worries, my unread is at 2677
  71. # [01:31] <Hixie> http://www.whatwg.org/issues/data.html :-)
  72. # [01:31] <Hixie> (for some definition of "unread" that is really "unreplied")
  73. # [01:34] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  74. # [01:38] * weinig_ is now known as weinig
  75. # [01:38] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
  76. # [01:39] * Quits: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  77. # [01:40] * Quits: dglazkov (n=dglazkov@nat/google/x-417d0fb569250c89)
  78. # [01:40] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  79. # [01:41] * aboodman2 is now known as doodman
  80. # [01:41] * doodman is now known as aboodman2
  81. # [01:45] * Joins: erlehmann (n=nils@dslb-092-078-100-246.pools.arcor-ip.net)
  82. # [01:57] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  83. # [02:01] <Lachy> I'm looking for things to do in Vegas this week. This looks like fun! :-) http://www.vegasindoorskydiving.com/
  84. # [02:01] <Lachy> it's right next door to my hotel too
  85. # [02:02] * Quits: aaronlev (n=chatzill@pool-71-243-102-201.bos.east.verizon.net) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  86. # [02:02] <jruderman> Lachy: indoor skydiving? shouldn't that be ceilingdiving?
  87. # [02:04] <gavin> their "celebrity spotting" link points to file:///C|/Users/Cherlyn%20Fields/Desktop/pictures2.php
  88. # [02:05] <Lachy> LOL
  89. # [02:05] <jruderman> i just tried to click that link :(
  90. # [02:06] <gavin> http://www.vegasindoorskydiving.com/pictures2.php works
  91. # [02:06] <gavin> though the thumbnails are full images, judging by how fast they loaded
  92. # [02:06] <Lachy> from one page, it links to http://www.vegasindoorskydiving.com/pictures2.php
  93. # [02:07] * Joins: MikeSmith (n=MikeSmit@EM114-48-134-219.pool.e-mobile.ne.jp)
  94. # [02:08] * Joins: shepazu (n=schepers@dhcp-246-194.mag.keio.ac.jp)
  95. # [02:08] <Lachy> I think I might go do that tonight and then head off to one of the casinos for dinner.
  96. # [02:09] <Lachy> But I still need to work out what to do for the rest of the week.
  97. # [02:09] <Lachy> Other than gambling away my life savings, I think I should go see a show or something
  98. # [02:10] * Joins: smerp (n=smerp@cpe-066-057-061-202.nc.res.rr.com)
  99. # [02:10] <Lachy> any recommendations?
  100. # [02:10] * Quits: pergj (n=pergj@65.219.59.50) (Read error: 110 (Connection timed out))
  101. # [02:10] <Hixie> avenue q
  102. # [02:11] <Hixie> though the vegas one is a truncated version
  103. # [02:12] <Lachy> is it still running?
  104. # [02:12] <Hixie> should be
  105. # [02:12] <Hixie> oh maybe not
  106. # [02:12] <Lachy> I found an New York Times article about it from 2006
  107. # [02:13] * Joins: smerp_ (n=smerp@66.192.95.199)
  108. # [02:15] <Hixie> spamalot apparently replaced it
  109. # [02:15] <Hixie> i imagine that's probably fun too
  110. # [02:15] <Hixie> but i don't know it
  111. # [02:16] * Joins: pergj (n=pergj@65.219.59.50)
  112. # [02:19] <Lachy> doesn't look like it is http://www.avenueq.com/tour/
  113. # [02:20] <Hixie> weee, they're coming to san jose in a few months!!!
  114. # [02:20] * Hixie marks his calendar for when the tickets go on sale
  115. # [02:20] <Hixie> lol, my girlfriend already marked it
  116. # [02:22] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  117. # [02:23] * Quits: aboodman (n=aboodman@72.14.229.81) (Read error: 60 (Operation timed out))
  118. # [02:28] * Quits: MikeSmith (n=MikeSmit@EM114-48-134-219.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  119. # [02:29] * Quits: smerp (n=smerp@cpe-066-057-061-202.nc.res.rr.com) (Read error: 110 (Connection timed out))
  120. # [02:30] <Lachy> damn, the wifi here is way too slow. I can't even read my email :-(
  121. # [02:30] <Lachy> oh well, I'm off to go dive into a giant fan. :-)
  122. # [02:31] <Hixie> later :-)
  123. # [02:31] * Quits: Lachy (n=Lachlan@lvcc-66-78-202-169.smartcity.com) ("This computer has gone to sleep")
  124. # [02:36] * Quits: pergj (n=pergj@65.219.59.50) (Read error: 110 (Connection timed out))
  125. # [02:53] * Quits: billmason (n=billmaso@ip41.unival.com) (".")
  126. # [02:53] * Joins: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  127. # [02:55] * Quits: weinig (n=weinig@17.203.15.152)
  128. # [03:00] * Joins: weinig (n=weinig@17.203.15.152)
  129. # [03:05] * Joins: MikeSmith (n=MikeSmit@EM114-48-161-95.pool.e-mobile.ne.jp)
  130. # [03:22] * Quits: weinig (n=weinig@17.203.15.152)
  131. # [03:33] * Quits: ojan (n=ojan@nat/google/x-5e9380ee3fc979b1) ("Leaving")
  132. # [03:40] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  133. # [03:43] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  134. # [03:48] * Parts: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  135. # [03:59] * Quits: aboodman2 (n=aboodman@72.14.229.81) (Read error: 110 (Connection timed out))
  136. # [04:04] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  137. # [04:04] * Joins: erlehmann_ (n=nils@dslb-092-078-105-178.pools.arcor-ip.net)
  138. # [04:08] * Quits: othermaciej (n=mjs@nat/apple/x-4e5e46be8b8a6fd1)
  139. # [04:11] * Joins: pergj (n=pergj@dhcp206-59-244-232.ssb.sjc.wayport.net)
  140. # [04:14] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  141. # [04:17] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  142. # [04:21] * Quits: erlehmann (n=nils@dslb-092-078-100-246.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
  143. # [04:29] * Quits: dbaron_ (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  144. # [04:31] * Quits: MikeSmith (n=MikeSmit@EM114-48-161-95.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  145. # [04:35] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  146. # [04:36] <Lachy> I managed to survive my sky dive, that was awesome
  147. # [04:36] <Lachy> it's definitely harder than it looks though
  148. # [04:36] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Connection timed out)
  149. # [04:44] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  150. # [04:49] * Joins: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net)
  151. # [04:54] <Lachy> I'm guessing Chris Wilson thinks the term vendor-lock-in is offensive in this contenxt because its companies like Microsoft that always get accused of it
  152. # [04:56] <roc> what context?
  153. # [04:59] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  154. # [05:00] * dglazkov_ is now known as dglazkov
  155. # [05:02] <Lachy> roc, see public-html
  156. # [05:02] <roc> oh
  157. # [05:02] <roc> no thanks!
  158. # [05:03] <Lachy> roc, why? Don't you read that list anymore?
  159. # [05:03] <roc> I never have
  160. # [05:03] * Quits: Mustafa51 (n=mustafa@122.164.205.212)
  161. # [05:03] * jwalden was going to type "any more?"
  162. # [05:04] <Lachy> jwalden, yeah, I meant "any more", but I didn't press space properly
  163. # [05:04] <jwalden> no, I was echoing roc, not criticizing a typo -- although I did notice it :-P
  164. # [05:04] <Lachy> oh
  165. # [05:05] <jwalden> always looked like a huge cesspool when I've occasionally skimmed web archives
  166. # [05:05] <jwalden> too many people who think they can cook spoil the broth
  167. # [05:07] <Lachy> I wonder where I should go for dinner tonight. I suppose there will be restaurants around in the casinos, if not cheaper ones elsewhere
  168. # [05:07] <jwalden> actually, casino restaurants may be cheaper, to entice you to come in and make up their loss inside
  169. # [05:07] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  170. # [05:07] <jwalden> that's how it was when I was traveling through the west with family a number of years ago
  171. # [05:09] <jwalden> hm, judging by message count public-html may have improved since I last looked at it
  172. # [05:16] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  173. # [05:18] * Quits: erlehmann_ (n=nils@dslb-092-078-105-178.pools.arcor-ip.net) (Read error: 60 (Operation timed out))
  174. # [05:24] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  175. # [05:26] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  176. # [05:26] * Quits: famicom_ (i=famicom@5ED2FF2D.cable.ziggo.nl) ("Leaving")
  177. # [05:34] * Joins: MikeSmith (n=MikeSmit@dhcp-246-119.mag.keio.ac.jp)
  178. # [05:42] * Lachy discovers that The Montecito casino featured in Las Vegas (the TV series) was fictional!
  179. # [05:43] <Lachy> until now, I just assumed it was a real one
  180. # [05:44] <Lachy> but at least the Bellagio from Ocean's 11 is real :-)
  181. # [05:47] * Joins: hdh (n=hdh@118.71.122.90)
  182. # [05:52] * Joins: smerp (n=smerp@cpe-066-057-061-202.nc.res.rr.com)
  183. # [05:55] <roc> for some definition of real
  184. # [06:05] * Joins: erlehmann (n=nils@dslb-092-078-105-178.pools.arcor-ip.net)
  185. # [06:09] * Quits: smerp_ (n=smerp@66.192.95.199) (Read error: 110 (Connection timed out))
  186. # [06:11] * Quits: csarven (n=csarven@modemcable150.182-202-24.mc.videotron.ca) (Read error: 104 (Connection reset by peer))
  187. # [06:18] * Joins: aboodman (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net)
  188. # [06:23] * Quits: roc (n=roc@202.0.36.64)
  189. # [06:31] * Quits: dglazkov (n=dglazkov@72.14.224.1)
  190. # [06:33] * Joins: gmaxwell (n=NT4TN@wikimedia/KatWalsh/x-0001)
  191. # [06:46] * Quits: jwalden (n=waldo@corp-241.mountainview.mozilla.com) (Remote closed the connection)
  192. # [07:15] * Joins: jwalden (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net)
  193. # [07:17] * Quits: smerp (n=smerp@cpe-066-057-061-202.nc.res.rr.com) ("Jesus Built My Workstation")
  194. # [07:18] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  195. # [07:22] * Quits: aboodman (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
  196. # [07:24] * Quits: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  197. # [07:27] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  198. # [08:00] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) (Read error: 110 (Connection timed out))
  199. # [08:04] * Joins: maikmerten (n=merten@129.217.26.195)
  200. # [08:10] * Joins: heycam (n=cam@124-168-34-173.dyn.iinet.net.au)
  201. # [08:19] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  202. # [08:27] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  203. # [08:40] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  204. # [08:44] * Joins: Mau`werk (n=ano@a80-100-71-209.adsl.xs4all.nl)
  205. # [08:52] * Joins: peter-proc (n=retep@procurios.xs4all.nl)
  206. # [08:58] * Joins: tthorsen (n=tommy@home.kvaleberg.no)
  207. # [09:02] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  208. # [09:12] * Joins: Lachy_ (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  209. # [09:13] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  210. # [09:19] * weinig is now known as weinig|zZz
  211. # [09:35] * Joins: hdh0 (n=hdh@118.71.122.90)
  212. # [09:35] * fakeolliej is now known as olliej
  213. # [09:43] * Joins: roc (n=roc@121-72-202-188.dsl.telstraclear.net)
  214. # [09:44] * Quits: hdh (n=hdh@118.71.122.90) (Read error: 145 (Connection timed out))
  215. # [09:59] * Quits: MikeSmith (n=MikeSmit@dhcp-246-119.mag.keio.ac.jp) (Read error: 110 (Connection timed out))
  216. # [10:08] * Quits: Lachy_ (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  217. # [10:08] <Hixie> oooh, leap second at the new year
  218. # [10:10] * hsivonen still thinks that needing announcement-based coordination for something as fundamental as time sucks big time
  219. # [10:11] <hsivonen> HTML5 should probably say that the system clocks are supposed to observe UTC but the calculations happen as if the numbers were UT1 times
  220. # [10:12] <Hixie> i think what it says now is clearer
  221. # [10:13] <Hixie> and how else would you do it? assuming that you want to keep the clocks in sync with the sun, that is
  222. # [10:13] <tthorsen> Couldn't you just adjust the velocity and rotation of the earth?
  223. # [10:14] <tthorsen> giant rocket-engines, maybe
  224. # [10:14] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  225. # [10:14] <hsivonen> Hixie: I think keeping solar year and atomic year in sync on that level of accuracy falls in the theoretical purity bucket
  226. # [10:14] <hsivonen> Posix time is sane
  227. # [10:15] <hsivonen> Hixie: I think at this point it's OK to leave sundial legacy UAs as a bit inaccurate
  228. # [10:16] <hsivonen> for the next few thousand years timezones already cause more sundial incompatibility than strict atomic time
  229. # [10:16] <Hixie> if you don't do this, then a few decades or centuries from now, you'll be a few hours off, and after a few thousand years, your noon will be at midnight.
  230. # [10:17] <hsivonen> oh. last time I calculated the max drift it was a lot smaller
  231. # [10:17] <hsivonen> perhaps I miscalculated
  232. # [10:19] <hsivonen> there are 3600 seconds in an hour
  233. # [10:19] <hsivonen> you can have at most 2 leap seconds per year
  234. # [10:19] <hsivonen> but the average is closer to one
  235. # [10:19] <hsivonen> so to get an hour of drift, you'd need to wait 3600 years
  236. # [10:20] <hsivonen> what did I calculate wrong?
  237. # [10:20] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  238. # [10:21] <hsivonen> and we accept an hour of drift every year. twice
  239. # [10:24] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  240. # [10:26] <Hixie> the average is closer to 1 ever 2 or 3 years iirc
  241. # [10:27] <Hixie> every
  242. # [10:27] <hsivonen> Hixie: doesn't that make my point stronger?
  243. # [10:34] <Hixie> drift takes a long time, yes
  244. # [10:35] <Hixie> apparently the average is 1.4 milliseconds per day per century
  245. # [10:36] <Hixie> average deceleraton of time, that is
  246. # [10:36] <Hixie> well, deceleration of earth
  247. # [10:36] <Hixie> (meaning longer days)
  248. # [10:37] <hsivonen> Hixie: it seems to me that an hour of drift in the cultural notation over 4000 years or so is less of a problem than trying to accommodate leap seconds in software
  249. # [10:38] <hsivonen> after all, by some accounts, the Earth is now only 6000 years old, so 4000 years is a relative long time
  250. # [10:42] <Hixie> well, if you can convince the relevant governments to decouple their civil time from astronomical measurements, then we'll go talk to the ITU
  251. # [10:42] <Hixie> the alternative, replacing leap seconds with leap hours, imho causes even more confusion
  252. # [10:42] <Hixie> and is far more likely to involve painful software bugs
  253. # [10:43] <Hixie> code that runs in production once every 4000 years is unlikely to be bug-free
  254. # [10:44] * Joins: ROBOd (n=robod@89.122.216.38)
  255. # [10:44] <hsivonen> Code that depends on external announcements is sure to perform different calculations before and after receiving an announcement
  256. # [10:44] <Hixie> (alternatively, you could just use TAI or GPS time instead of UTC)
  257. # [10:44] <Hixie> most code doesn't need to care about leap seconds
  258. # [10:45] <Hixie> because the clocks are likely to drift by more than that in normal operation anyway
  259. # [10:45] <hsivonen> the concept of civil time sucks
  260. # [10:45] <Hixie> so the normal clock-sync mechanisms will fix leap seconds for you
  261. # [10:45] * Joins: MikeSmith (n=MikeSmit@EM114-48-140-153.pool.e-mobile.ne.jp)
  262. # [10:46] <hsivonen> Hixie: I think it's acceptable to pretend that the current time is UTC as long as calculations don't implement UTC
  263. # [10:46] <hsivonen> implementing real UTC in software would be crazy
  264. # [10:46] <hsivonen> i.e. it's OK to do Posix time calculations and set the current time UTC
  265. # [10:47] <hsivonen> Hixie: have you seen the serious proposals for smoothing leap second transitions? those are some serious complexity
  266. # [10:47] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  267. # [10:48] <Hixie> UTC-SLS?
  268. # [10:49] <hsivonen> yeah
  269. # [10:49] <Hixie> most software wouldn't need to know about it
  270. # [10:49] <Hixie> as far as i can tell
  271. # [10:52] <roc> the whole notion of simultaneity is flawed. Each processor must maintain its own local time and compensate for relative velocities when translating times into other frames of reference
  272. # [10:53] <hsivonen> Hixie: doesn't it bother you that different pieces of software would do different conversions so if you use midnight to represent dates you get random-looking *day*-level drift?
  273. # [10:53] * Quits: MikeSmith (n=MikeSmit@EM114-48-140-153.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  274. # [10:53] <Hixie> not really, but maybe i don't understand what you mean
  275. # [10:54] * Joins: MikeSmith (n=MikeSmit@EM114-48-140-153.pool.e-mobile.ne.jp)
  276. # [10:54] <jgraham> roc: Don't forget variations in g
  277. # [10:54] <hsivonen> Hixie: the usual practice for representing dates to the precision of a day is to store seconds from a reference point and zero the least-significant seconds
  278. # [10:55] <Hixie> between hardware limitations (and, to a far lesser extent, relativistic, gravitational, and black-box radiation effects) and configuration errors, i doubt most consumer computers ever get anywhere near accurate enough for leap seconds to matter
  279. # [10:55] <hsivonen> Hixie: right, so leap seconds make no sense for "civil time"
  280. # [10:55] * jgraham wonders h
  281. # [10:55] <jgraham> what
  282. # [10:55] <hsivonen> and military time doesn't use them
  283. # [10:55] <hsivonen> hence, theoretical purity needless complexity bucket
  284. # [10:55] <jgraham> Hixie means by "black-box radiation effects"
  285. # [10:56] <zcorpan> tthorsen: the spec actually matches ie, except that ie hides what's in object
  286. # [10:56] <zcorpan> tthorsen: try <p><object></p></object>x
  287. # [10:56] <tthorsen> how about the extra <p></p>?
  288. # [10:56] <hsivonen> aside, teaching people to say UTC instead of GMT is like teaching them to say URI instead of URL
  289. # [10:56] <zcorpan> tthorsen: stray </p> means <p></p>
  290. # [10:57] <zcorpan> tthorsen: why is it a problem?
  291. # [10:57] <Hixie> hsivonen: civil time in many countries is legally defined in terms of astronomical state. if we're going to use SI seconds and 36400 seconds-per-day, then that breaks. so we either have to change the laws, or have leap seconds (or hours, or whatever)
  292. # [10:57] <Hixie> jgraham: caesium atomic clocks vary in speed based on ambient temperature
  293. # [10:58] <Hixie> jgraham: i meant blackbody radiation, my bad
  294. # [10:58] <tthorsen> It's not really a problem for me, but I thought it was a bug in the spec. Firefox and opera usually makes empty <p> elements when they see stray </p>'s but not in this case
  295. # [10:58] <Philip`> 36400 seconds per day would be pretty weird
  296. # [10:59] <zcorpan> tthorsen: that's because firefox and opera don't treat <object> as scoping
  297. # [10:59] <Hixie> er, 86400
  298. # [10:59] <zcorpan> yet
  299. # [10:59] <hsivonen> Hixie: naively, one would think laws were more malleable than the way Earth's orbit time divides by cesium pulses
  300. # [11:00] <tthorsen> ok, If this is the intended behaviour of the spec, then I'll happily change our test cases
  301. # [11:00] <Hixie> hsivonen: like i said, let me know when you get the laws changed, and we can take it to the ITU. :-)
  302. # [11:01] <tthorsen> after all this means that I get to do nothing, and the guy who's responsible for the tests needs to do all the work :-)
  303. # [11:01] <zcorpan> tthorsen: fwiw we've changed to match the spec (for our next major release)
  304. # [11:03] <tthorsen> zcorpan: sounds good to me. Fwiw we will also match the spec for our next major release.
  305. # [11:06] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  306. # [11:07] <tthorsen> zcorpan: The thing we talked about yesterday - about ignoring cdata in select tags. Do you know whether the spec will be changed or not?
  307. # [11:07] <jgraham> hsivonen: Per wikipedia leap seconds will be needed much more frequently in the future, although it seemes there is a plan to vote on the issue in 2011
  308. # [11:08] <tthorsen> I that case too, it doesn't really matter if the spec changes or not, but I'd like some kind of confirmation before I go ahead and get all our tests changed.
  309. # [11:08] <tthorsen> s/doesn't really matter/doesn't really matter to me/
  310. # [11:08] <jgraham> tthorsen: What usually happens is that we wait for Hixie to read the feedback, he makes a judgement call and then we complain again if we think he used faulty logic :)
  311. # [11:09] <jgraham> If it's a high priority for you then I suggest that you make him aware of that so he can schedule his priorities accordingly
  312. # [11:10] <tthorsen> Nah, the normal procedure sounds fine to me.
  313. # [11:11] <jgraham> (I should note that there is sometimes a multi-year delay between the feedback being recieved and it being considered in detail, although I guess the parsing section will be ouched much sooner than that)
  314. # [11:12] <jgraham> touched
  315. # [11:12] <takkaria> fwiw, NetSurf (browser using Hubbub) has had no reported problems with the current HTML5 algorithm, but it has a very small number of users and no scripting support
  316. # [11:15] * Joins: webben (n=webben@nat/yahoo/x-cef104336ff62e70)
  317. # [11:15] <tthorsen> well, a couple of the things I mentioned were mere clarification issues. A couple of things turned out to be the intended behaviour, and not a bug, after all. So in the end we don't see a lot of real problems either.
  318. # [11:16] <Hixie> oldest feedback still pending a reply is from unix time_t 1073954713
  319. # [11:16] <Hixie> whenever that is
  320. # [11:17] <Hixie> oldest feedback that's going to get a reply any time soon is from unix time_t 1101133613
  321. # [11:17] <Hixie> (the oldest feedback is about the rendering section)
  322. # [11:17] <takkaria> 13th January
  323. # [11:17] <takkaria> 2004
  324. # [11:17] <Hixie> wow, that's older than the whatwg
  325. # [11:18] <takkaria> and 22 November 2004 for the "reply any time soon" bit
  326. # [11:18] <Hixie> that makes more sense
  327. # [11:18] <tthorsen> takkaria: But, for instance the nested forms issue on http://bankrate.com, i think you'd be able to see in the NetSurf browser too. It's certainly very visible if you parse the html with html5lib and open it in firefox.
  328. # [11:18] <takkaria> yeah, there's definitely something going wrong there
  329. # [11:19] <tthorsen> the page is laid out in two floated columns, and when the two columns don't end up with the same parent, they don't end up next to each other.
  330. # [11:20] * takkaria nods, it looks a mess
  331. # [11:21] <Hixie> ok bed time
  332. # [11:21] <Hixie> nn
  333. # [11:37] * Quits: webben (n=webben@nat/yahoo/x-cef104336ff62e70) (Read error: 60 (Operation timed out))
  334. # [11:47] * Quits: erlehmann (n=nils@dslb-092-078-105-178.pools.arcor-ip.net) (Read error: 145 (Connection timed out))
  335. # [11:58] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  336. # [12:01] <tthorsen> zcorpan: You say that the next version of Opera will deal with scoping like in the html5 spec; how does the new Opera like this markup:
  337. # [12:02] <tthorsen> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3EAudio1%3C%2Fp%3E%0A%3Cp%3E%3Cobject%3E%3Cp%3EX%3C%2Fp%3E%3C%2Fp%3E%0A%3Cp%3EAudio2%3C%2Fp%3E%0A%3Cp%3E%3Cobject%3E%3Cp%3EY%3C%2Fp%3E%3C%2Fp%3E%0A%0A
  338. # [12:03] <tthorsen> The current Firefox and Opera makes sense of this - IE produces something really strange, and the html5 parser puts the two objects inside one another
  339. # [12:05] * Quits: MikeSmith (n=MikeSmit@EM114-48-140-153.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  340. # [12:31] <hsivonen> http://www.opensource.apple.com/darwinsource/10.5.5/autozone-77.1/README.html interesting
  341. # [12:32] * Quits: nessy (n=nessy@124-171-46-138.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  342. # [12:33] * Joins: nessy (n=nessy@124-171-46-138.dyn.iinet.net.au)
  343. # [12:40] <Philip`> hsivonen: Their explanation of "conservative" seems completely unrelated to what I'd usually understand conservative GC to be
  344. # [12:41] <hsivonen> Philip`: the usual conservative being related to guessing whether a word holds a pointer?
  345. # [12:41] <Philip`> (where I'd usually understand to mean that it doesn't always know whether some piece of memory is a pointer or an integer, so it conservatively assumes it's a pointer)
  346. # [12:42] <hsivonen> how does a garbage collector looking at the heap of a C++ process ever know that something is an integer and not a pointer?
  347. # [12:44] <Dashiva> Philip`: That's just half of it
  348. # [12:45] <Dashiva> The other half is that you can't move memory, because then you're either not updating pointers, or you are updating integers that aren't pointers, either way it's a loss
  349. # [12:46] <Philip`> hsivonen: In general, it can't; but you could restrict the language a bit, and make the compiler cleverer so it retains all the necessary type information at runtime, and then it could work
  350. # [12:47] <Philip`> (e.g. Java)
  351. # [12:48] <hsivonen> Philip`: sure, I get that it works with Java, but how does e.g. Boehm ever know what to collect?
  352. # [12:48] <Philip`> Dashiva: That seems to me like it's a consequence of conservatism, and not part of what conservatism itself actually means
  353. # [12:48] <Philip`> but I suppose that's just a matter of definition :-)
  354. # [12:49] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 60 (Operation timed out))
  355. # [12:49] * Joins: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp)
  356. # [12:49] <hsivonen> I guess I should read up on C++ garbage collection some time
  357. # [12:49] <Philip`> hsivonen: Boehm doesn't, so it's conservative
  358. # [12:49] <hsivonen> Philip`: so why does it ever collect anything?
  359. # [12:50] <hsivonen> ooh. never mind
  360. # [12:50] * hsivonen thought about things the wrong way round
  361. # [12:50] <Dashiva> I'm more confused by how they manage to do useful data flow analysis in c/c++ compilers
  362. # [12:51] <Philip`> I guess it just scans the stack for pointer-like things, and then scans the pointed-at memory regions for pointer-like things, until it's run out of things to scan, or something like that
  363. # [12:51] <Philip`> Dashiva: Usually they don't, because aliasing breaks everything :-)
  364. # [12:51] <Dashiva> Philip`: Pretty much what you said
  365. # [12:55] * Quits: olliej (n=oliver@122-57-98-9.jetstream.xtra.co.nz)
  366. # [12:58] <Philip`> C++ is a bit crazy when simply adding a "restrict" to a function argument can make your function go twice as fast
  367. # [12:58] <takkaria> I hope everyone's seen the closure syntax for C++0x
  368. # [12:59] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  369. # [12:59] <takkaria> ([](int x) { cout << x; })(3); will be valid C++
  370. # [13:00] <takkaria> or maybe it's [](int x){ cout << x; }(3);, I can't remember
  371. # [13:01] <Philip`> That doesn't seem excessively crazy
  372. # [13:02] * Philip` wasn't previously aware that C++0x had closure syntax
  373. # [13:02] <takkaria> "int main(void) { int x = 2; [=](){ x++; cout << x;}(); cout << x; }" will print "32" (the '=' means "capture by value inside the closure")
  374. # [13:03] <zcorpan> tthorsen: i get http://tinyurl.com/5ahcw7
  375. # [13:03] <takkaria> they've also added semi-automatic typing, such that "auto x = 3;" will declare x as an int
  376. # [13:03] <Dashiva> ... why
  377. # [13:04] <takkaria> http://blogs.msdn.com/vcblog/archive/2008/10/28/lambdas-auto-and-static-assert-c-0x-features-in-vc10-part-1.aspx
  378. # [13:04] <Dashiva> Have we learned nothing from fortran?
  379. # [13:04] <takkaria> if anyone fancies a read, that's got examples of a bunch of crazy syntax
  380. # [13:04] <Philip`> Hmm, I suppose they're not really closures, because they don't hang onto stack frames and you'll just end up crashing if you try to return them from functions and aren't careful
  381. # [13:05] <Philip`> I've wanted something like "auto" every time I've had to write "for (std::map<std::string, std::string>::iterator = m.begin(); ...)"
  382. # [13:05] <zcorpan> tthorsen: ie6 doesn't allow nested <object>s
  383. # [13:06] <zcorpan> not sure what ie8 does
  384. # [13:06] <zcorpan> tthorsen: firefox does the scoping thing with <applet> i think
  385. # [13:08] <hsivonen> Dashiva: isn't that auto thing more like JS than Fortran?
  386. # [13:09] <Dashiva> hsivonen: Looks to me like it only autotypes the declaration, you can't change types on assignment
  387. # [13:09] <Philip`> Dashiva: It's static typing, not like dynamic var in JS
  388. # [13:09] <Philip`> Uh
  389. # [13:09] <hsivonen> oh
  390. # [13:09] <Philip`> hsivonen: ^
  391. # [13:09] <hsivonen> doesn't seem useful
  392. # [13:10] <Philip`> As far as I'm aware, it just saves you having to type out the (often quite long, if it's using templates) type name on the LHS of a declaration when the compiler already knows the RHS's type
  393. # [13:10] <Dashiva> Apparently it's for storing lambdas
  394. # [13:11] <hsivonen> Philip`: as far as templated types go, I think this is a sign of a pretty severe problem: http://www.bdsoft.com/tools/stlfilt.html
  395. # [13:12] <Philip`> hsivonen: That's just a compiler implementation quality issue - they are all rubbish and print horribly verbose error messages :-(
  396. # [13:12] <tthorsen> zcorpan: It's interesting that you get that result. That _is_ certainly the same as what the html5 algorithm outputs.
  397. # [13:12] <Philip`> I got an infinitely long template error message once
  398. # [13:12] <hsivonen> Philip`: "just"? :-)
  399. # [13:12] <Philip`> (or at least the compiler generated a few hundred megabytes of error output before I killed it)
  400. # [13:13] <zcorpan> tthorsen: why is it interesting?
  401. # [13:14] <Philip`> hsivonen: There's no reason they couldn't include functionality equivalent to what stlfilt does
  402. # [13:15] * Philip` has been working with someone who's written a compiler that converts certain arbitrarily-complex algebraic expressions into executable code, which works by stringing together a whole load of templated library functionality into a single C++ type that performs the whole computation
  403. # [13:15] <tthorsen> zcorpan: well, it's not backwards compatible with the current behaviour of any of the browsers
  404. # [13:16] <Philip`> and the error messages are crazy, but otherwise it's actually pretty nice, and works much better than the other approaches that have been tried
  405. # [13:16] <hsivonen> Philip`: sounds like a shotgun aimed at foot
  406. # [13:17] <zcorpan> tthorsen: it's pretty broken in ie though so probably pages don't depend on any particular behavior. or have you found otherwise?
  407. # [13:17] <tthorsen> no. I only have a testcase. I'm not sure if that testcase is based on something that was found in the wild.
  408. # [13:17] <zcorpan> tthorsen: we found a site before that depended on this behavior for <applet> (the markup was something like <p><applet></p>foo</applet> where the "foo" wasn't expected to be rendered)
  409. # [13:20] <Philip`> hsivonen: But it works :-)
  410. # [13:21] <tthorsen> zcorpan: wow, you'd think ordering those tags sanely wouldn't be rocket science...
  411. # [13:22] <zcorpan> tthorsen: well, it's the web we're talking about, remember :)
  412. # [13:23] * hsivonen finds http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIDocument.h#729
  413. # [13:24] <Philip`> Even sane people will do something crazy if you give them a billion chances to mess it up :-)
  414. # [13:28] <tthorsen> Philip`: btw, I looked at the thing you posted yesterday with the "<code><pre>...</code></pre>...". It's kinda related to a problem I'm seeing myself
  415. # [13:29] <tthorsen> I've got "<abbr><p>abbr</abbr></p><acronym><p>acronym</acronym></p>" which doesn't work out quite right
  416. # [13:30] <tthorsen> Both seem to be related to step 3 of the "any other end tag" handling in "in body"
  417. # [13:31] <Philip`> I guess it only works correctly if you've got misnested formatting elements, or something?
  418. # [13:31] <Philip`> (<b><i>...</b></i> etc)
  419. # [13:32] * Philip` goes away
  420. # [13:41] <tthorsen> Philip`: Yes. Removing step 3 completely (or replacing it with a step that makes sure we don't go out of bounds on the stack of open elements) fixes these cases, but I don't feel very confident it's the right fix...
  421. # [13:49] * Quits: roc (n=roc@121-72-202-188.dsl.telstraclear.net)
  422. # [13:55] <zcorpan> is <code> a formatting element in webkit?
  423. # [13:56] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  424. # [13:56] <zcorpan> if you use <span> instead then webkit will nest
  425. # [13:57] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  426. # [13:58] <zcorpan> hmm firefox just closes <code> at <pre>
  427. # [13:59] <tthorsen> yeah. Opera and IE do the same thing, though
  428. # [14:00] <tthorsen> (at least my version of Opera does)
  429. # [14:02] <zcorpan> not quite, but yeah
  430. # [14:04] <zcorpan> (try to put some text between the end tags)
  431. # [14:12] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
  432. # [14:16] <tthorsen> I think Opera's result looks nice, but I'm not sure how to write the html5 spec to mimic that. When we get to the </code> we can't pop our way out to the <code> because that would remove the <pre>.
  433. # [14:16] * Quits: nessy (n=nessy@124-171-46-138.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  434. # [14:18] <tthorsen> This actually reminds me of what I proposed for both the nested forms case and the script handling in "after head" case. When we see the </code>, if there's a <code> in the stack of open elements, we just remove it.
  435. # [14:18] <zcorpan> tthorsen: what we do can't be mimicked without changing css
  436. # [14:19] <tthorsen> really? How does css affect this?
  437. # [14:19] <zcorpan> try http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ccode%20style%3Dcolor%3Ared%3E%3Cpre%3Ex%3C%2Fcode%3Ey%3C%2Fpre%3E
  438. # [14:21] * Quits: shepazu (n=schepers@dhcp-246-194.mag.keio.ac.jp)
  439. # [14:21] <tthorsen> the change I proposed just now, would do just that, wouldn't it?
  440. # [14:22] <zcorpan> note that only the "x" is red, not the "y"
  441. # [14:26] <tthorsen> oh, right. That's really weird. I would have thought that css should have been done after, and independently from, the parser.
  442. # [14:27] <tthorsen> ie: <code> has style color: red, y ends up inside <code>, so y should be red
  443. # [14:28] <zcorpan> right
  444. # [14:29] <tthorsen> is this behaviour in Opera considered a bug or a feature?
  445. # [14:30] <zcorpan> well per html5 it's a bug
  446. # [14:31] <zcorpan> i think the closest you can get rendering-wise is to make <code> a formatting element
  447. # [14:33] <tthorsen> yeah. That certainly does produce the same result in our browser
  448. # [14:39] * Quits: maikmerten (n=merten@129.217.26.195) (Read error: 110 (Connection timed out))
  449. # [14:40] * Quits: Mau`werk (n=ano@a80-100-71-209.adsl.xs4all.nl) (Read error: 60 (Operation timed out))
  450. # [14:43] * Joins: Mau`werk (n=ano@a80-100-71-209.adsl.xs4all.nl)
  451. # [14:47] * Joins: Lachy_ (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  452. # [14:54] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  453. # [15:13] * mpt_ is now known as mpt
  454. # [15:14] * Quits: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  455. # [15:21] * Quits: gmaxwell (n=NT4TN@wikimedia/KatWalsh/x-0001) ("Leaving")
  456. # [15:23] * Joins: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk)
  457. # [15:35] * Joins: eric_carlson (n=ericc@17.203.15.222)
  458. # [15:39] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  459. # [15:39] * Quits: Lachy_ (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 60 (Operation timed out))
  460. # [15:45] * Joins: maikmerten (n=merten@129.217.26.195)
  461. # [15:46] * Joins: gmaxwell (n=NT4TN@wikimedia/KatWalsh/x-0001)
  462. # [15:47] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  463. # [15:59] * Joins: smerp (n=smerp@66.192.95.199)
  464. # [16:02] * Joins: aaronlev (n=chatzill@pool-71-243-102-201.bos.east.verizon.net)
  465. # [16:04] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  466. # [16:04] * Quits: tthorsen (n=tommy@home.kvaleberg.no) ("Leaving")
  467. # [16:10] * Joins: kangax (n=kangax@static-71-244-90-14.ny325.east.verizon.net)
  468. # [16:13] * Parts: ehird (n=ehird@eso-std.org)
  469. # [16:28] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  470. # [16:33] * Joins: billmason (n=billmaso@ip41.unival.com)
  471. # [16:40] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) (Read error: 104 (Connection reset by peer))
  472. # [16:49] * Joins: csarven (n=csarven@80.76.201.52)
  473. # [16:50] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  474. # [16:50] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  475. # [16:52] * Joins: MikeSmith (n=MikeSmit@EM114-48-37-110.pool.e-mobile.ne.jp)
  476. # [16:52] * Quits: MikeSmith (n=MikeSmit@EM114-48-37-110.pool.e-mobile.ne.jp) (Read error: 104 (Connection reset by peer))
  477. # [16:53] * Joins: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net)
  478. # [17:01] * Joins: Mustafa51 (n=mustafa@122.164.168.224)
  479. # [17:03] * Quits: maikmerten (n=merten@129.217.26.195) (Remote closed the connection)
  480. # [17:06] * Quits: Mau`werk (n=ano@a80-100-71-209.adsl.xs4all.nl) ("Disconnected...")
  481. # [17:06] * Joins: aaronlev_ (n=chatzill@pool-71-243-102-201.bos.east.verizon.net)
  482. # [17:17] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  483. # [17:23] * Joins: aroben (n=aroben@unaffiliated/aroben)
  484. # [17:24] * Quits: Kuruma (n=Kuruman@h116-000-163-146.catv01.catv-yokohama.ne.jp) (Read error: 104 (Connection reset by peer))
  485. # [17:27] * Joins: Kuruma (n=Kuruman@h116-000-163-146.catv01.catv-yokohama.ne.jp)
  486. # [17:30] * Quits: aaronlev (n=chatzill@pool-71-243-102-201.bos.east.verizon.net) (Read error: 110 (Connection timed out))
  487. # [17:40] * Joins: MikeSmith (n=MikeSmit@EM114-48-37-110.pool.e-mobile.ne.jp)
  488. # [17:42] * Quits: pergj (n=pergj@dhcp206-59-244-232.ssb.sjc.wayport.net) (Read error: 113 (No route to host))
  489. # [17:45] * Quits: Lachy (n=Lachlan@wsip-24-234-142-17.lv.lv.cox.net) (Read error: 110 (Connection timed out))
  490. # [17:49] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  491. # [17:54] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  492. # [17:58] * Joins: dglazkov (n=dglazkov@nat/google/x-4b1cfe475829abb9)
  493. # [17:59] * Joins: Maurice` (i=copyman@5ED548D4.cable.ziggo.nl)
  494. # [18:00] * Quits: jwalden (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  495. # [18:01] * Joins: pergj (n=pergj@65.219.59.50)
  496. # [18:03] * Quits: csarven (n=csarven@80.76.201.52) (Remote closed the connection)
  497. # [18:14] * Quits: peter-proc (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  498. # [18:15] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  499. # [18:42] * Joins: nessy (n=nessy@124-171-46-138.dyn.iinet.net.au)
  500. # [18:46] * Joins: jwalden (n=waldo@corp-241.mountainview.mozilla.com)
  501. # [19:03] * Joins: aaronlev__ (n=chatzill@pool-71-243-102-201.bos.east.verizon.net)
  502. # [19:03] * aaronlev__ is now known as aaronlev
  503. # [19:06] * Joins: Lachy (n=Lachlan@lvcc-66-78-202-167.smartcity.com)
  504. # [19:09] * Joins: aboodman (n=aboodman@72.14.229.81)
  505. # [19:18] * Joins: aboodman2 (n=aboodman@72.14.229.81)
  506. # [19:24] * Quits: weinig|zZz (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  507. # [19:26] * Quits: aaronlev_ (n=chatzill@pool-71-243-102-201.bos.east.verizon.net) (Read error: 110 (Connection timed out))
  508. # [19:33] * Joins: csarven (n=csarven@80.76.201.52)
  509. # [19:36] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.83 [Firefox 3.1b2pre/20081111020233]")
  510. # [19:40] * Joins: maikmerten (n=maikmert@Lb11c.l.pppool.de)
  511. # [19:46] * Quits: nessy (n=nessy@124-171-46-138.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  512. # [19:50] * aroben is now known as aroben|meeting
  513. # [19:57] * Joins: erlehmann (n=nils@dslb-092-078-103-044.pools.arcor-ip.net)
  514. # [19:59] * Joins: weinig (n=weinig@nat/apple/x-2bf2f2b03de836b0)
  515. # [20:03] * Quits: Lachy (n=Lachlan@lvcc-66-78-202-167.smartcity.com) ("This computer has gone to sleep")
  516. # [20:08] * Parts: hdh0 (n=hdh@118.71.122.90) ("Konversation terminated!")
  517. # [20:12] * Quits: aaronlev (n=chatzill@pool-71-243-102-201.bos.east.verizon.net) (Read error: 60 (Operation timed out))
  518. # [20:36] * Hixie doesn't think it likely that we'll change the spec for <code><pre></code>
  519. # [20:36] <Hixie> really our only option is making <code> one of the quirky tags
  520. # [20:36] <Hixie> formatting tags
  521. # [20:36] <Hixie> and i'd rather not add more of those
  522. # [20:44] <Hixie> where on earth is zcorpan's dom core draft
  523. # [20:48] <hsivonen> Hixie: http://simon.html5.org/specs/web-dom-core
  524. # [20:48] <Hixie> thanks
  525. # [20:48] * Quits: kangax (n=kangax@static-71-244-90-14.ny325.east.verizon.net)
  526. # [20:50] <Hixie> hm, his appendChild() definition doesn't prevent elements appended to text nodes
  527. # [20:50] <Hixie> oh well
  528. # [21:13] <jgraham> Does actual badness occur is <code> is a formatting tag?
  529. # [21:17] * Joins: roc (n=roc@202.0.36.64)
  530. # [21:19] <hober> Seems like people can just write <pre><code>
  531. # [21:19] <hober> how often does <code><pre> even happen?
  532. # [21:22] * aroben|meeting is now known as aroben|lunch
  533. # [21:25] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  534. # [21:27] * Quits: Philip` (n=philip@zaynar.demon.co.uk) (Read error: 113 (No route to host))
  535. # [21:47] * Joins: Philip` (n=philip@zaynar.demon.co.uk)
  536. # [21:50] * Quits: MikeSmith (n=MikeSmit@EM114-48-37-110.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  537. # [21:50] <Philip`> Hixie: Not fixing <code><pre></code> is bad PR because it breaks early adopters :-(
  538. # [21:51] <Philip`> (specifically http://planet.intertwingly.net/ in "REST APIs must be hypertext driven")
  539. # [21:51] <Hixie> um, early adopters shouldn't use bad markup? :-)
  540. # [21:52] <Philip`> The early adopter didn't use bad markup; he used html5lib to sanitise other people's markup
  541. # [21:55] <Philip`> (under the assumption that html5lib would parse HTML in a way that's largely compatible with browsers; and browsers all handle <code><pre></code></pre> and get the 'correct' output)
  542. # [22:10] * Quits: maikmerten (n=maikmert@Lb11c.l.pppool.de) (Remote closed the connection)
  543. # [22:13] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  544. # [22:30] * Joins: Lachy (n=Lachlan@lvcc-66-78-202-167.smartcity.com)
  545. # [22:30] * Joins: gavin___ (n=gavin@people.mozilla.com)
  546. # [22:31] * Joins: sicking_ (n=chatzill@corp-242.mountainview.mozilla.com)
  547. # [22:33] * Quits: roc (n=roc@202.0.36.64) (lindbohm.freenode.net irc.freenode.net)
  548. # [22:33] * Quits: aboodman (n=aboodman@72.14.229.81) (lindbohm.freenode.net irc.freenode.net)
  549. # [22:33] * Quits: jwalden (n=waldo@corp-241.mountainview.mozilla.com) (lindbohm.freenode.net irc.freenode.net)
  550. # [22:33] * Quits: Kuruma (n=Kuruman@h116-000-163-146.catv01.catv-yokohama.ne.jp) (lindbohm.freenode.net irc.freenode.net)
  551. # [22:33] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (lindbohm.freenode.net irc.freenode.net)
  552. # [22:33] * Quits: sicking (n=chatzill@corp-242.mountainview.mozilla.com) (lindbohm.freenode.net irc.freenode.net)
  553. # [22:33] * Quits: wilhelm (i=wilhelm@trivini.no) (lindbohm.freenode.net irc.freenode.net)
  554. # [22:33] * Quits: Yudai (n=Yudai@pa3d18c.kngwnt01.ap.so-net.ne.jp) (lindbohm.freenode.net irc.freenode.net)
  555. # [22:33] * Quits: Dashiva (i=Dashiva@wikia/Dashiva) (lindbohm.freenode.net irc.freenode.net)
  556. # [22:33] * Quits: gavin (n=gavin@firefox/developer/gavin) (lindbohm.freenode.net irc.freenode.net)
  557. # [22:33] * Quits: syp (n=syp@lasigpc9.epfl.ch) (lindbohm.freenode.net irc.freenode.net)
  558. # [22:33] * Quits: doublec (n=chris@li5-223.members.linode.com) (lindbohm.freenode.net irc.freenode.net)
  559. # [22:33] * Quits: didymos (i=jho@rapwap.razor.dk) (lindbohm.freenode.net irc.freenode.net)
  560. # [22:33] * Quits: YaaL (i=yaal@hell.pl) (lindbohm.freenode.net irc.freenode.net)
  561. # [22:33] * Quits: gpy (i=gpy@193.138.219.74) (lindbohm.freenode.net irc.freenode.net)
  562. # [22:33] * Quits: bzed (n=bzed@devel.recluse.de) (lindbohm.freenode.net irc.freenode.net)
  563. # [22:33] * Quits: JohnResig (n=JohnResi@74.201.254.36) (lindbohm.freenode.net irc.freenode.net)
  564. # [22:33] * Quits: raspberry-lemon (n=lemon@raspberry-style.net) (lindbohm.freenode.net irc.freenode.net)
  565. # [22:33] * sicking_ is now known as sicking
  566. # [22:40] * Joins: tantek (n=tantek@c-98-210-195-2.hsd1.ca.comcast.net)
  567. # [22:42] * aroben|lunch is now known as aroben
  568. # [22:42] * Joins: aboodman (n=aboodman@72.14.229.81)
  569. # [22:43] * gavin___ is now known as gavin
  570. # [22:46] * Quits: pergj (n=pergj@65.219.59.50) (Read error: 110 (Connection timed out))
  571. # [22:46] * Joins: olliej (n=oliver@219-88-199-196.jetstream.xtra.co.nz)
  572. # [22:51] * Joins: pergj (n=pergj@65.219.59.50)
  573. # [22:51] * Joins: roc (n=roc@202.0.36.64)
  574. # [22:51] * Joins: Kuruma (n=Kuruman@h116-000-163-146.catv01.catv-yokohama.ne.jp)
  575. # [22:51] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  576. # [22:51] * Joins: wilhelm (i=wilhelm@trivini.no)
  577. # [22:51] * Joins: Yudai (n=Yudai@pa3d18c.kngwnt01.ap.so-net.ne.jp)
  578. # [22:51] * Joins: Dashiva (i=Dashiva@wikia/Dashiva)
  579. # [22:51] * Joins: syp (n=syp@lasigpc9.epfl.ch)
  580. # [22:51] * Joins: doublec (n=chris@li5-223.members.linode.com)
  581. # [22:52] * Joins: raspberry-lemon (n=lemon@raspberry-style.net)
  582. # [22:53] * Joins: jwalden (n=waldo@corp-241.mountainview.mozilla.com)
  583. # [22:53] * Joins: didymos (i=jho@rapwap.razor.dk)
  584. # [22:53] * Joins: YaaL (i=yaal@hell.pl)
  585. # [22:53] * Joins: gpy (i=gpy@193.138.219.74)
  586. # [22:53] * Joins: bzed (n=bzed@devel.recluse.de)
  587. # [22:53] * Joins: JohnResig (n=JohnResi@74.201.254.36)
  588. # [23:08] <Hixie> Philip`: well, there's not much we can do there since four browsers handle that markup in four different ways
  589. # [23:09] * Joins: nessy (n=nessy@124-171-46-138.dyn.iinet.net.au)
  590. # [23:10] <Philip`> Hixie: That means there's four ways that all result in the paragraph after the code being rendered properly (not monospaced text etc), so there's plenty of choices for HTML5 to copy :-)
  591. # [23:19] * Quits: Lachy (n=Lachlan@lvcc-66-78-202-167.smartcity.com) ("This computer has gone to sleep")
  592. # [23:19] * Quits: eric_carlson (n=ericc@17.203.15.222)
  593. # [23:21] * Quits: olliej (n=oliver@219-88-199-196.jetstream.xtra.co.nz)
  594. # [23:22] * Joins: olliej (n=oliver@219-88-199-196.jetstream.xtra.co.nz)
  595. # [23:23] * Quits: Maurice` (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  596. # [23:31] <Hixie> Philip`: maybe. of course, changing this will just result in other bugs, the question is which bugs do we want.
  597. # [23:33] <jgraham> Hixie: The ones that browsers already have :)
  598. # [23:33] <Hixie> they differ
  599. # [23:33] * Quits: heycam (n=cam@124-168-34-173.dyn.iinet.net.au) ("bye")
  600. # [23:37] <jgraham> Hixie: Well what I actually mean is that we want to pick something that will result in the rendering observed in browsers in cases where they are in agreement and try to limit our differences to cases where browsers differ
  601. # [23:38] <jgraham> (in agreement for rendering if not for the DOM)
  602. # [23:44] <Hixie> that's what we want to do, yes
  603. # [23:45] <Hixie> my point is that it's not clear that we're not already at a global minimum for that goal.
  604. # [23:47] <Philip`> It's clear that we're not, because you could rewrite the algorithm to say "if the document is equal to this multi-kilobyte string then return this particular DOM, else continue with the standard parser algorithm", which would result in the algorithm handling more pages correctly and wouldn't make any more be handled incorrectly
  605. # [23:47] * Joins: sverrej (n=sverrej@cm-84.208.153.202.getinternet.no)
  606. # [23:48] * Joins: ojan (n=ojan@nat/google/x-85f13fa2aa90843d)
  607. # [23:49] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  608. # [23:50] * Quits: smerp (n=smerp@66.192.95.199) (Read error: 60 (Operation timed out))
  609. # [23:53] * Joins: othermaciej (n=mjs@dsl081-052-219.sfo1.dsl.speakeasy.net)
  610. # Session Close: Thu Nov 13 00:00:00 2008

The end :)