/irc-logs / freenode / #whatwg / 2010-02-15 / end

Options:

  1. # Session Start: Mon Feb 15 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:00] * Joins: MikeSmith (~MikeSmith@EM114-48-129-191.pool.e-mobile.ne.jp)
  4. # [00:07] * Quits: deltab (~deltab@cpc1-smal2-0-0-cust270.perr.cable.virginmedia.com) (Read error: Connection reset by peer)
  5. # [00:08] * Joins: deltab (~deltab@cpc1-smal2-0-0-cust270.perr.cable.virginmedia.com)
  6. # [00:20] * Joins: twolfe18 (~twolfe18@c-71-61-180-11.hsd1.pa.comcast.net)
  7. # [00:20] * Quits: twolfe18 (~twolfe18@c-71-61-180-11.hsd1.pa.comcast.net) (Client Quit)
  8. # [00:34] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  9. # [00:34] * Joins: othermaciej_ (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  10. # [00:34] * othermaciej_ is now known as othermaciej
  11. # [00:37] * Joins: _Utkarsh (~admin@117.201.86.165)
  12. # [00:39] * Quits: Utkarsh (~admin@117.201.86.165) (Ping timeout: 240 seconds)
  13. # [00:42] * Quits: erlehmann (~erlehmann@82.113.121.125) (Quit: Ex-Chat)
  14. # [00:59] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115132715])
  15. # [01:03] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 245 seconds)
  16. # [01:08] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  17. # [01:11] * Quits: Lachy (~Lachlan@london.perfect-privacy.com) (Quit: Leaving)
  18. # [01:12] * Joins: JoePeck (~JoePeck@cpe-74-65-7-212.rochester.res.rr.com)
  19. # [01:14] * Quits: paul_irish (~paul_iris@c-71-192-163-128.hsd1.nh.comcast.net) (Remote host closed the connection)
  20. # [01:15] <Hixie> this style sheets blocking scripts stuff is a huge pain
  21. # [01:15] <Hixie> should they block appendChild()ed scripts?
  22. # [01:15] <Hixie> or only parser-inserted scripts?
  23. # [01:23] * Quits: wakaba_ (~wakaba_@122.139.210.220.dy.bbexcite.jp) (Ping timeout: 240 seconds)
  24. # [01:25] <othermaciej> hober: linking the design principles will be persuasive to some but may just set off others, so if your goal is persuasion I'd suggest dropping those
  25. # [01:28] <Hixie> someone objected to hidden=""?! o_O
  26. # [01:29] <Hixie> the one thing that is clearly and unambiguously an accessibility improvement?
  27. # [01:32] <AryehGregor> Is it? I mean, in real life, don't UAs for blind users screen-scrape graphical browsers and therefore ignore display:none anyway?
  28. # [01:32] <AryehGregor> I mean, ignore things that are display:none, as visual browsers do.
  29. # [01:33] <NickYoung> one would hope so
  30. # [01:33] <AryehGregor> Some people actually believe in aural stylesheets, don't they? :)
  31. # [01:35] * Joins: paul_irish (~paul_iris@c-65-96-162-9.hsd1.ma.comcast.net)
  32. # [01:35] <Hixie> AryehGregor: relying on the style sheet for anything that critical is not a long-term solution
  33. # [01:36] <AryehGregor> I'm not sure why not, since realistically, that's what authors do. So everyone will have to support it anyway. Not that I object to the attribute, it's one of the syntactic-sugar things in HTML5 that it's nice to think about actually being able to use in ten years or so.
  34. # [01:37] <daedb_> Are there *any* new features that hasn't had any objections?
  35. # [01:37] <Hixie> that's circular thinking. Authors can't do anything _but_ use CSS at the moment.
  36. # [01:37] <Hixie> daedb_: there's a lot of them that haven't been noticed by the people complaining, i think
  37. # [01:38] <AryehGregor> Well, I mean, so many authors rely so heavily on CSS to make their sites even basically functional that I can't imagine assistive technology would ever be able to get away with ignoring it.
  38. # [01:39] <AryehGregor> Of course, in well-written HTML, you're better off just ignoring the CSS. I once had a blind user in #mediawiki asking how to turn off all CSS on his wiki for blind users.
  39. # [01:39] <Hixie> HTML5 has added numerous features to try to reduce the need for CSS
  40. # [01:39] <Hixie> (for that kind of semantic-level stuff)
  41. # [01:40] <AryehGregor> I got into a discussion with him about AT, actually. He said Windows AT is horrible and ridiculously expensive, Linux AT is horrible but at least free, and Mac AT is awesome and comes with the OS, IIRC.
  42. # [01:40] <daedb_> Hixie: Maybe that's true, I've just become even more cynical after seeing all the "remove X new feature/element" bugs and discussions that I have a complete lack of surprise when new objections come up.
  43. # [01:41] <Hixie> AryehGregor: don't say that near the accessibility people, they'll say your blind user was biased against AT users
  44. # [01:41] <Hixie> (seriously, any time VO is brought up, the "experts" dismiss it as a toy)
  45. # [01:42] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  46. # [01:42] <AryehGregor> VO? Is that Mac's accessibility thing?
  47. # [01:42] <AryehGregor> I would expect Mac to have good built-in accessibility, actually. It's the sort of thing Apple does well.
  48. # [01:42] <Hixie> VoiceOver
  49. # [01:42] <AryehGregor> Whereas I'd also totally expect Windows to have cruddy built-in stuff so everyone has to pay a fortune to get their OS working at a basic level.
  50. # [01:43] <Hixie> oh i agree
  51. # [01:43] <AryehGregor> And I'd also expect Linux to have something built-in that's sort of workable but not really very good. So my expectations were totally satisfied. :P
  52. # [01:43] <Hixie> and that has totally been my experience in practice, playing with the various ATs, too
  53. # [01:43] <Hixie> but we're not "experts", so our experiences and opinions are worthless
  54. # [01:46] * Quits: paul_irish (~paul_iris@c-65-96-162-9.hsd1.ma.comcast.net) (Remote host closed the connection)
  55. # [01:47] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: Leaving)
  56. # [01:47] <Hixie> annevk: yt?
  57. # [01:47] <Hixie> MikeSmith: yt?
  58. # [01:52] * Quits: JoePeck (~JoePeck@cpe-74-65-7-212.rochester.res.rr.com) (Quit: JoePeck)
  59. # [02:03] * Joins: tkent (~tkent@220.109.219.244)
  60. # [02:05] * Joins: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  61. # [02:06] * beilabs_ is now known as beilabs
  62. # [02:17] * Quits: gunderwonder (~gunderwon@191.80-202-79.nextgentel.com) (Quit: gunderwonder)
  63. # [02:21] * Joins: paul_irish (~paul_iris@c-65-96-162-9.hsd1.ma.comcast.net)
  64. # [02:22] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  65. # [02:39] * Quits: Hixie (ianh@trivini.no) (Read error: Operation timed out)
  66. # [02:39] * Joins: Hixie (ianh@trivini.no)
  67. # [02:45] * Joins: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net)
  68. # [02:45] * Quits: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net) (Changing host)
  69. # [02:45] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  70. # [02:47] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  71. # [03:07] * Quits: _Utkarsh (~admin@117.201.86.165) (Ping timeout: 265 seconds)
  72. # [03:08] * Quits: bzed (~bzed@devel.recluse.de) (Read error: Operation timed out)
  73. # [03:08] <boblet> Hixie: currently datetime in HTML requires the colon in timezone. In uF wiki it’s recommended to drop colon to avoid confusing timezone and time
  74. # [03:08] <boblet> http://microformats.org/wiki/value-class-pattern#Date_and_time_parsing
  75. # [03:09] * Joins: cpearce_ (~cpearce@203-97-204-82.dsl.clear.net.nz)
  76. # [03:09] * Quits: cpearce (~cpearce@203-97-204-82.dsl.clear.net.nz) (Ping timeout: 245 seconds)
  77. # [03:09] * cpearce_ is now known as cpearce
  78. # [03:10] * Joins: bzed (~bzed@devel.recluse.de)
  79. # [03:10] <boblet> I’m guessing that HTML spec won’t include colonless style…
  80. # [03:10] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Ping timeout: 245 seconds)
  81. # [03:12] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 265 seconds)
  82. # [03:12] * Quits: grimboy (~grimboy@bcm-131-111-216-247.girton.cam.ac.uk) (Remote host closed the connection)
  83. # [03:13] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
  84. # [03:18] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 245 seconds)
  85. # [03:19] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  86. # [03:20] * Joins: wakaba_ (~wakaba_@119-228-219-41.eonet.ne.jp)
  87. # [03:27] <AryehGregor> I've never seen this happen in a Google cache result: http://74.125.113.132/search?q=cache:6v10d8GH4KEJ:aryeh.name/+aryeh+gregor&cd=7&hl=en&ct=clnk&gl=us
  88. # [03:28] <AryehGregor> The thing at the top sort of got squished into the page.
  89. # [03:28] <AryehGregor> Oh, I see, it's not an iframe or anything, they just inject everything into the page as a div.
  90. # [03:28] <AryehGregor> So my styling of <body> threw it off.
  91. # [03:29] <AryehGregor> Freaky.
  92. # [03:29] <AryehGregor> Great use-case for srcdoc="". ;)
  93. # [04:12] * Quits: beilabs (~beilabs@ppp121-44-120-55.lns20.syd6.internode.on.net) (Ping timeout: 276 seconds)
  94. # [04:14] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  95. # [04:15] <TabAtkins> AryehGregor: Huh, that's new. Cache results always *used* to be iframed, iirc.
  96. # [04:16] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  97. # [04:24] * Quits: MikeSmith (~MikeSmith@EM114-48-129-191.pool.e-mobile.ne.jp) (Ping timeout: 256 seconds)
  98. # [04:27] * Joins: beilabs (~beilabs@ppp121-44-122-3.lns20.syd6.internode.on.net)
  99. # [04:43] * Joins: surkov (~surkov@client-69-51.sibtele.com)
  100. # [04:46] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Ping timeout: 245 seconds)
  101. # [04:47] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  102. # [04:59] * Quits: TabAtkins (~chatzilla@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Ping timeout: 265 seconds)
  103. # [05:00] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Ping timeout: 245 seconds)
  104. # [05:12] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  105. # [05:15] * Joins: MikeSmith (~MikeSmith@EM114-49-134-29.pool.e-mobile.ne.jp)
  106. # [05:15] <MikeSmith> Hixie, here now
  107. # [05:17] <jcranmer> wait, Hixie's a cat now?
  108. # [05:17] * Quits: paul_irish (~paul_iris@c-65-96-162-9.hsd1.ma.comcast.net) (Remote host closed the connection)
  109. # [05:19] * Quits: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  110. # [05:19] * Joins: JoePeck (~JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  111. # [05:22] * Quits: surkov (~surkov@client-69-51.sibtele.com) (Quit: surkov)
  112. # [05:25] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Quit: roc)
  113. # [05:26] * Quits: JoePeck (~JoePeck@cpe-74-69-85-249.rochester.res.rr.com) (Quit: JoePeck)
  114. # [05:26] * Quits: annodomini (~lambda@wikipedia/lambda) (Quit: annodomini)
  115. # [05:29] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 246 seconds)
  116. # [05:35] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  117. # [05:44] * Quits: cpearce (~cpearce@203-97-204-82.dsl.clear.net.nz) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.15/2009101909])
  118. # [05:46] * Joins: surkov (~surkov@client-69-51.sibtele.com)
  119. # [05:47] * Quits: ttepasse (~ttepasse@dslb-084-060-073-183.pools.arcor-ip.net) (Quit: This computer has gone to sleep)
  120. # [05:52] * Quits: surkov (~surkov@client-69-51.sibtele.com) (Quit: surkov)
  121. # [05:52] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  122. # [06:03] * Quits: MikeSmith (~MikeSmith@EM114-49-134-29.pool.e-mobile.ne.jp) (Quit: This computer has gone to sleep)
  123. # [06:11] * Quits: Amorphous (jan@unaffiliated/amorphous) (Read error: Connection reset by peer)
  124. # [06:30] * Joins: Amorphous (jan@unaffiliated/amorphous)
  125. # [06:39] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 246 seconds)
  126. # [06:39] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  127. # [06:43] * Joins: roc (~roc@121-74-161-151.telstraclear.net)
  128. # [06:59] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  129. # [07:01] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  130. # [07:02] * Joins: ttepasse (~ttepasse@dslb-084-060-043-254.pools.arcor-ip.net)
  131. # [07:23] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  132. # [07:24] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  133. # [07:30] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  134. # [07:32] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  135. # [07:37] * Quits: roc (~roc@121-74-161-151.telstraclear.net) (Quit: roc)
  136. # [07:39] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  137. # [07:41] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  138. # [07:47] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  139. # [07:51] * Joins: surkov_ (~surkov@client-69-51.sibtele.com)
  140. # [07:53] * Quits: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds)
  141. # [07:56] <hober> Hixie: "someone objected to hidden=""?! o_O" yeah, that's what I said. It's why I volunteered to write the counter-proposal--hidden="" is one of the most no-brainer of HTML5 improvements over HTML4.
  142. # [07:56] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  143. # [07:57] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  144. # [08:02] <hober> othermaciej: hmm. I aim to be persuasive to those who can be persuaded. I'd like to think that, regardless of someone's stance on the Design Principles document *as a whole*, that they still find the specific principles I cite to be reasonable.
  145. # [08:02] <hober> If not, I'm not sure if anything I can write will have any effect.
  146. # [08:03] <hober> That said, if I can reword things so that I make the same points in a way where I don't have to cite the principles, and if that's worth doing in the first place, I could do that, sure.
  147. # [08:06] * Joins: FireFly (~firefly@unaffiliated/firefly)
  148. # [08:06] <hsivonen> how. lots of process email over the weekend...
  149. # [08:07] <hsivonen> s/how/wow/
  150. # [08:23] * Joins: cristianl (~cristianl@201-14-217-21.paemt704.dsl.brasiltelecom.net.br)
  151. # [08:24] * Quits: cristianl (~cristianl@201-14-217-21.paemt704.dsl.brasiltelecom.net.br) (Client Quit)
  152. # [08:30] * Joins: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  153. # [08:31] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  154. # [08:32] * Joins: Breakmau5 (~breakz@erft-5d808eea.pool.mediaWays.net)
  155. # [08:33] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  156. # [08:36] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 256 seconds)
  157. # [08:36] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  158. # [08:46] * Quits: virtuelv (~virtuelv_@162.179.251.212.customer.cdi.no) (Ping timeout: 245 seconds)
  159. # [08:53] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
  160. # [08:56] * Joins: gunderwonder (~gunderwon@191.80-202-79.nextgentel.com)
  161. # [09:00] * Joins: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de)
  162. # [09:03] * Quits: Hiall^ (~bleh@5ac2857a.bb.sky.com) (Read error: Connection reset by peer)
  163. # [09:06] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: Leaving)
  164. # [09:13] * Joins: pesla (~retep@procurios.xs4all.nl)
  165. # [09:15] * Joins: zalan (~zalan@catv-89-135-108-81.catv.broadband.hu)
  166. # [09:16] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
  167. # [09:22] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  168. # [09:23] * Quits: zalan (~zalan@catv-89-135-108-81.catv.broadband.hu)
  169. # [09:23] <annevk> Hixie, am here now
  170. # [09:23] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Ping timeout: 245 seconds)
  171. # [09:23] <annevk> reading da email
  172. # [09:25] * Joins: zalan (~zalan@catv-89-135-108-81.catv.broadband.hu)
  173. # [09:28] * Quits: gunderwonder (~gunderwon@191.80-202-79.nextgentel.com) (Quit: gunderwonder)
  174. # [09:29] * Joins: mat_t (~mattomasz@ppp-3-229.leed-b-2.access.uk.tiscali.com)
  175. # [09:40] * Quits: ttepasse (~ttepasse@dslb-084-060-043-254.pools.arcor-ip.net) (Quit: Verlassend)
  176. # [09:42] * Joins: svl (~chatzilla@a194-109-2-65.dmn.xs4all.nl)
  177. # [09:43] * Joins: Lachy (~Lachlan@southampton.perfect-privacy.com)
  178. # [09:43] * Joins: Necrathex (~bleptop@dhcp-077-249-097-016.chello.nl)
  179. # [09:45] * Joins: danbri (~danbri@unaffiliated/danbri)
  180. # [09:49] * Joins: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at)
  181. # [09:51] * Joins: danbri_ (~danbri@unaffiliated/danbri)
  182. # [09:52] * Quits: danbri (~danbri@unaffiliated/danbri) (Ping timeout: 258 seconds)
  183. # [09:54] * Joins: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net)
  184. # [09:54] * Quits: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net) (Changing host)
  185. # [09:54] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  186. # [10:01] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
  187. # [10:04] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
  188. # [10:04] * Quits: nattokirai (~nattokira@y226086.dynamic.ppp.asahi-net.or.jp) (Quit: nattokirai)
  189. # [10:05] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  190. # [10:07] * Quits: Lachy (~Lachlan@southampton.perfect-privacy.com) (Ping timeout: 246 seconds)
  191. # [10:08] * Joins: nattokirai (~nattokira@y226086.dynamic.ppp.asahi-net.or.jp)
  192. # [10:11] * Joins: gunderwonder (~gunderwon@garage.upstruct.com)
  193. # [10:12] * Joins: Lachy (~Lachlan@amsterdam.perfect-privacy.com)
  194. # [10:12] <annevk> http://dev.w3.org/csswg/cssom/#serialize-a-css-value
  195. # [10:12] <annevk> anyone with ideas how to rewrite that in a more extensible way?
  196. # [10:13] <annevk> there's value primitives, e.g. CSS <uri> value, CSS <number> value, etc.
  197. # [10:13] <annevk> then properties combine those in weird ways
  198. # [10:14] <annevk> e.g. comma-separated, space-separated
  199. # [10:14] <annevk> some values nest in function-like values, e.g. rect(<number>, ...)
  200. # [10:20] * Joins: mpt (~mpt@canonical/mpt)
  201. # [10:23] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115132715])
  202. # [10:32] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Quit: GarethAdams|Home)
  203. # [10:40] * Joins: ROBOd (~robod@89.122.216.38)
  204. # [10:41] <annevk> I guess I could just declare CSS a mess and do something else :)
  205. # [10:44] <Philip`> Then you'd just be moving onto a less important mess :-)
  206. # [10:51] <hsivonen> looks like the W3C is still in the mobile adaptation land: http://www.w3.org/2010/02/mbui/cfp
  207. # [10:51] * Quits: beilabs (~beilabs@ppp121-44-122-3.lns20.syd6.internode.on.net) (Ping timeout: 252 seconds)
  208. # [10:53] <hsivonen> does anyone have keygen test cases?
  209. # [10:54] <hsivonen> looks like googling for keygen is useless, because the work has been taken by the warez d00dz
  210. # [10:54] <hsivonen> s/work/word/
  211. # [10:55] * Joins: beilabs (~beilabs@ppp121-44-122-3.lns20.syd6.internode.on.net)
  212. # [10:55] <jgraham> Hixie: I like "James Graham did most of the work [...] the system is relatively fragile" :)
  213. # [10:56] * Quits: Lachy (~Lachlan@amsterdam.perfect-privacy.com) (Quit: This computer has gone to sleep)
  214. # [11:09] * Quits: mat_t (~mattomasz@ppp-3-229.leed-b-2.access.uk.tiscali.com) (Quit: This computer has gone to sleep)
  215. # [11:11] * Joins: Lachy (~Lachlan@pat.se.opera.com)
  216. # [11:15] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  217. # [11:38] * Joins: mat_t (~mattomasz@ppp-3-229.leed-b-2.access.uk.tiscali.com)
  218. # [11:42] * Quits: beilabs (~beilabs@ppp121-44-122-3.lns20.syd6.internode.on.net) (Ping timeout: 256 seconds)
  219. # [11:42] * Joins: beilabs (~beilabs@ppp121-44-122-3.lns20.syd6.internode.on.net)
  220. # [11:42] <hsivonen> does anyone have an example of great video use in a Wikipedia article?
  221. # [11:44] * Joins: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  222. # [11:44] * Quits: wakaba_ (~wakaba_@119-228-219-41.eonet.ne.jp) (Ping timeout: 245 seconds)
  223. # [11:45] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  224. # [11:49] <hsivonen> http://en.wikipedia.org/wiki/Polar_bear is the best example I've found so far (the play-fight video; the nursing video is badly encoded)
  225. # [11:49] * Quits: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 245 seconds)
  226. # [12:09] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  227. # [12:09] * Joins: surkov (~surkov@client-67-135.sibtele.com)
  228. # [12:10] * Joins: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net)
  229. # [12:11] * Quits: surkov_ (~surkov@client-69-51.sibtele.com) (Ping timeout: 240 seconds)
  230. # [12:13] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  231. # [12:17] * pesla is now known as peslafk
  232. # [12:18] * Joins: Multiply (multiply@unaffiliated/multiply)
  233. # [12:26] <annevk> hmm, it seems implementations preserve more information than needed
  234. # [12:26] <annevk> e.g. absolute length values are not normalized
  235. # [12:30] <hsivonen> yay. http://jilion.com/sublime/video now works in Firefox
  236. # [12:31] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  237. # [12:32] <hsivonen> doesn't work in Opera :-(
  238. # [12:39] * Quits: Breakmau5 (~breakz@erft-5d808eea.pool.mediaWays.net) (Ping timeout: 265 seconds)
  239. # [12:44] <Necrathex> hsivonen: very nice :o
  240. # [12:44] <Necrathex> firefox seems rather slow though (compared to chromium)
  241. # [12:45] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Ping timeout: 272 seconds)
  242. # [12:53] <nessy> hsivonen: also works on the iPhone - that's nice!
  243. # [12:53] * Joins: Utkarsh (~admin@117.201.90.49)
  244. # [12:54] <nessy> though I'm not sure how the source selection picks it since there is no media query or anything else on it
  245. # [12:55] <nessy> works fine for me on Firefox 3.7
  246. # [13:07] <Lachy> nessy, it seems to use a script, presumably with UA sniffing, for the source selection.
  247. # [13:08] <Lachy> since it's using <source title="http://..."> rather than <source src="http://...">. I'm guessing it changes the title attributes to src attributes based on the detection
  248. # [13:08] <nessy> thanks for tracking it down - I admit I couldn't be bothered ;-)
  249. # [13:08] <nessy> ah, that's a good point
  250. # [13:08] <Lachy> that might explain why it doesn't work in Opera, if they haven't done good UA sniffing
  251. # [13:08] <nessy> I wonder if media queries would really help in this case
  252. # [13:09] <hsivonen> they also aren't using whatever prefix Opera supports for rounder corners
  253. # [13:09] <hsivonen> vendor prefixes for the lose
  254. # [13:10] <hsivonen> so I've promised to give my lecture about HTML5 again tomorrow at my alma mater
  255. # [13:10] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
  256. # [13:10] <hsivonen> I wonder how much I should edit my slides from the last year...
  257. # [13:10] <nessy> :)
  258. # [13:11] <nessy> I'm going to have a similar challenge next week :)
  259. # [13:11] <hsivonen> I think I'll zap the drag&drop demo
  260. # [13:11] <hsivonen> maybe I should also zap the postMessage demo and show pieces of code instead
  261. # [13:12] <hsivonen> also, it would be nice to have a less violent canvas demo than Wolf3D
  262. # [13:12] <hsivonen> I guess I should talk and show more <video> stuff
  263. # [13:12] <hsivonen> and I should say something about microdata and RDFa
  264. # [13:13] <hsivonen> but I don't really know what to say without getting too much into politics
  265. # [13:16] <Lachy> just talk about the benefits of Microdata, and don't focus on RDFa much at all
  266. # [13:19] * Quits: seventh (seventh@189.59.206.63) (Remote host closed the connection)
  267. # [13:20] <Lachy> that reminds me, I need to write up my proposal for Web Directions South later. The deadline for that is coming up soon
  268. # [13:20] * Philip` 's canvas demo is entirely non-violent, because he was too lazy to implement guns
  269. # [13:21] <gsnedders> Philip`: I thought you at least had a multiplayer version somewhere?
  270. # [13:21] <Philip`> Yes, on my hard disk somewhere, but that didn't have guns either
  271. # [13:22] <ment> hsivonen: what's wrong with violent demos? :)
  272. # [13:22] * Joins: mpt (~mpt@canonical/mpt)
  273. # [13:22] <Philip`> (Just walking, and text chat)
  274. # [13:22] * Joins: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at)
  275. # [13:22] <gsnedders> Yeah, I thought you hadn't implemented that.
  276. # [13:23] <gsnedders> But what the use of a multiplayer FPS without guns is I'm not sure
  277. # [13:23] <gsnedders> Second life in the browser?
  278. # [13:23] <Philip`> You could have an FPS with only melee weapons
  279. # [13:24] <hsivonen> what canvas 3D demo should I show?
  280. # [13:24] <Philip`> Could do something like Second Life, but I'm not sure what the point would be
  281. # [13:24] <hsivonen> (preferrably something that doesn't hang my Intel GPU)
  282. # [13:25] <Philip`> (since Second Life already exists)
  283. # [13:25] <hsivonen> so no complex shaders
  284. # [13:25] <Philip`> (and being in a web browser would just make it technologically worse)
  285. # [13:26] <Philip`> hsivonen: You mean WebGL, rather than 3D emulated in the 2D context?
  286. # [13:26] <hsivonen> Philip`: WebGL, yes
  287. # [13:26] <Philip`> Does it work at all on your GPU?
  288. # [13:26] <hsivonen> maybe I should have a 2D game demo for the 2D context instead of Wolf3D
  289. # [13:26] * Quits: sebmarkbage (~miranda@213.80.108.29) (Remote host closed the connection)
  290. # [13:26] <hsivonen> Philip`: it does
  291. # [13:26] * Joins: yutak_home (~kee@N038037.ppp.dion.ne.jp)
  292. # [13:26] * Philip` doesn't remember when Intel started having GLSL support
  293. # [13:26] * Joins: Michelangelo (~Michelang@93-41-59-43.ip80.fastwebnet.it)
  294. # [13:27] <hsivonen> Philip`: sicking's shader-based fractals hang the intel GPU, though
  295. # [13:28] <jgraham> Philip`: Aren't you already working on some game that is quite like a number of existing games?
  296. # [13:28] <Philip`> Maybe there are some X3DOM examples that could work? (since they don't rely on fancy shaders, and demonstrate the ability to provide APIs that are more user-friendly than raw OpenGL)
  297. # [13:28] <hsivonen> does Opera support Drag&Drop yet?
  298. # [13:28] <jgraham> hsivonen: No
  299. # [13:29] <Philip`> jgraham: Yes, but it's not being artificially worsened by putting it in a web browser for no reason :-)
  300. # [13:31] * Joins: seventh (seventh@189.59.206.63)
  301. # [13:32] <hsivonen> Maybe I'll throw in geolocation and Web Workers now that HTML5 proper doesn't contain everything I talked about last year anyway
  302. # [13:32] * Philip` hasn't used SL-style programs since Alpha World on a dialup modem, where they hadn't even implemented teleportation so he had to run 10km to reach his house on the outskirts of the city, and where one day somebody discovered the .ini file that controls your avatar so everyone in the world changed themselves into chess pieces and lamp posts and floor tiles
  303. # [13:32] <Philip`> Maybe they're a bit more advanced now?
  304. # [13:34] <annevk> hsivonen, where are you presenting?
  305. # [13:35] <hsivonen> annevk: https://noppa.tkk.fi/noppa/kurssi/t-111.5360/esite
  306. # [13:36] <gsnedders> Philip`: Floor tiles? How does that work?
  307. # [13:36] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  308. # [13:37] * Parts: zcorpan (~zcorpan@pat.se.opera.com)
  309. # [13:37] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
  310. # [13:38] <Philip`> gsnedders: The world consisted entirely of a flat infinite plane of grass, plus a load of objects (textured meshes) that users could create and move and rotate and slightly script
  311. # [13:39] <Philip`> so floors were built out of lots and lots of flat square floor tiles
  312. # [13:39] * Parts: zcorpan (~zcorpan@pat.se.opera.com)
  313. # [13:39] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
  314. # [13:39] <Philip`> and there was nothing stopping you picking one of those objects as your avatar
  315. # [13:39] <gsnedders> Philip`: So your avatar was a bunch of flat squares?
  316. # [13:40] <Philip`> No, a single flat square
  317. # [13:40] <gsnedders> That's what I thought when you first mentioned it.
  318. # [13:40] <gsnedders> That must make seeing other people fun
  319. # [13:40] <Philip`> The developers fixed it after a few days, sadly :-(
  320. # [13:40] <Philip`> so you could only be the normal human shape
  321. # [13:46] * Quits: danbri_ (~danbri@unaffiliated/danbri) (Quit: Leaving...)
  322. # [13:47] * Joins: myakura (~myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp)
  323. # [13:50] * Joins: FireFly (~firefly@unaffiliated/firefly)
  324. # [13:50] <hsivonen> I have trouble finding WebGL demos that show something that's obviously not 2D canvas emulating 3D
  325. # [13:51] * Quits: nessy (~Adium@124-168-170-167.dyn.iinet.net.au) (Quit: Leaving.)
  326. # [13:54] <zcorpan> device-min-width makes some sense for <source media>
  327. # [13:57] <hsivonen> I think https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/shiny-teapot/index.html is probably most obviously using WebGL and not just emulating stuff in the 2D API
  328. # [14:08] <Dashiva> For all of Shelley's talk about FUD, this message seems like a quite good candidate: http://lists.w3.org/Archives/Public/public-html/2010Feb/0423.html
  329. # [14:09] * Joins: MikeSmithX (~MikeSmith@EM114-49-29-244.pool.e-mobile.ne.jp)
  330. # [14:10] * Quits: yutak_home (~kee@N038037.ppp.dion.ne.jp) (Quit: Ex-Chat)
  331. # [14:10] * Joins: pmuellr (~pmuellr@nat/ibm/x-xtldyezopdpdkslb)
  332. # [14:10] <annevk> hmm, <canvas> exposes system colors, is that a privacy leak?
  333. # [14:11] * Joins: danbri (~danbri@unaffiliated/danbri)
  334. # [14:13] <workmad3> annevk: it may be, if you set your system colours to hex-encoded versions of your credit-card numbers and SSN
  335. # [14:15] <annevk> it seems system colors are lost with .fillStyle
  336. # [14:15] <annevk> at least per spec
  337. # [14:15] <annevk> in opera they're always lost it seems
  338. # [14:15] <Dashiva> What about the text api?
  339. # [14:17] <annevk> system colors can presumably be used via fillStyle as another means to uniquely pin down people
  340. # [14:17] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 246 seconds)
  341. # [14:18] <annevk> unless we somehow forbid them in <canvas> and always return them as keywords through DOM APIs
  342. # [14:18] <annevk> it's annoying that when you try to do something relatively simple (serialization of <color>) so many side-issues come up
  343. # [14:20] <workmad3> I'm not sure how much of a privacy leak it is tbh
  344. # [14:21] <annevk> not a whole lot for sure
  345. # [14:21] <workmad3> you could possibly pin down the identity of some people with system colours, but you couldn't pin down the identity of everybody
  346. # [14:21] * Quits: Lachy (~Lachlan@pat.se.opera.com) (Quit: This computer has gone to sleep)
  347. # [14:21] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  348. # [14:21] <annevk> no, but lots of other variables can be used
  349. # [14:21] <workmad3> as most people don't bother changing system colours or use one of a set of pre-defined defaults
  350. # [14:22] <Dashiva> I wouldn't worry about privacy leak, rather that it lets people create more authentic-looking fake chrome
  351. # [14:23] <Dashiva> But I suppose they can do that already?
  352. # [14:23] <zcorpan> they can do that by just using the system colors
  353. # [14:23] <annevk> that's the whole point of system colors
  354. # [14:24] * Joins: Lachy (~Lachlan@pat.se.opera.com)
  355. # [14:40] * Joins: TabAtkins (~chatzilla@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  356. # [14:41] <boblet> annevk: looking at http://www.w3.org/TR/html5-diff/ and noticed 3.1 figure example has <legend> (plus <figcaption> should be in the list)
  357. # [14:41] <boblet> annevk: want me to file a bug somewhere?
  358. # [14:42] <zcorpan> boblet: TR/ means out-of-date (unless we published very recently)
  359. # [14:43] <boblet> zcorpan: yeah, it’s Aug 2009 :) no similar use of bugtracker for TR/ stuff then huh?
  360. # [14:43] <annevk> we don't fix /TR/ drafts
  361. # [14:43] <annevk> see the editor's draft
  362. # [14:43] <boblet> annevk: ok
  363. # [14:44] <annevk> (not even typos are fixed, though sometimes that happens and it will be annotated with "edited in place" or some such, mostly restricted to actual RECs)
  364. # [14:44] <boblet> thanks for explaining the distinction—I trusted the Googl & it let me down
  365. # [14:48] <Dashiva> It's a feature, really
  366. # [14:48] <Dashiva> At least that's what W3C says
  367. # [14:48] <boblet> I should have read the header more carefully
  368. # [14:49] <annevk> it's a bit annoying really
  369. # [14:49] <annevk> snapshots work when you do things in private
  370. # [14:50] <annevk> but when everything is in public and process happens daily, it's sort of a weird thing
  371. # [14:50] <annevk> and rather arbitrary
  372. # [14:51] <Dashiva> Especially when there are multiple drafts that need to be in sync
  373. # [14:53] * Joins: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams)
  374. # [14:53] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Client Quit)
  375. # [14:54] <jgraham> It only works for private things if you don't care about the fact that all external feedback will be out of date
  376. # [14:54] <annevk> protecting against system colors would be rather hard for the canvas case btw
  377. # [14:54] <annevk> it would either have to forbid them completely or mark the <canvas> as unsafe or some such
  378. # [14:55] * Quits: Necrathex (~bleptop@dhcp-077-249-097-016.chello.nl) (Quit: Necrathex)
  379. # [14:56] * Joins: ChrisLTD|Work (~blahness@152.2.194.196)
  380. # [14:57] <workmad3> could the canvas spec not mandate that the user is informed when system colours are accessed and can allow/deny it when it occurs?
  381. # [14:57] <jgraham> No
  382. # [14:57] <workmad3> fair enough :)
  383. # [14:57] <jgraham> (becuase in general you can't mandate UI)
  384. # [14:58] <Philip`> Dashiva: People can make perfectly authentic-looking fake chrome by screenshotting Windows
  385. # [14:58] <jgraham> But in this specific case it would also be bad because, well, who wants to be asked a question like that
  386. # [14:58] <workmad3> 'warning, this page is trying to look authentic, which may compromise your system security. Do you wish the page to look half decent? <yes>, <no>'
  387. # [14:58] <annevk> this stuff is such a mess
  388. # [14:59] <workmad3> I guess that wouldn't go down well :)
  389. # [14:59] <annevk> anyway, hopefully webkit/gecko people have something to say about it: http://www.w3.org/mid/op.u758kvnh64w2qv@annevk-t60
  390. # [15:00] <jgraham> Since this kind of attack is only statistical anyway and most people have UIs that look like the default windows UI you may as well just use the default windows UI look
  391. # [15:00] <jgraham> s/use/fake/
  392. # [15:01] <Philip`> You can check their UA string if you want to be more specific about which version of Windows they use
  393. # [15:02] <jgraham> Indeed. And if for some reason you want to invest more effort than will result in payback you can determine OS X from the UA string too
  394. # [15:02] <jgraham> and fake than when needed
  395. # [15:02] <Philip`> But colours seem like one of the less important parts of UI spoofing - modern UI doesn't even use flat colours, so you care about gradients and shapes and hover effects and fonts
  396. # [15:04] * Joins: paul_irish (~paul_iris@c-65-96-162-9.hsd1.ma.comcast.net)
  397. # [15:04] * boblet is following foolip’s Chinese proverb
  398. # [15:07] * Quits: Rik` (~Rik`@chn38-1-78-231-168-7.fbx.proxad.net) (Read error: No route to host)
  399. # [15:07] <annevk> TabAtkins, instead of #rrggbbaa we'll get .color.red .color.alpha etc. hopefully
  400. # [15:07] * Joins: Rik` (~Rik`@chn38-1-78-231-168-7.fbx.proxad.net)
  401. # [15:07] <annevk> (which can be set as well)
  402. # [15:07] <Dashiva> Hum, so the camelData supports multiple hyphens
  403. # [15:07] <annevk> camel?
  404. # [15:07] <Philip`> Like two-hump camels?
  405. # [15:07] <Dashiva> data--whatnot------doquery
  406. # [15:07] <Dashiva> data-Whatnot-----Doquery
  407. # [15:08] <TabAtkins> That'll work too. I'd still like to be able use #rrggbbaa in my stylesheets, though, rather than having to swap over to rgba() syntax and spend a few seconds converting from hex to dec.
  408. # [15:08] <Philip`> Wouldn't #rrggbbaa conflict with the current required parsing of bogus colour strings?
  409. # [15:08] <annevk> TabAtkins, i see, no real opinion on adding extra syntax
  410. # [15:09] <TabAtkins> Philip`: Possibly. Nuts to them, though.e
  411. # [15:09] <annevk> Philip`, it would fail in older browsers and work in newer
  412. # [15:09] <annevk> Philip`, which is how CSS extensions are supposed to work so that seems ok
  413. # [15:10] <TabAtkins> Interestingly, in some cases it would "fail" by parsing as a different color. Though I think it likely that it would just parse as the non-a version.
  414. # [15:10] <boblet> foolip: do you have any advice about hcard in microdata when you want to link the name? itemprop="fn" on separate wrapper?
  415. # [15:10] <TabAtkins> Though :gasp: :shock: :horror: that might require some grammar changes.
  416. # [15:10] <annevk> i don't see why changing the grammar is such a huge deal
  417. # [15:11] <TabAtkins> It's totally not. Bert's just stupid conservative. >_<
  418. # [15:11] <annevk> we should just do it when it makes sense
  419. # [15:13] <Philip`> annevk: I mean that <body bgcolor=#aabbccdd> already has a specific meaning, which presumably is relied on by some pages and can't be changed, and it would be weird if CSS specified a different meaning for the same colour syntax
  420. # [15:13] <Philip`> (Seems it's equivalent to #aabcdd)
  421. # [15:16] <annevk> it doesn't seem too weird to me given that's just legacy
  422. # [15:20] <boblet> has anyone done microformats in microdata? <meta content=""> in spec’s hcard example isn’t working for me in foolip’s interpreter…
  423. # [15:21] <TabAtkins> You have a name on it, right?
  424. # [15:22] * Joins: annodomini (~lambda@wikipedia/lambda)
  425. # [15:22] <TabAtkins> Sorry, not name. itemprop.
  426. # [15:23] <Philip`> What browser?
  427. # [15:23] <Philip`> Some move <meta> into <head> so it won't parse right
  428. # [15:24] <boblet> TabAtkins: yep <meta itemprop="type" content="work"> for hcard
  429. # [15:24] * Joins: sbublava (~stephan@77.116.2.156.wireless.dyn.drei.com)
  430. # [15:24] <boblet> Philip`: Chrome 5 Mac
  431. # [15:24] <boblet> will check dom…
  432. # [15:25] <boblet> (although hold on, this is in http://foolip.org/microdatajs/live/ so that shouldn’t matter, no?)
  433. # [15:25] <Philip`> (I assume it still uses your browser to parse the HTML)
  434. # [15:26] <boblet> Philip`: ah, you’re right
  435. # [15:26] <boblet> the doc currently has 12 <head>s O_o
  436. # [15:27] <boblet> Philip`: is there a way around that? apart from not using content=""?
  437. # [15:28] <Philip`> You could wait until everyone fixes their parsers
  438. # [15:28] <annevk> would be nice if CSS made it more clear what was syntax-level and what's part of the model
  439. # [15:28] <Philip`> otherwise you have to not use <meta>, as far as I'm aware
  440. # [15:28] <TabAtkins> You can use <span itemprop style=display:none;>content</span> for now, if you have to.
  441. # [15:29] <boblet> hrm, sucks that there’s no equivalent of uF’s value-title pattern
  442. # [15:29] <Philip`> The equivalent is <meta>, I thought
  443. # [15:29] <TabAtkins> Yup.
  444. # [15:29] <boblet> this is kind of a common need once you’re not using English
  445. # [15:30] <boblet> heh. I want to reply ‘a method that works,’ but half the uF tools can’t use value-title either
  446. # [15:30] <TabAtkins> It works in the future!
  447. # [15:30] <boblet> TabAtkins: thanks for that :P
  448. # [15:30] <TabAtkins> And a method that works now is what I just described with <span>.
  449. # [15:31] <Philip`> It works in browsers with HTML5 parsers
  450. # [15:31] <boblet> srsly thank you both for the info and the workaround
  451. # [15:31] * Quits: nattokirai (~nattokira@y226086.dynamic.ppp.asahi-net.or.jp) (Quit: nattokirai)
  452. # [15:31] <Philip`> which is, admittedly, none
  453. # [15:31] <TabAtkins> Well, 1 if you set a pref.
  454. # [15:31] <Philip`> That doesn't count :-p
  455. # [15:31] <boblet> living in the future is harder than the 1960’s made it out to be
  456. # [15:32] <Philip`> Really? Everyone here today managed it
  457. # [15:32] <TabAtkins> And we don't even get flying cars. HUUUUGE disappointment.
  458. # [15:32] * Philip` wonders if people predicting flying cars ever looked at traffic accident statistics
  459. # [15:33] <boblet> one more q, are there any other tools for microdata apart from foolip’s that you know of?
  460. # [15:33] <TabAtkins> where's the htmlwg wiki again?
  461. # [15:34] <boblet> bookmarklets, H2VX-equivalent convertors etc…
  462. # [15:34] <TabAtkins> boblet: http://philip.html5.org/demos/microdata/demo.html
  463. # [15:34] <Philip`> boblet: Would you be happy with ancient obsolete ones?
  464. # [15:34] <boblet> Philip`: I’m always happy with your stuff
  465. # [15:34] <Philip`> I never am :-)
  466. # [15:35] <boblet> heh, know the feeling
  467. # [15:35] <boblet> cool that gives me another data point. no converting tools that output a vcard file for download yet tho huh
  468. # [15:35] <TabAtkins> As far as I can tell, Microdata was invented by people named Philip.
  469. # [15:36] <Philip`> I don't think Hixie is named Philip
  470. # [15:36] <TabAtkins> Not ones that take Microdata, unless by "download" you mean "copypasta from foolip's tool".
  471. # [15:36] <TabAtkins> Philip`: Shows what you know. Philip is his middle name!
  472. # [15:36] <TabAtkins> Hixie Philip Hickson.
  473. # [15:36] <Philip`> I never knew that :-o
  474. # [15:36] <Dashiva> Hixie Hickson
  475. # [15:38] <boblet> lol
  476. # [15:38] <boblet> well, if someone whips one up in the next 2 days let me know :)
  477. # [15:39] <Philip`> You could always whip up one yourself :-)
  478. # [15:40] <TabAtkins> Go find one of the Microformat ones and mod it.
  479. # [15:40] <Philip`> Microdata should be simple enough that that wouldn't be much work
  480. # [15:40] <boblet> unfortunately I’m working on whipping up a preso on uF & microdata in HTML5
  481. # [15:40] <boblet> in Japanese :|
  482. # [15:41] <Philip`> If it's for a presentation then you could just fake it
  483. # [15:41] <Philip`> Nobody would know
  484. # [15:41] <boblet> with a download tool they might ;-)
  485. # [15:42] <Dashiva> What do you call microformats in Japanese?
  486. # [15:42] <annevk> because without a model it's unclear e.g. whether an <identifier> is internally represented as <string> and can be serialized as such...
  487. # [15:42] <boblet> Dashiva: Maikurofo-matto (マイクロフォーマット)
  488. # [15:43] * Joins: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl)
  489. # [15:43] <boblet> but often just written as Microformat (that previous one was pronunciation & katakana)
  490. # [15:43] <Philip`> How many specs do have decent models, separating the semantics and syntax?
  491. # [15:44] <boblet> thanks for your help, all. nn
  492. # [15:45] <TabAtkins> annevk: What else would an identifier be serialized as? JS doesn't have a concept of 'symbol'.
  493. # [15:45] * Philip` wonders how long it'll be until Japanese has adopted enough words that it'll effectively be English in an unusual accent
  494. # [15:45] <TabAtkins> So, hey, htmlwg wiki. The esw thing. Where is it?
  495. # [15:45] <TabAtkins> Philip`: Has?
  496. # [15:45] <Philip`> TabAtkins: http://www.w3.org/html/wg/wiki/Main_Page
  497. # [15:45] <Dashiva> It isn't esw anymore, luckily
  498. # [15:46] <Philip`> TabAtkins: (See http://www.w3.org/html/wg/, click on "Wiki")
  499. # [15:46] <TabAtkins> That would explain why i wasn't finding it.
  500. # [15:47] * Joins: aroben (~aroben@unaffiliated/aroben)
  501. # [15:50] * Quits: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  502. # [15:54] <Philip`> TabAtkins: Maybe the question is whether the strings "test" and "te\st" and "TEST" all have the same internal representation (because they are specified to be "exactly the same identifier") and thus the same serialisation (in which case which one?)
  503. # [15:54] <TabAtkins> Those are valid questions, and should indeed be specified precisely.
  504. # [15:54] <annevk> TabAtkins, strings are serialized with quotes
  505. # [15:55] * Philip` guesses there's also questions like whether the string "\7B" should be serialized as "\7B" or as "{"
  506. # [15:55] <annevk> Philip`, for identifiers, yes
  507. # [15:55] <TabAtkins> annevk: ah, gotcha. I read you as saying something subtly different.
  508. # [15:55] * gsnedders wonders if the fact that HTML 5 disallows all Unicode code characters causes issues by disallowing General_Category Cf
  509. # [15:55] <Dashiva> Reminds me of that horrible feature of JSON...
  510. # [15:55] <annevk> so e.g. [attr=ident] turns into [attr="ident"] in most browsers
  511. # [15:55] <annevk> but there's no Selectors model that defines that
  512. # [15:56] <Philip`> Dashiva: Which of the horrible features?
  513. # [15:56] <Dashiva> The one that lets you use both \/ and /
  514. # [15:56] <gsnedders> How will I live without U+1D177 MUSICAL SYMBOL BEGIN SLUR?
  515. # [15:56] <gsnedders> Or more seriously, what about something like U+0600 ARABIC NUMBER SIGN?
  516. # [15:57] <Philip`> Dashiva: Why is that any worse than the feature that you can use both "\u0078" and "x"?
  517. # [15:57] <Dashiva> Because some python libs only supported one of them
  518. # [15:57] <Dashiva> And I had to work around it
  519. # [15:58] <annevk> identifiers are especially complicated, because they cannot start with numbers either unless prefixed with -, etc.
  520. # [15:58] <Philip`> Is it JSON's fault that implementations are buggy?
  521. # [15:58] * Joins: jgornick (~joe@199.199.210.66)
  522. # [15:58] <Dashiva> Yes
  523. # [15:58] * Quits: myakura (~myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp) (Ping timeout: 256 seconds)
  524. # [16:00] * Joins: myakura (~myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp)
  525. # [16:01] <Philip`> Is it not just the fault of implementors who can't read a trivial grammar spec?
  526. # [16:03] * jgraham notes that in javascript, escaped identifiers are not equivalent to unescaped ones despite what the spec says
  527. # [16:03] <jgraham> (in particular you can use reserved words in identifiers by cunning/evil use of escapes even though that is forbidden)
  528. # [16:04] <Philip`> You can escape identifiers in JS?
  529. # [16:04] * Philip` somehow failed to notice that
  530. # [16:09] <gsnedders> Philip`: Well of course, it's a brilliant feature
  531. # [16:10] <TabAtkins> What is an undercount?
  532. # [16:10] <Philip`> A count that is too small?
  533. # [16:10] <TabAtkins> Google is not helping me.
  534. # [16:10] <TabAtkins> Nah, it has something to do with polling, but everything I'm finding is talking about undercounts like I already understand what they are.
  535. # [16:11] <Philip`> "To record fewer than the actual number of (persons in a census, for example)." ?
  536. # [16:11] <Philip`> like if you lose/ignore half the votes, or something
  537. # [16:11] <TabAtkins> That makes sense. It makes what I'm reading sort of nonsensical, but shrug. That's to be expected given the author.
  538. # [16:13] <meledin> It could be a misrepresentation
  539. # [16:13] <meledin> e.g. say "video games have a 10% market share (when polling adult females aged 60 and up)"
  540. # [16:15] <annevk> TabAtkins, e.g. with counter-reset or so you want to know the model
  541. # [16:16] <TabAtkins> annevk: Indeed, it's very important to know whether an escaped counter identifier is the same as the unescaped. Complete agreement there.
  542. # [16:18] * Philip` blames XML for being too successful and encouraging people to believe it's good to specify just syntax and not the interpretation of the syntax
  543. # [16:20] <annevk> TabAtkins, oh, that is pretty clear
  544. # [16:21] <TabAtkins> Oh, ok. Man, I don't even know then. ^_^ I don't have enough impl experience yet.
  545. # [16:21] <annevk> TabAtkins, though maybe not, is <string> "test" the same as <identifier> test, and what do they serialize as?
  546. # [16:21] <annevk> it's mostly what happens in serialization that I was worried about
  547. # [16:21] <annevk> e.g. is it all <string> internally or not
  548. # [16:22] <TabAtkins> I'd have to go read the spec, since it treats strings and identifiers inconsistently. >_<
  549. # [16:22] <annevk> it seems most impl just do whatever
  550. # [16:22] * Quits: mat_t (~mattomasz@ppp-3-229.leed-b-2.access.uk.tiscali.com) (Quit: This computer has gone to sleep)
  551. # [16:22] <TabAtkins> Javascript needs a symbol type. Like a string but you can just do pointer comparisons to check equality.
  552. # [16:22] <annevk> CSS just falls apart as spec when you look at API stuff
  553. # [16:22] <Philip`> Sounds like most specs
  554. # [16:22] <annevk> TabAtkins, hmm, impl could do that internally
  555. # [16:23] <gsnedders> TabAtkins: I wonder how much perf you'd gain from that though
  556. # [16:23] * Joins: mat_t (~mattomasz@ppp-3-229.leed-b-2.access.uk.tiscali.com)
  557. # [16:23] * Quits: beilabs (~beilabs@ppp121-44-122-3.lns20.syd6.internode.on.net) (Remote host closed the connection)
  558. # [16:23] <TabAtkins> I think they *do*. At least, that the impression I get from some things I've heard dbaron saying.
  559. # [16:23] * gsnedders thinks that will almost certainly be the wrong place to optimize
  560. # [16:23] <annevk> Philip`, yeah, HTML4/DOM2HTML had the same issue
  561. # [16:23] <TabAtkins> gsnedders: In a tight loop, string comparison is expensive. >_<
  562. # [16:24] <Philip`> You don't need a special symbol type, you just need interned strings
  563. # [16:24] * Joins: harig (~harig@202.164.55.82)
  564. # [16:24] <jgraham> Don't you hate it when you are about to say something and then Philip` speaks
  565. # [16:24] <TabAtkins> True, but it's nice to reflect that in a user-visible way. A symbol *is* an interned string.
  566. # [16:24] <jgraham> because he always says whatever you were about to say
  567. # [16:24] <Philip`> jgraham: I sure do
  568. # [16:24] <Philip`> (Hate it, I mean)
  569. # [16:25] <TabAtkins> At least, for the one language I have experience with that has a symbol type (lisp). (intern "foo") returns the symbol foo.
  570. # [16:25] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
  571. # [16:25] * Quits: Utkarsh (~admin@117.201.90.49) (Ping timeout: 240 seconds)
  572. # [16:25] <gsnedders> Ruby has a symbol type too
  573. # [16:27] <Philip`> C++ has boost::flyweight<std::wstring>, which seems to be the same idea
  574. # [16:27] <Philip`> Not the snappiest name, though
  575. # [16:28] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 246 seconds)
  576. # [16:31] * Joins: Utkarsh (~admin@117.201.82.136)
  577. # [16:35] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  578. # [16:35] <annevk> I thought I was before Philip`, though I guess I didn't mention interned strings explicitly
  579. # [16:38] <jgraham> Yeah but Philip` always does it :)
  580. # [16:39] <annevk> interesting definition of always then :p
  581. # [16:42] * Philip` is clearly too predictable
  582. # [16:42] <jgraham> I reserve the right to be interesting
  583. # [16:50] <TabAtkins> Yay for people assembling all the information I needed for my counter proposal for me!
  584. # [16:51] <Lachy> TabAtkins, what counter proposal are you writing?
  585. # [16:51] <TabAtkins> For issues 1 and 2. Just posted it to the list.
  586. # [16:58] * Quits: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de) (Remote host closed the connection)
  587. # [16:58] <hsivonen> Philip`: boost calls interned stuff "flyweight"?
  588. # [16:58] <hsivonen> as in weighing as much as an insect?
  589. # [16:58] <annevk> we could just use a PING method instead
  590. # [16:59] <annevk> custom methods are quite well supported nowadays
  591. # [16:59] * Quits: harig (~harig@202.164.55.82) (Ping timeout: 245 seconds)
  592. # [17:00] <Philip`> hsivonen: http://en.wikipedia.org/wiki/Flyweight_pattern
  593. # [17:01] <Philip`> as in weighing between 49kg and 51kg :-)
  594. # [17:02] <hsivonen> Philip`: clearly, I haven't read enough Design Patterns literature to know the lingo
  595. # [17:07] <TabAtkins> annevk: Are they?
  596. # [17:07] * TabAtkins has no idea if php supports new methods well.
  597. # [17:07] <gsnedders> TabAtkins: It treats all methods identically
  598. # [17:07] <Philip`> Do proxies support them?
  599. # [17:07] <TabAtkins> That wouldn't actually resolve the objection, though. The PING method would still be 'unsafe'.
  600. # [17:08] <gsnedders> TabAtkins: It just sets $_SERVER['HTTP_METHOD'] or some other key to the method of the request
  601. # [17:08] <TabAtkins> gsnedders: Thanks for the info!
  602. # [17:08] <Philip`> Hmm, I think Squid doesn't by default, which is why it breaks Subversion
  603. # [17:08] <annevk> TabAtkins, not necessarily
  604. # [17:08] <annevk> TabAtkins, new methods can be safe
  605. # [17:08] <Lachy> the only really relevant question reagarding ping is whether or not browsers will implement it, and if they do, then it should be specced. (Of course, browsers should choose whether or not to implement the feature on its own merits, none of which should affect whether or not it should be specced)
  606. # [17:09] <TabAtkins> annevk: I think they're using "unsafe" to mean "not idempotent", and @ping is inherently not idempotent.
  607. # [17:10] <annevk> TabAtkins, I don't think that's quite true
  608. # [17:10] <TabAtkins> Elaborate?
  609. # [17:11] <annevk> by not holding the user accountable it is acceptable afaict
  610. # [17:12] <annevk> though using GET would be just as fine in that case, though presumably does not work well with caching and all
  611. # [17:13] <Philip`> Can't you just set some request header to make sure it doesn't get cached?
  612. # [17:18] <jgraham> It seems like bad design to require special overrides to ensure the request is not cached when caching is never the right thing to do
  613. # [17:18] * Quits: seventh (seventh@189.59.206.63) (Remote host closed the connection)
  614. # [17:19] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
  615. # [17:21] * Joins: zcorpan__ (~zcorpan@static-88.131.66.111.addr.tdcsong.se)
  616. # [17:21] <Philip`> It seems like bad design to rely on certain side-effects of the request method, rather than on the explicit cache control headers, when the primary aim is to affect the request's cache behaviour
  617. # [17:22] * Quits: Peter- (~peter@92.254.21.251) (Read error: Connection reset by peer)
  618. # [17:24] * Joins: Peter- (~peter@92.254.21.251)
  619. # [17:24] <hsivonen> is there some echo service that I POST a form to and get it echoed to me?
  620. # [17:25] <jgraham> Philip`: Well with my approach ("right by default") people will typically get it right whereas with the "be explicit but fail wrong" approach people will typically get it wrong
  621. # [17:28] <Philip`> jgraham: "people" here are web browser developers and they can be expected to largely get it right
  622. # [17:29] <Philip`> and it's easy to test
  623. # [17:30] <Philip`> (If it was something authors would have to do, then I'd find it more compelling to make it harder to make mistakes)
  624. # [17:34] <annevk> hsivonen, hixie has that
  625. # [17:34] <hsivonen> annevk: where?
  626. # [17:34] <annevk> not sure, looking it up
  627. # [17:34] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: mhausenblas)
  628. # [17:35] <annevk> his site is somewhat slow
  629. # [17:36] <annevk> hsivonen, http://software.hixie.ch/utilities/cgi/test-tools/echo
  630. # [17:36] <hsivonen> annevk: thanks
  631. # [17:38] <annevk> for whoever is in the CSS-<number>-values-need-to-support-a-significand camp it would make writing down how to serialize a <number> value easier
  632. # [17:38] <TabAtkins> There's a thread for that, annevk.
  633. # [17:39] <annevk> I deleted that thread
  634. # [17:40] <TabAtkins> Hehe. Why not just mute it?
  635. # [17:40] * TabAtkins deletes NOTHING.
  636. # [17:40] <hsivonen> I can has bogo-keygen
  637. # [17:41] <hsivonen> one item less on my todolist
  638. # [17:41] <annevk> TabAtkins, cause I delete
  639. # [17:42] <TabAtkins> Fine. Could you explain your reasoning more fully? I'll send it to the list.
  640. # [17:42] <annevk> HTML5 uses ToString() for real numbers, from ECMA
  641. # [17:42] <annevk> it seems some browsers already use that too
  642. # [17:43] <annevk> using that for serializing CSS <number> values too would unify things a little more
  643. # [17:43] * Quits: peslafk (~retep@procurios.xs4all.nl) (Quit: ( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com ))
  644. # [17:43] <TabAtkins> kk
  645. # [17:43] <TabAtkins> So we'd be harmonizing with HTML5 as well as SVG.
  646. # [17:45] <Philip`> HTML5 seems to bounce between different serialisation/parsing definitions quite frequently
  647. # [17:45] <Philip`> Strangely it seems to happen whenever I complain about the previous definition
  648. # [17:45] <Philip`> (even if that's a definition I suggested)
  649. # [17:47] * Joins: seventh (seventh@189.59.206.63)
  650. # [17:49] * svl is now known as svl__
  651. # [17:51] <Philip`> "Ping would never be capable of proving undercounts" - s/proving/preventing/ ?
  652. # [17:51] <Philip`> The sentence seems to make more sense with that change
  653. # [17:53] <smaug> Hixie: why does the websocket protocol have the optional binary-frames?
  654. # [17:53] * Quits: myakura (~myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving...)
  655. # [17:54] <smaug> or why are they optional?
  656. # [17:55] <annevk> they're not optional
  657. # [17:55] * Quits: seventh (seventh@189.59.206.63) (Remote host closed the connection)
  658. # [17:56] <TabAtkins> Philip`: I think it's meant to be "providing"?
  659. # [17:57] <Philip`> I don't think that would make sense
  660. # [17:57] <jgraham> Do you mean "lower bounds"?
  661. # [17:57] <Philip`> I think the meaning was that ping would never provide a perfectly accurate count that never misses any clicks
  662. # [17:58] <Philip`> (because it's be easy for the ping server to be down, etc)
  663. # [17:58] <Philip`> I'm not at all confident in my thinking, though
  664. # [17:59] <TabAtkins> I suppose that makes sense too. Honestly, that objection is incoherent anyway, because there is no perfectly accurate auditing method.
  665. # [18:00] <Philip`> Even with no perfect method, if current methods had 99% accuracy and a new method had 50% accuracy then nobody would use the new method
  666. # [18:01] <Philip`> so I don't think the impossibility of perfection means there's no need to debate accuracy
  667. # [18:02] <jgraham> They might if the loss in accuracy had some positive side effect
  668. # [18:02] <jgraham> (so there is equally no use ssaying that accuracy alone is the only significant variable)
  669. # [18:03] <Philip`> Well, no
  670. # [18:03] <Philip`> Maybe the new method has 50% accuracy but it kills a puppy every time someone clicks on the link, and you hate puppies
  671. # [18:03] <Philip`> so I'd agree it's not the only factor
  672. # [18:03] <Philip`> but it is a valid factor to discuss
  673. # [18:04] <Philip`> (but preferably it should be discussed with data and specific cases, rather than handwavey claims that it won't be accurate enough)
  674. # [18:08] <TabAtkins> Philip`: True. However, I'd be willing to argue that @ping will be no less accurate than existing similar methods.
  675. # [18:12] <annevk> oh sweet, the grammar uses octal references
  676. # [18:12] <annevk> gotta love that
  677. # [18:12] * Joins: ap_ (~ap@17.246.19.5)
  678. # [18:13] <TabAtkins> omg
  679. # [18:13] <TabAtkins> wtf are we using octal. wtf is *anyone* using octal?
  680. # [18:13] <annevk> I seriously dislike the CSS grammar
  681. # [18:14] <TabAtkins> What feature, in the history of computers, has ever gained more benefit from using octal than it suffered from confusion caused by it?
  682. # [18:14] <annevk> fortunately CSS itself uses unicode escapes
  683. # [18:15] <Philip`> TabAtkins: Unix file permissions?
  684. # [18:15] <TabAtkins> Are those octal? I always figured they were just chars.
  685. # [18:16] <Philip`> "0755" etc
  686. # [18:16] <TabAtkins> Yeah, I just never really thought of that as a number.
  687. # [18:16] <TabAtkins> More like 0,7,7,5.
  688. # [18:16] <TabAtkins> Four separate flags.
  689. # [18:18] <Philip`> You need three bits for each number (rwx), so octal makes sense
  690. # [18:18] <Philip`> It'd be awfully wasteful to devote 8 bits when you only need 3
  691. # [18:19] <TabAtkins> Shrug.
  692. # [18:19] <Philip`> and it'd be a pain for a program to process character strings
  693. # [18:19] <Philip`> compared to just &ing with a mask to extract the desired permission bits
  694. # [18:20] * Joins: harig (HariG@59.161.73.248)
  695. # [18:20] <TabAtkins> I have no idea how the permission bits are actually exposed.
  696. # [18:20] * Joins: maikmerten (~maikmerte@port-92-201-46-58.dynamic.qsc.de)
  697. # [18:21] * Joins: gunderwonder_ (~gunderwon@garage.upstruct.com)
  698. # [18:21] <Philip`> With C code like mkdir("foo", 0755);
  699. # [18:22] <annodomini> Interesting comment re the W3C HTML standards process: http://news.ycombinator.com/item?id=1126640
  700. # [18:23] <TabAtkins> I suppose C treats numbers starting with 0 as octal there?
  701. # [18:23] * Quits: gunderwonder (~gunderwon@garage.upstruct.com) (Ping timeout: 240 seconds)
  702. # [18:23] <TabAtkins> annodomini: Urm, wow.
  703. # [18:24] <annodomini> Yeah, the resemblance is scary, isn't it?
  704. # [18:24] <Philip`> TabAtkins: Yes
  705. # [18:24] <Philip`> It treats numbers starting with 0 as octal everywhere, in fact :-p
  706. # [18:25] <TabAtkins> Well, yeah. Bad use of "there" there. ^_^
  707. # [18:25] <Philip`> annodomini: Already incorporated into http://ian.hixie.ch/bible/handling-people :-)
  708. # [18:26] * Quits: gunderwonder_ (~gunderwon@garage.upstruct.com) (Ping timeout: 276 seconds)
  709. # [18:26] <hsivonen> annodomini: the awesome part is that people imply Hixie practices that because Hixie has a copy of that text on his site
  710. # [18:26] <hsivonen> annodomini: see http://ian.hixie.ch/bible/handling-people
  711. # [18:27] <annodomini> Philip`: Ah, I hadn't seen that.
  712. # [18:27] <annodomini> hsivonen: Heh.
  713. # [18:28] <hsivonen> annodomini: it's an interesting exercise to try to see who appears to be practicing those points in which W3C WGs
  714. # [18:29] <Philip`> You should watch out for people sneaking about the W3C server room and dropping iron filings into the machines, too
  715. # [18:29] <Philip`> (That sabotage manual has lots of great ideas)
  716. # [18:30] * Quits: zcorpan__ (~zcorpan@static-88.131.66.111.addr.tdcsong.se) (Ping timeout: 240 seconds)
  717. # [18:30] <annodomini> It's definitely a good rebuttal to the people who claim that they are not trying to sabotage HTML5 (or fill in any other standard) but instead are just trying to improve the process.
  718. # [18:33] * Joins: harig_ (harig@59.161.73.248)
  719. # [18:34] * Joins: zcorpan__ (~zcorpan@static-88.131.66.111.addr.tdcsong.se)
  720. # [18:36] <hsivonen> http://news.ycombinator.com/item?id=1126555
  721. # [18:37] * Quits: harig (HariG@59.161.73.248) (Ping timeout: 245 seconds)
  722. # [18:48] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115132715])
  723. # [18:53] * Joins: gunderwonder (~gunderwon@191.80-202-79.nextgentel.com)
  724. # [19:09] <workmad3> hah :) I was reading the handling people thing and was thinking "I'm sure something like this was in Yes Minister"... and then saw the reference at the bottom :)
  725. # [19:10] * Quits: Utkarsh (~admin@117.201.82.136) (Ping timeout: 265 seconds)
  726. # [19:14] * Joins: Utkarsh (~admin@117.201.80.16)
  727. # [19:20] * Quits: mat_t (~mattomasz@ppp-3-229.leed-b-2.access.uk.tiscali.com) (Remote host closed the connection)
  728. # [19:22] * Quits: sbublava (~stephan@77.116.2.156.wireless.dyn.drei.com) (Quit: sbublava)
  729. # [19:28] * Joins: pixelflips_ (~chatzilla@p54BEFF60.dip.t-dialin.net)
  730. # [19:28] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  731. # [19:30] * Parts: pixelflips_ (~chatzilla@p54BEFF60.dip.t-dialin.net)
  732. # [19:32] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Client Quit)
  733. # [19:34] * Quits: Lachy (~Lachlan@pat.se.opera.com) (Quit: This computer has gone to sleep)
  734. # [19:36] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 256 seconds)
  735. # [19:36] * harig_ is now known as harig
  736. # [19:36] * Joins: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
  737. # [19:36] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  738. # [19:39] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  739. # [19:41] * Quits: harig (harig@59.161.73.248)
  740. # [19:41] * Quits: zcorpan__ (~zcorpan@static-88.131.66.111.addr.tdcsong.se) (Quit: zcorpan__)
  741. # [19:41] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  742. # [19:45] * Joins: Lachy (~Lachlan@southampton.perfect-privacy.com)
  743. # [19:46] * Quits: ChrisLTD|Work (~blahness@152.2.194.196) (Quit: ChrisLTD|Work)
  744. # [19:58] * Joins: virtuelv (~virtuelv_@162.179.251.212.customer.cdi.no)
  745. # [20:00] * Joins: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at)
  746. # [20:00] * aroben is now known as aroben|away
  747. # [20:04] * Joins: zcorpan__ (~zcorpan@91-103-36-68.dynamic.thecloud.net)
  748. # [20:05] * Joins: MikeSmithXX (~MikeSmith@EM114-48-137-0.pool.e-mobile.ne.jp)
  749. # [20:09] * Quits: MikeSmithX (~MikeSmith@EM114-49-29-244.pool.e-mobile.ne.jp) (Ping timeout: 272 seconds)
  750. # [20:28] * Quits: drry (~drry@unaffiliated/drry) (Quit: Tiarra 0.1+svn-36552M: SIGTERM received; exit)
  751. # [20:28] * Joins: cristianl (~cristianl@201-14-217-21.paemt704.dsl.brasiltelecom.net.br)
  752. # [20:30] <Hixie> MikeSmithXX: yt?
  753. # [20:33] * Quits: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) (Remote host closed the connection)
  754. # [20:35] * Joins: nessy (~Adium@124-168-170-167.dyn.iinet.net.au)
  755. # [20:38] * Parts: cristianl (~cristianl@201-14-217-21.paemt704.dsl.brasiltelecom.net.br)
  756. # [20:40] * Joins: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
  757. # [20:42] <smaug> Hixie:now that you're here, why does the websocket protocol have the optional binary-frames?
  758. # [20:42] <smaug> or what to call them, semi-optional
  759. # [20:43] <Hixie> so that we can add support for binary in the future
  760. # [20:43] <Hixie> they're not optional, they're invalid at the moment
  761. # [20:43] <Hixie> the support is just error handling
  762. # [20:43] <Hixie> and you can handle them by either ignoring them or failing the connection
  763. # [20:44] <Hixie> (only ignoring them if you're a browser client)
  764. # [20:44] <smaug> well, might be better to define that they are really invalid now
  765. # [20:45] <Hixie> i thought it did
  766. # [20:45] <Hixie> where does it say they are alid?
  767. # [20:45] <Hixie> valid
  768. # [20:45] <Hixie> neither the server nor the client is allowed to send them
  769. # [20:45] <Hixie> they're only allowed to send 0x00 frames currently
  770. # [20:45] * Quits: surkov (~surkov@client-67-135.sibtele.com) (Quit: surkov)
  771. # [20:46] <smaug> well, the server side part says that "If /type/ is not a 0x00 byte, then the server may disconnect from
  772. # [20:46] <smaug> the client."
  773. # [20:46] <Hixie> right
  774. # [20:46] <smaug> it is just "may"
  775. # [20:46] <Hixie> indeed
  776. # [20:46] <Hixie> that's the right thing to do as far as i can tell
  777. # [20:47] <Hixie> the server knows the subprotocol that the conneciton is using
  778. # [20:47] <Hixie> so it can know that if it sees a binary frame it can disconnect since it's not valid
  779. # [20:47] <Hixie> and it can equally know that it might want to use binary frames in the future and will therefore know that it can try to be future-compatible and not disconnect, but just ignore the packet
  780. # [20:48] <Hixie> s/packet/frame/
  781. # [20:48] <smaug> server may not really know the subprotocol. I'd assume the subprotocol was implemented by some cgi-like script
  782. # [20:49] <Hixie> that's still the server
  783. # [20:50] <smaug> and anyway, the client can't handle binary data at all
  784. # [20:50] <Hixie> today, right
  785. # [20:50] <Hixie> but in the future we'll add binary frames
  786. # [20:50] <smaug> yeah
  787. # [20:50] <smaug> so why define some sort of server side support for binary, but not client side
  788. # [20:51] <Hixie> the clients ignore binary frames just like the server does
  789. # [20:51] <smaug> not the same way
  790. # [20:51] <smaug> client does always "Discard the read bytes."
  791. # [20:51] <Hixie> well the clients aren't allowed to disconnect, sure
  792. # [20:51] <smaug> server just may close the connection
  793. # [20:51] <Hixie> right
  794. # [20:52] <Hixie> the server knows the protocol, the client doesn't (it's running JS that does the protocol)
  795. # [20:52] <Hixie> so the server can know if it's expecting binary frames or not
  796. # [20:52] <Hixie> the clients on the other hand have to all interoperate exactly
  797. # [20:52] <zcorpan__> Hixie: doesn't object send a PARAM:null parameter to plugins (commented out in the spec)?
  798. # [20:52] <Hixie> zcorpan__: only firefox seems to do that
  799. # [20:52] <zcorpan__> Hixie: hmm i thought opera also does
  800. # [20:53] <Hixie> nope
  801. # [20:53] <smaug> currently websockets api is text based
  802. # [20:53] <Hixie> smaug: yes
  803. # [20:53] <Hixie> no binary support in JS :-(
  804. # [20:53] <smaug> could the protocol say something that if the API to handle protocol supports binary, then the data shouldn't be discarded
  805. # [20:54] <Hixie> once the API handles binary, I'll update the protocol.
  806. # [20:54] <Hixie> (they're the same source document, I edit them as one spec)
  807. # [20:54] <Hixie> (they're both part of http://www.whatwg.org/specs/web-apps/current-work/complete.html)
  808. # [20:54] <smaug> why can't you write the protocol so that it supports that already?
  809. # [20:54] <Hixie> no point, the API doesn't do it
  810. # [20:55] <Hixie> what would you do with the data?
  811. # [20:55] <Hixie> the client can neither send nor receive binary
  812. # [20:55] <zcorpan__> you could implement a server now that will work in the future when clients support binary
  813. # [20:55] <smaug> currently it can receive binary
  814. # [20:55] * Quits: Lachy (~Lachlan@southampton.perfect-privacy.com) (Quit: This computer has gone to sleep)
  815. # [20:55] <smaug> it just discards the data immediately
  816. # [20:56] <Hixie> right
  817. # [20:56] <smaug> in the future the protocol will need backwards incompatible change
  818. # [20:56] <Hixie> zcorpan__: that'd be unwise, since we don't know exactly what the conventions will be
  819. # [20:57] <smaug> client may not discard the data anymore
  820. # [20:57] <Hixie> how is that not backwards compatible?
  821. # [20:58] <smaug> for some reason server could send some random data to client to keep the connection open or something....
  822. # [20:58] <smaug> and rely on that client doesn't handle that
  823. # [20:58] <smaug> but suddenly client starts to handle the data
  824. # [20:58] <Hixie> that would work fine, since the JS would also ignore the binary frames
  825. # [20:59] <smaug> I assume JS can handle binary frames in the future
  826. # [20:59] <Hixie> yes, but the script the author wrote isn't going to suddenly support it without the server being fixed to not send those frames
  827. # [21:01] <smaug> right
  828. # [21:01] <smaug> so why not say now that client may use the binary frames
  829. # [21:01] <Hixie> JS doesn't support binary
  830. # [21:02] <Hixie> so what are we supposed to do with the binary frames?
  831. # [21:02] <smaug> I assume there can be other than WebSockets API which use the protocol
  832. # [21:02] <Hixie> oh, no, that would be silly
  833. # [21:02] <Hixie> if you're not a browser just use TCP
  834. # [21:02] <smaug> huh
  835. # [21:03] <Hixie> the only things WebSockets gives you are an origin-based security model (only helpful for browsers) and basic framing
  836. # [21:03] <Hixie> basic framing is so trivial to do that you can do it in your own protocol, you don't need websockets
  837. # [21:03] <smaug> if you have some service which already uses websockets, why not use the same protocol everywhere?
  838. # [21:03] <Hixie> well i guess you could, but then you have to worry about JS clients again
  839. # [21:04] <Hixie> my point is you'd only ever use websockets if at least one of your clients is going to be a browser
  840. # [21:04] <Hixie> and if that's the case, then you can't use binary frames
  841. # [21:04] <Hixie> until we add binary to the protocol
  842. # [21:04] <Hixie> er, to JS I mean
  843. # [21:05] <smaug> right
  844. # [21:06] <smaug> but since the binary frames are defined already, server-to-server (or server-to-C++) communication could start use binary-frames already
  845. # [21:06] <Hixie> personally i'd strongly recommend that if your client isn't a browser, you just use a custom protocol
  846. # [21:06] <smaug> and once the JS API is ready, it can just start use the same (binary) subprotocol
  847. # [21:06] <Hixie> it might look very similar to websockets, but it needn't be websockets itself
  848. # [21:06] <Hixie> for example the whole handshake is a waste of time if you're not a browser
  849. # [21:07] <Hixie> and if you're not using websockets, you can write your own spec that uses whatever frames you want
  850. # [21:07] <smaug> yet you mention in the draft that not all communication is server-to-browser
  851. # [21:07] * Quits: paul_irish (~paul_iris@c-65-96-162-9.hsd1.ma.comcast.net) (Remote host closed the connection)
  852. # [21:07] <Hixie> yeah, people keep telling me to make the spec more generic
  853. # [21:07] <Hixie> i think it's a mistake
  854. # [21:07] * Quits: maikmerten (~maikmerte@port-92-201-46-58.dynamic.qsc.de) (Remote host closed the connection)
  855. # [21:09] <smaug> I still don't see why the draft couldn't say that if the API supports binary, then client may not discard the data
  856. # [21:09] <smaug> not a big change
  857. # [21:10] <smaug> but would allow server-to-C++ etc
  858. # [21:10] <Hixie> same reason it doesn't say you can use frame 0x01
  859. # [21:10] <Hixie> we don't know what the conventions will be yet
  860. # [21:10] <Hixie> maybe binary frames will be [mimetype][data]
  861. # [21:10] <Hixie> or maybe they'll be [data][checksum][data][checksum] etc
  862. # [21:11] <Hixie> and there's no need for it -- if you want to speak a custom protocol to a server, you don't need this spec
  863. # [21:11] <Hixie> just write your own
  864. # [21:12] * Joins: pmuellr_ (~pmuellr@nat/ibm/x-rxdtgdbgsawbiaxp)
  865. # [21:12] * Quits: pmuellr (~pmuellr@nat/ibm/x-xtldyezopdpdkslb) (Read error: Connection reset by peer)
  866. # [21:12] * pmuellr_ is now known as pmuellr
  867. # [21:12] <TabAtkins> What. The. Hell. Something is going *terribly* wrong here. Either the server or the browser is cutting off my post request after a minute or two and just navigating to the form's @action instead.
  868. # [21:14] <Hixie> tcpdump
  869. # [21:14] <Hixie> find out what's actually going on :-)
  870. # [21:14] * Joins: beowulf (wiglaf@ps4552.dreamhost.com)
  871. # [21:14] * Quits: zcorpan__ (~zcorpan@91-103-36-68.dynamic.thecloud.net) (Remote host closed the connection)
  872. # [21:15] * Joins: zcorpan__ (~zcorpan@91-103-36-68.dynamic.thecloud.net)
  873. # [21:16] * Quits: pmuellr (~pmuellr@nat/ibm/x-rxdtgdbgsawbiaxp) (Client Quit)
  874. # [21:17] <smaug> the protocol does say what part of the frame is binary
  875. # [21:17] <smaug> so why the client couldn't use that?
  876. # [21:17] <Hixie> no, it says how to skip length-prefixed frames
  877. # [21:17] <Hixie> it doesn't say what 0x80-0xFF frames actually mean
  878. # [21:17] <Hixie> in fact, case in point, we're thinking of defining 0xFE and 0xFF to be a disconnect handshake
  879. # [21:19] <smaug> would server send those?
  880. # [21:19] <Hixie> we don't know yet
  881. # [21:19] <smaug> ...since currently client must just discard the binary data
  882. # [21:20] <Hixie> if we make 0xFF do something, then we'd change the client and server rules accordingly
  883. # [21:20] <Hixie> that's my point
  884. # [21:20] <Hixie> as we make frames do new things, we'll update the spec
  885. # [21:20] <Hixie> you know, the spec also says to discard 0x01 frames
  886. # [21:20] <Hixie> which aren't binary
  887. # [21:20] <Hixie> it's not just binary frames it discards
  888. # [21:21] <Hixie> it discards 99.6% of possible frame types
  889. # [21:21] <Hixie> only 0x00 frames get processed currently without discarding
  890. # [21:22] * Quits: zalan (~zalan@catv-89-135-108-81.catv.broadband.hu) (Ping timeout: 246 seconds)
  891. # [21:23] <smaug> rigth
  892. # [21:23] <smaug> I just wish the wording would be something else than "discard data"
  893. # [21:23] * Joins: cpearce (~cpearce@203-97-204-82.dsl.clear.net.nz)
  894. # [21:23] <Hixie> "this frame is invalid, discard the data"?
  895. # [21:24] <Hixie> "if you ever see this, you're either speaking to a buggy peer or a peer from the future"
  896. # [21:24] <smaug> since the idea is anyway that in the future the data may be used for something
  897. # [21:24] <Hixie> in the future we'll update the spec
  898. # [21:24] <TabAtkins> Hmm. I have no idea how to tell tcpdump how to only report on traffic from the webserver.
  899. # [21:25] <Hixie> are you running it on the client or the server?
  900. # [21:25] <TabAtkins> server.
  901. # [21:26] <smaug> so a server based on Feb 15 2010 draft can rely on that everything else than 0x00 frames are discarded, because the spec says so
  902. # [21:26] * TabAtkins basically doesn't know what he's doing.
  903. # [21:26] <Hixie> tcpdump ... 'src post 80'
  904. # [21:26] <Hixie> er
  905. # [21:26] <Hixie> src port 80
  906. # [21:26] <Hixie> smaug: a server based on feb 15 2010 draft can't send anything but 0x00 frames, because the spec says so
  907. # [21:27] <Hixie> TabAtkins: actually
  908. # [21:27] <smaug> ah, that is ture
  909. # [21:27] <smaug> true
  910. # [21:28] <smaug> yet, the spec should say something (even in normative section) about reserving frame types for future use
  911. # [21:28] * aroben|away is now known as aroben
  912. # [21:29] <Hixie> TabAtkins: you want '((src host web.server.address) && (src port 80)) || ((dst host web.server.address) && (dst port 80))' or something
  913. # [21:31] * Quits: nessy (~Adium@124-168-170-167.dyn.iinet.net.au) (Quit: Leaving.)
  914. # [21:31] <Hixie> smaug: Something like:
  915. # [21:31] <Hixie> The protocol is designed to support other frame types in future.
  916. # [21:31] <Hixie> Instead of the 0x00 byte, other bytes might in future be defined.
  917. # [21:31] <Hixie> ...?
  918. # [21:31] <Hixie> (from 10.3.4.1.2 Protocol overview)
  919. # [21:31] <smaug> that is non-normative
  920. # [21:32] <smaug> er, which chapter
  921. # [21:32] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/complete.html#protocol-overview
  922. # [21:32] * smaug reads the one in ietf, since the API draft points to there
  923. # [21:32] <Hixie> wait, what normative conformance criteria do you want?
  924. # [21:33] <Hixie> the API draft is also in complete.html
  925. # [21:33] <Hixie> (http://www.whatwg.org/specs/web-apps/current-work/complete.html#network)
  926. # [21:34] <smaug> Something that in the future servers and clients may need to support other than 0x00 frames
  927. # [21:34] <smaug> not sure about the wording
  928. # [21:34] * Joins: Maurice (copyman@5ED548D4.cable.ziggo.nl)
  929. # [21:35] <Hixie> I don't understand what the requirement would be
  930. # [21:35] <smaug> currently the requirement is that server always sends 0x00 frames
  931. # [21:35] <smaug> *always* only 0x00 frames
  932. # [21:36] <smaug> in the future we want to support something else too
  933. # [21:36] <Hixie> sure. in the future we'll update teh spec.
  934. # [21:36] * smaug doesn't like non-stable specs
  935. # [21:37] <smaug> which are always just drafts
  936. # [21:39] <zcorpan__> why not?
  937. # [21:39] <smaug> in general? because of backwards compatibility problems
  938. # [21:43] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  939. # [21:47] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  940. # [21:47] <Hixie> smaug: improving a spec over time doesn't mean it's not stable
  941. # [21:48] * Quits: ROBOd (~robod@89.122.216.38) (Read error: Connection reset by peer)
  942. # [21:48] <smaug> right. I think, so far I haven't see a stable spec which has been just "improved"
  943. # [21:49] <smaug> I admin, W3C has tried to do that with erratas
  944. # [21:49] <smaug> admit
  945. # [21:49] <Hixie> so HTML has been unstable?
  946. # [21:50] <smaug> you mean html5
  947. # [21:50] <smaug> yes, unstable
  948. # [21:50] * Joins: ROBOd (~robod@89.122.216.38)
  949. # [21:50] * Joins: nessy (~Adium@124-168-170-167.dyn.iinet.net.au)
  950. # [21:50] <smaug> just an example: hashchange
  951. # [21:50] <Hixie> i mean HTML 1-4
  952. # [21:51] <smaug> they are new versions
  953. # [21:51] <smaug> new specs
  954. # [21:52] <Hixie> that's what i mean we'll do with websockets
  955. # [21:52] <smaug> ah
  956. # [21:52] <smaug> I thought something like with html5
  957. # [21:52] <smaug> never-ever stable
  958. # [21:52] <Hixie> i don't see the difference
  959. # [21:53] <TabAtkins> I too am curious as to the difference between minting a new version identifier for changes, and just changing the existing spec.
  960. # [21:53] <Hixie> whatwg html is on "version 4745"
  961. # [21:53] <Hixie> if you go by subversion revisions
  962. # [21:54] <TabAtkins> HTML 5.4745
  963. # [21:54] <smaug> so browser x may support version 4733 and some other browser version 4655 and they have conflicting behavior, yet both say that they support HTML5
  964. # [21:55] <smaug> not the perfect situation
  965. # [21:55] <TabAtkins> Welcome to the web?
  966. # [21:55] <TabAtkins> At least they can't claim to support the same edition of the spec and still be conflicting (if we've done things right).
  967. # [21:56] <Hixie> smaug: um, that's no worse than what happened with html 1-4
  968. # [21:56] <TabAtkins> This TCPdump output just tells me that there is regular communication for almost exactly 4 minutes between browser and server, and then it suddenly cuts out (at which point the browser navigates to the form's action). I can't decipher anything special happening near the end that could cause problems.
  969. # [21:57] <smaug> there browser x was saying it support v4, and y supports v3
  970. # [21:57] <smaug> there is clear possibility for API breakage
  971. # [21:57] <TabAtkins> No, Browser X would claim to support v4, Browser Y would claim to support v4, and yet they would have conflicting behavior.
  972. # [21:58] <smaug> that is different thing
  973. # [21:58] <Hixie> it's the same thing
  974. # [21:58] <Hixie> in practice browsers don't claim to implement a particular version
  975. # [21:59] <Hixie> not in any meaningful way
  976. # [21:59] <smaug> they do in the API documentation
  977. # [22:00] <smaug> or whatever the documentation for web devs is called
  978. # [22:00] <Hixie> not in a meaningful way
  979. # [22:00] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  980. # [22:00] <othermaciej> hi everyone
  981. # [22:00] <smaug> pretty often the comment is that this and that HTML5 feature is supported ...
  982. # [22:00] <Hixie> there's going to be more delta between browser x and html5 version 4733 in your example than between html5 version 4733 and html5 version 4655
  983. # [22:01] <Hixie> smaug: sure, and often people say this and that DOM2 HTML or CSS2 or HTML4 feature is supported, and it's just as different between browsers
  984. # [22:01] <Hixie> at least with a regularly updated spec, the browsers have a chance of converging on something
  985. # [22:01] <Hixie> hey maciej
  986. # [22:01] <smaug> not necessarily if the web dev is interested only in one particular feature
  987. # [22:02] <smaug> anyway, this is pretty useless discussion :)
  988. # [22:04] <othermaciej> well, I'm supposed to be on vacation today but I just got a call to explain to my management what's going on with HTML5
  989. # [22:07] * Hixie checks his e-mail to make sure he's not also being dragged into work
  990. # [22:08] <smaug> Hixie: oh, one thing still
  991. # [22:08] * Joins: roc (~roc@121-74-161-151.telstraclear.net)
  992. # [22:08] <smaug> the back/forward discussion didn't continue for some reason
  993. # [22:08] <smaug> the draft was just changed to what chromium wants it to be
  994. # [22:09] <smaug> and that's it
  995. # [22:11] <Hixie> and what mozilla wanted
  996. # [22:11] <Hixie> but i think i have more e-mails in that folder
  997. # [22:11] <smaug> ?
  998. # [22:11] <Hixie> it's not finished yet
  999. # [22:12] <Hixie> (739 e-mails remaining)
  1000. # [22:12] <Hixie> (so it takes a while to go through them)
  1001. # [22:13] <smaug> I know it is kind of hard to say what Mozilla wants when Mozilla is a group of people which may have quite different opinions
  1002. # [22:15] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115132715])
  1003. # [22:17] * Joins: paul_irish (~paul_iris@c-71-192-163-128.hsd1.nh.comcast.net)
  1004. # [22:18] * Joins: nattokirai (~nattokira@y226086.dynamic.ppp.asahi-net.or.jp)
  1005. # [22:18] <Hixie> true
  1006. # [22:19] <Hixie> sicking said that he thought making it async would help mozilla, though, and sicking is pretty representative :-)
  1007. # [22:19] <smaug> but sicking is not the one who has been hacking session history lately ;)
  1008. # [22:21] <smaug> I'd just like to understand the reasoning behind making API async. So far the reasoning has been mainly just that in chromium's architecture sync might be a bit harder to implement
  1009. # [22:21] <Hixie> not just chrome's architecture, pretty much any multi-process model
  1010. # [22:21] <smaug> no
  1011. # [22:22] <Hixie> Justin's e-mail is the only one i seem to have in the history pile
  1012. # [22:22] <Hixie> but that's about pushState
  1013. # [22:22] <Hixie> did i miss one?
  1014. # [22:22] <smaug> as far as I see session history could live in a process between ui and the tab process
  1015. # [22:23] <smaug> Hixie: oops, seems like I've missed
  1016. # [22:23] <Hixie> yeah but any IPC basically has to be async
  1017. # [22:23] <smaug> sorry
  1018. # [22:23] <smaug> IPC doesn't have to be async
  1019. # [22:24] <Hixie> if you try doing sync IPC with the kind of model a browser implies, you're very likely to end up with either deadlocks or EXTREMELY complicated code
  1020. # [22:25] <roc> you just force the event loops into a directed acyclic graph and then require all calls in one direction to be async
  1021. # [22:26] <smaug> IPC from client process to parent doesn't have to be async
  1022. # [22:26] <smaug> and especially if there was a separate process for a "tab", that could handle session history
  1023. # [22:26] <Hixie> history traversal requires two-way communication
  1024. # [22:27] <smaug> if there was some problem with it, the main process could kill it
  1025. # [22:27] * Joins: Sidnicious (~Sidney@pdpc/supporter/professional/sidney)
  1026. # [22:27] <Hixie> if you can come up with a model that has each iframe in a different process, and can do sync history traversal, I'm certainly eager to hear how it would work.
  1027. # [22:27] <Hixie> please do e-mail such proposals to the list
  1028. # [22:28] <Hixie> currently, i'm not aware of any plausible way to do it that isn't insanely complicated compared to just making history traversal async
  1029. # [22:28] <Hixie> and since history traversal has to be mostly async anyway when you're doing cross-page traversal, it seems simple enough to do it async
  1030. # [22:28] <Hixie> (generally we want everything async anyway)
  1031. # [22:29] <Hixie> (so that e.g. script doesn't block on disk I/O)
  1032. # [22:29] <smaug> I'll think about the sync sh
  1033. # [22:30] <Hixie> frankly the best argument for keeping the same-page session history sync would be evidence that it's needed for back compat
  1034. # [22:31] <Hixie> lacking that, making it trigger based on queueing a task seems like a big win all round
  1035. # [22:31] <Hixie> (i wish we could make location.href async too, but that one clearly does have back compat requirmenets)
  1036. # [22:36] * Quits: ROBOd (~robod@89.122.216.38) (Quit: http://www.robodesign.ro)
  1037. # [22:37] * Joins: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at)
  1038. # [22:40] <zcorpan__> should there be a dimensionchange event for <video>?
  1039. # [22:41] <Hixie> probably in some future version, yeah
  1040. # [22:42] <zcorpan__> whatwg.org is down
  1041. # [22:42] <Hixie> weird
  1042. # [22:44] <Hixie> hm, googlebot is using a lot of slots
  1043. # [22:44] <Hixie> let me reduce the indexing frequency
  1044. # [22:44] * Joins: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  1045. # [22:48] <Hixie> zcorpan__: fixed
  1046. # [22:49] <Hixie> zcorpan__: i had a couple of CGI scripts that never finished, and as googlebot indexed them it was taking progressively more and more slots
  1047. # [22:49] <Hixie> they now terminate after 60s
  1048. # [22:49] * Joins: ttepasse (~ttepasse@dslb-084-060-031-019.pools.arcor-ip.net)
  1049. # [23:07] * aroben is now known as aroben|meeting
  1050. # [23:10] * Quits: nattokirai (~nattokira@y226086.dynamic.ppp.asahi-net.or.jp) (Quit: nattokirai)
  1051. # [23:15] * Quits: Maurice (copyman@5ED548D4.cable.ziggo.nl)
  1052. # [23:17] * Quits: Michelangelo (~Michelang@93-41-59-43.ip80.fastwebnet.it) (Remote host closed the connection)
  1053. # [23:22] * Joins: auk (~scott@cpe-98-149-72-10.socal.res.rr.com)
  1054. # [23:22] * Quits: auk (~scott@cpe-98-149-72-10.socal.res.rr.com) (Read error: Connection reset by peer)
  1055. # [23:28] * Joins: nattokirai (~nattokira@y226086.dynamic.ppp.asahi-net.or.jp)
  1056. # [23:28] <zcorpan__> Hixie: nice
  1057. # [23:28] <Hixie> also dramatically reduced the indexing frequency :-)
  1058. # [23:29] <Hixie> not much point indexing tests every 5 seconds
  1059. # [23:29] <zcorpan__> Hixie: apparently opera does send PARAM:"", but only since last week :)
  1060. # [23:29] <Hixie> i wish i had a way to test IE
  1061. # [23:30] <Philip`> Isn't there some existing plugin you could use and modify for testing?
  1062. # [23:30] <Philip`> (assuming that's what the problem was)
  1063. # [23:31] <Hixie> well on mac i just wrote my own plugin to dump the data out
  1064. # [23:31] <zcorpan__> do you have that plugin around somewhere?
  1065. # [23:31] <Hixie> sure
  1066. # [23:31] <Hixie> source or binary?
  1067. # [23:32] <zcorpan__> can i has both? :)
  1068. # [23:32] <Hixie> sure
  1069. # [23:32] <zcorpan__> awesome
  1070. # [23:32] * Quits: paul_irish (~paul_iris@c-71-192-163-128.hsd1.nh.comcast.net) (Quit: Leaving...)
  1071. # [23:38] * aroben|meeting is now known as aroben
  1072. # [23:41] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115132715])
  1073. # [23:42] <Hixie> http://junkyard.damowmow.com/408
  1074. # [23:43] <Hixie> zcorpan__: ^
  1075. # [23:43] <zcorpan__> Hixie: thanks!
  1076. # [23:44] <Hixie> let me know if you find anything in there that i shouldn't have put in public :-)
  1077. # [23:44] <Hixie> i didn't look closley
  1078. # [23:44] <Hixie> closely
  1079. # [23:45] <zcorpan__> still loading...
  1080. # [23:45] <Hixie> also, that code is a mess. It has memory leaks and the like. I didn't do anything to fix it because all I wanted was the data, and once I had it I was done and threw it out
  1081. # [23:45] <zcorpan__> connection timed out
  1082. # [23:45] <Hixie> (i wouldn't be surprised if it had security bugs and stuff)
  1083. # [23:45] <Hixie> (so don't install it on a production machine)
  1084. # [23:46] <Hixie> wfm
  1085. # [23:49] <zcorpan__> i can't reach it from here for some reason. i'll try at the office tomorrow
  1086. # [23:49] <Hixie> can you get to hixie.ch?
  1087. # [23:49] <zcorpan__> no
  1088. # [23:49] <jgraham> zcorpan__: wfm
  1089. # [23:49] <TabAtkins> I can reach it, fwiw.
  1090. # [23:50] <Hixie> zcorpan__: odd
  1091. # [23:50] <Hixie> zcorpan__: can you ping hixie.ch?
  1092. # [23:50] <zcorpan__> ping times out too
  1093. # [23:51] <zcorpan__> maybe park hotel has blocked hixie.ch
  1094. # [23:51] <Hixie> can you ping 69.163.222.251 ?
  1095. # [23:51] <jgraham> Too many Opera employees trying to reach it :)
  1096. # [23:53] <zcorpan__> Hixie: times out
  1097. # [23:53] <Hixie> weird
  1098. # [23:53] <zcorpan__> dns lookup for hixie.ch is successful
  1099. # [23:53] <Hixie> if you traceroute it, where does the route fail?
  1100. # [23:53] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1101. # [23:56] <zcorpan__> 3 sar-l1.se.thecloud.net (10.5.24.134) 97.385 ms 28.379 ms 26.584 ms
  1102. # [23:57] <zcorpan__> all others say * * * *
  1103. # [23:57] <zcorpan__> er
  1104. # [23:57] <zcorpan__> * * *
  1105. # [23:57] <Hixie> then the problem is definitely at your ewnd
  1106. # [23:57] <Hixie> end
  1107. # [23:57] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 264 seconds)
  1108. # [23:57] <Hixie> because i doubt very much dreamhost peer with thecloud.net :-)
  1109. # [23:57] <zcorpan__> yeah
  1110. # [23:58] <jcranmer> dump a bgp route advertisement and check the ASN path?
  1111. # [23:58] <zcorpan__> time to sleep
  1112. # [23:58] <zcorpan__> dump eyelocks
  1113. # [23:58] * Hixie would have no idea how to dump route advertisements or check ASN paths :-)
  1114. # [23:59] * Quits: zcorpan__ (~zcorpan@91-103-36-68.dynamic.thecloud.net) (Quit: zcorpan__)
  1115. # Session Close: Tue Feb 16 00:00:00 2010

The end :)