/irc-logs / freenode / #whatwg / 2010-04-11 / end

Options:

  1. # Session Start: Sun Apr 11 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:20] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: Leaving)
  4. # [00:30] * Quits: Michelangelo (~Michelang@93-42-7-234.ip84.fastwebnet.it) (Remote host closed the connection)
  5. # [00:50] * Parts: divya (~divya@c-24-18-47-121.hsd1.wa.comcast.net)
  6. # [00:53] * Quits: eighty4 (~eighty4@c-39c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  7. # [00:53] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  8. # [00:57] * Joins: estellevw_ (~estellevw@adsl-76-254-5-221.dsl.pltn13.sbcglobal.net)
  9. # [00:59] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  10. # [00:59] * Quits: estellevw (~estellevw@adsl-99-139-51-54.dsl.pltn13.sbcglobal.net) (Ping timeout: 240 seconds)
  11. # [00:59] * estellevw_ is now known as estellevw
  12. # [00:59] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  13. # [01:02] * Quits: grimboy (~grimboy@78-86-152-156.zone2.bethere.co.uk) (Remote host closed the connection)
  14. # [01:04] * Joins: othermaciej_ (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  15. # [01:04] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  16. # [01:04] * othermaciej_ is now known as othermaciej
  17. # [01:05] * Joins: seventh (galofort@208.98.1.237)
  18. # [01:05] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  19. # [01:08] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Read error: Operation timed out)
  20. # [01:55] * Quits: TabAtkins__ (~chatzilla@76-253-3-102.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 248 seconds)
  21. # [02:00] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 246 seconds)
  22. # [02:01] * Quits: paul_irish (~paul_iris@64.119.159.231) (Remote host closed the connection)
  23. # [02:06] * Parts: estellevw (~estellevw@adsl-76-254-5-221.dsl.pltn13.sbcglobal.net)
  24. # [02:12] * Joins: surkov (~surkov@client-65-40.sibtele.com)
  25. # [02:13] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  26. # [02:16] * Joins: Amorphous (jan@unaffiliated/amorphous)
  27. # [02:18] * seutje is now known as frigginCarebear
  28. # [02:27] * Joins: paul_irish (~paul_iris@static-68-162-220-26.bos.east.verizon.net)
  29. # [02:27] * Quits: paul_irish (~paul_iris@static-68-162-220-26.bos.east.verizon.net) (Remote host closed the connection)
  30. # [02:33] * Joins: paul_irish (~paul_iris@c-98-216-49-228.hsd1.ma.comcast.net)
  31. # [02:50] * Joins: othermaciej (~mjs@76.14.73.144)
  32. # [02:50] * Joins: jwalden (~waldo@c-67-180-84-153.hsd1.ca.comcast.net)
  33. # [02:52] * Joins: nessy (~Adium@124-168-176-223.dyn.iinet.net.au)
  34. # [03:06] * Joins: MikeSmithX (~MikeSmith@EM114-48-195-173.pool.e-mobile.ne.jp)
  35. # [03:09] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  36. # [03:11] * Quits: MikeSmith (~MikeSmith@EM114-48-150-53.pool.e-mobile.ne.jp) (Ping timeout: 276 seconds)
  37. # [03:21] * Joins: estellevw (~estellevw@adsl-76-254-5-221.dsl.pltn13.sbcglobal.net)
  38. # [03:23] * Quits: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  39. # [03:26] * Quits: othermaciej (~mjs@76.14.73.144) (Quit: othermaciej)
  40. # [03:33] * Quits: estellevw (~estellevw@adsl-76-254-5-221.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  41. # [03:43] * Joins: estellevw (~estellevw@adsl-76-254-5-221.dsl.pltn13.sbcglobal.net)
  42. # [03:43] * Parts: mercator (~mercator@ip3e831e0f.speed.planet.nl)
  43. # [03:49] * Quits: paul_irish (~paul_iris@c-98-216-49-228.hsd1.ma.comcast.net) (Remote host closed the connection)
  44. # [04:10] * Quits: nessy (~Adium@124-168-176-223.dyn.iinet.net.au) (Quit: Leaving.)
  45. # [04:13] * Quits: shepazu (~schepers@64.119.159.231) (Quit: shepazu)
  46. # [04:25] * Joins: mmn (~mmn@CPE001a70d49598-CM001ac3181c8a.cpe.net.cable.rogers.com)
  47. # [04:27] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: Verlassend)
  48. # [04:27] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 265 seconds)
  49. # [04:39] * Joins: Amorphous (jan@unaffiliated/amorphous)
  50. # [04:47] * Joins: othermaciej (~mjs@c-67-180-197-126.hsd1.ca.comcast.net)
  51. # [05:07] * Joins: Rik` (~Rik`@173.200.178.70)
  52. # [05:09] * Joins: othermaciej_ (~mjs@76.14.73.144)
  53. # [05:12] * Joins: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  54. # [05:12] * Quits: othermaciej (~mjs@c-67-180-197-126.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
  55. # [05:12] * othermaciej_ is now known as othermaciej
  56. # [05:14] * Quits: othermaciej (~mjs@76.14.73.144) (Client Quit)
  57. # [05:20] * Joins: Bolkonskij (~Bolkonski@unaffiliated/bolkonskij)
  58. # [05:37] * Quits: surkov (~surkov@client-65-40.sibtele.com) (Quit: surkov)
  59. # [05:58] * Joins: knowtheory (~knowtheor@bas1-london16-1176190035.dsl.bell.ca)
  60. # [06:00] * Joins: auk (~scott@cpe-98-149-72-10.socal.res.rr.com)
  61. # [06:02] * Joins: mr_danie1 (~irssi@e177148092.adsl.alicedsl.de)
  62. # [06:03] * Quits: mr_daniel (~irssi@e177154036.adsl.alicedsl.de) (Read error: Operation timed out)
  63. # [06:21] * Joins: wakaba_ (~wakaba_@203-140-91-140.eonet.ne.jp)
  64. # [06:28] * Joins: TabAtkins__ (~chatzilla@76-253-3-102.lightspeed.sntcca.sbcglobal.net)
  65. # [06:31] * Joins: paul_irish (~paul_iris@c-71-192-163-128.hsd1.nh.comcast.net)
  66. # [06:41] * Quits: TabAtkins__ (~chatzilla@76-253-3-102.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds)
  67. # [06:51] * Joins: jaket (~jake@124-168-46-183.dyn.iinet.net.au)
  68. # [07:00] * Quits: Rik` (~Rik`@173.200.178.70) (Ping timeout: 276 seconds)
  69. # [07:46] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  70. # [07:46] * Joins: nessy (~Adium@124-168-176-223.dyn.iinet.net.au)
  71. # [07:51] * Parts: nessy (~Adium@124-168-176-223.dyn.iinet.net.au)
  72. # [08:10] * Quits: jaket (~jake@124-168-46-183.dyn.iinet.net.au) (Ping timeout: 276 seconds)
  73. # [08:16] * Joins: jaket (~jake@210-84-34-103.dyn.iinet.net.au)
  74. # [08:44] * Quits: mmn (~mmn@CPE001a70d49598-CM001ac3181c8a.cpe.net.cable.rogers.com) (Quit: Leaving.)
  75. # [08:45] * Joins: myakura (~myakura@p1104-ipbf2109marunouchi.tokyo.ocn.ne.jp)
  76. # [08:48] <estellevw> There were five global attributes related to microdata including itemid, itemprop, itemref, itemscope and itemtype that i remember seeing, but don't see in the spec right now. Am I missing something?
  77. # [08:51] * Joins: othermaciej (~mjs@c-67-180-197-126.hsd1.ca.comcast.net)
  78. # [08:51] * Quits: othermaciej (~mjs@c-67-180-197-126.hsd1.ca.comcast.net) (Client Quit)
  79. # [08:54] <myakura> estellevw: they got split off from the main HTML5 spec about a month (or two) ago.
  80. # [08:54] <estellevw> thanks
  81. # [08:55] <estellevw> is it likely to come back in?
  82. # [08:56] <myakura> I guess the WHATWG version of HTML5 still incorporates it.
  83. # [08:56] <myakura> for W3C version, see http://www.w3.org/TR/microdata/ .
  84. # [08:57] <estellevw> yeah, looking at it
  85. # [08:57] <estellevw> i think it needs some editing. The attributes are in the body but not in the table of contents
  86. # [08:59] <estellevw> http://www.w3.org/TR/microdata/#attr-itemref and the like have lost their original stature.
  87. # [08:59] * Joins: TabAtkins__ (~chatzilla@76-253-3-102.lightspeed.sntcca.sbcglobal.net)
  88. # [09:00] <estellevw> it states The following attributes are added as global attributes to HTML elements:
  89. # [09:00] <estellevw> * itemid
  90. # [09:00] <estellevw> * itemprop
  91. # [09:00] <estellevw> * itemref
  92. # [09:00] <estellevw> * itemscope
  93. # [09:00] <estellevw> * itemtype
  94. # [09:00] <estellevw> oops, sorry
  95. # [09:00] <estellevw> but if i recall correctly, those aren't listed in teh global attributes anymore
  96. # [09:01] <estellevw> the global attributes being here: http://www.w3.org/TR/html5/dom.html#global-attributes
  97. # [09:04] <myakura> because they are two separete specs; Microdata is build on top of HTML5 so those item* attributes cannot be defined in HTML5.
  98. # [09:07] <estellevw> ok, makes sense as to why role, and the aria-* attributes aren't listed as global even though they are too
  99. # [09:07] <estellevw> thanks
  100. # [09:07] <myakura> yeah..
  101. # [09:07] * Joins: MikeSmith (~MikeSmith@EM114-48-137-88.pool.e-mobile.ne.jp)
  102. # [09:08] <myakura> just refer to the WHATWG version and you won't get confused :)
  103. # [09:08] <myakura> MikeSmith: aloha
  104. # [09:09] <estellevw> i can still get confused, but i'll have to blame myself ;)
  105. # [09:09] * Quits: auk (~scott@cpe-98-149-72-10.socal.res.rr.com) (Quit: Ex-Chat)
  106. # [09:10] * Quits: MikeSmithX (~MikeSmith@EM114-48-195-173.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  107. # [09:18] * Quits: TabAtkins__ (~chatzilla@76-253-3-102.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 248 seconds)
  108. # [09:34] * Quits: jwalden (~waldo@c-67-180-84-153.hsd1.ca.comcast.net) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2/20100122095031])
  109. # [09:52] * Quits: erikvold (~erikvold@S01060024012860e9.gv.shawcable.net) (Quit: erikvold)
  110. # [10:08] * Quits: myakura (~myakura@p1104-ipbf2109marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving...)
  111. # [10:15] * Joins: myakura (~myakura@p1104-ipbf2109marunouchi.tokyo.ocn.ne.jp)
  112. # [10:27] * Joins: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  113. # [10:27] * Quits: estellevw (~estellevw@adsl-76-254-5-221.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  114. # [10:29] * Joins: othermaciej (~mjs@c-67-180-197-126.hsd1.ca.comcast.net)
  115. # [10:29] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  116. # [10:31] * Joins: surkov (~surkov@client-65-40.sibtele.com)
  117. # [10:33] * Joins: ROBOd (~robod@89.122.216.38)
  118. # [10:33] * Quits: surkov (~surkov@client-65-40.sibtele.com) (Client Quit)
  119. # [10:38] * Quits: wakaba_ (~wakaba_@203-140-91-140.eonet.ne.jp) (Ping timeout: 260 seconds)
  120. # [10:40] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  121. # [10:40] * Joins: surkov (~surkov@client-65-40.sibtele.com)
  122. # [10:42] * Joins: netmonster (~netmonste@mail.lionmv.com)
  123. # [10:44] * Quits: jaket (~jake@210-84-34-103.dyn.iinet.net.au) (Read error: Connection reset by peer)
  124. # [10:44] * Joins: jaket_ (~jake@210-84-34-103.dyn.iinet.net.au)
  125. # [10:44] * jaket_ is now known as jaket
  126. # [10:44] * Quits: jaket (~jake@210-84-34-103.dyn.iinet.net.au) (Client Quit)
  127. # [10:47] * Quits: netmonster (~netmonste@mail.lionmv.com) (Quit: Leaving)
  128. # [10:48] * Joins: othermaciej_ (~mjs@76.14.73.144)
  129. # [10:52] * Quits: othermaciej (~mjs@c-67-180-197-126.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
  130. # [10:52] * othermaciej_ is now known as othermaciej
  131. # [11:00] * Joins: FireFly (~firefly@1-1-3-36a.tul.sth.bostream.se)
  132. # [11:00] * Quits: FireFly (~firefly@1-1-3-36a.tul.sth.bostream.se) (Changing host)
  133. # [11:00] * Joins: FireFly (~firefly@unaffiliated/firefly)
  134. # [11:04] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  135. # [11:17] * Quits: Bolkonskij (~Bolkonski@unaffiliated/bolkonskij) (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
  136. # [11:21] * Joins: mhausenblas (~mhausenbl@79.97.142.102)
  137. # [11:21] * Quits: ray (ray@the.ug) (Ping timeout: 265 seconds)
  138. # [11:28] * Joins: ray (ray@the.ug)
  139. # [11:30] * Quits: frigginCarebear (~seutje@drupal.org/user/264148/view) (Ping timeout: 276 seconds)
  140. # [11:30] * Quits: mhausenblas (~mhausenbl@79.97.142.102) (Quit: brb)
  141. # [11:33] * Joins: seutje (~seutje@drupal.org/user/264148/view)
  142. # [11:39] * Joins: mhausenblas (~mhausenbl@79.97.142.102)
  143. # [11:47] * Quits: othermaciej (~mjs@76.14.73.144) (Quit: othermaciej)
  144. # [11:54] * Quits: surkov (~surkov@client-65-40.sibtele.com) (Quit: surkov)
  145. # [11:56] * Quits: mhausenblas (~mhausenbl@79.97.142.102) (Read error: Connection timed out)
  146. # [11:57] * Joins: mhausenblas (~mhausenbl@79.97.142.102)
  147. # [12:00] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  148. # [12:14] * Quits: mhausenblas (~mhausenbl@79.97.142.102) (Read error: Connection timed out)
  149. # [12:15] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  150. # [12:16] * Joins: mhausenblas (~mhausenbl@79.97.142.102)
  151. # [12:28] * Joins: maikmerten (~maikmerte@port-92-201-167-200.dynamic.qsc.de)
  152. # [12:32] * Quits: mhausenblas (~mhausenbl@79.97.142.102) (Read error: Connection timed out)
  153. # [12:34] * Joins: mhausenblas (~mhausenbl@79.97.142.102)
  154. # [12:34] * Quits: mhausenblas (~mhausenbl@79.97.142.102) (Client Quit)
  155. # [12:34] * Joins: surkov (~surkov@client-65-40.sibtele.com)
  156. # [12:36] <MikeSmith> myakura: here now
  157. # [12:37] <MikeSmith> hsivonen: if/when you are around and have time to chat, please ping me
  158. # [12:37] <MikeSmith> in regard to http://dev.w3.org/html5/spec/text-level-semantics.html#guidance-for-conformance-checkers
  159. # [12:50] <MikeSmith> writing code for a conformance checker to check "The img element is part of the only paragraph directly in its section" or even "only non-whitespace content in the only paragraph directly in its section" is not easy
  160. # [12:53] <annevk> prolly also depends on how you implement things
  161. # [12:54] <MikeSmith> well, it's not practical at all to implement using a grammar-based schema, so we forget about that completely
  162. # [12:56] <MikeSmith> and it's quite complicated to implement in the Java code that validator.nu currently uses for things that can't be checked practically using grammar-based checking
  163. # [12:58] <MikeSmith> as far as I can see, it will require adding code that is very unlike existing code for any other checking that is being done by validator.nu
  164. # [13:06] <othermaciej> MikeSmith: I think that particular exception is not very well justified in the first place
  165. # [13:06] <othermaciej> MikeSmith: but yeah, to check an "only paragraph in its section" condition would require running the HTML5 outline algorithm I think
  166. # [13:07] <MikeSmith> It would be help to have the spec provide the intended rationale for that exception
  167. # [13:08] <othermaciej> MikeSmith: Hixie explained it a bit in the specific bug Laura filed about it
  168. # [13:08] <MikeSmith> ok
  169. # [13:08] <othermaciej> let me see if I can find it
  170. # [13:09] <othermaciej> MikeSmith: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9217
  171. # [13:10] <MikeSmith> I see
  172. # [13:10] <othermaciej> MikeSmith: I would personally think it was fine to say "just use figure"
  173. # [13:10] <MikeSmith> well, I think we could all live without that particular exception
  174. # [13:10] <MikeSmith> yeah, what you said
  175. # [13:11] <othermaciej> because associating the relevant section header with the image is much more complicated
  176. # [13:11] <othermaciej> as much as you don't want to implement it in the validator, I *really* don't want to implement the outline algorithm solely for our accessibility code to handle this case
  177. # [13:12] <MikeSmith> yep
  178. # [13:14] <othermaciej> I'm adding a comment to the bug
  179. # [13:14] <MikeSmith> OK
  180. # [13:18] <othermaciej> done
  181. # [13:19] <othermaciej> I mentioned the validator issue but feel free to comment as well
  182. # [13:20] <othermaciej> the rate of incoming bugs is just ridiculous
  183. # [13:20] <othermaciej> can't believe we are up to 90 already, there were about 42 just a few days ago
  184. # [13:21] <MikeSmith> well, in some ways, incoming bugs is a sign of progress
  185. # [13:21] <othermaciej> it's a sign of people reviewing the spec
  186. # [13:21] <MikeSmith> e.g., with the media-accessibility bugs that Silvia raised
  187. # [13:21] <othermaciej> which is good
  188. # [13:21] <MikeSmith> true that
  189. # [13:22] <othermaciej> I don't feel bad about incoming bugs, as long as the rate of outgoing bugs is also high
  190. # [13:27] * Quits: maikmerten (~maikmerte@port-92-201-167-200.dynamic.qsc.de) (Remote host closed the connection)
  191. # [13:28] * Joins: maikmerten (~maikmerte@port-92-201-167-200.dynamic.qsc.de)
  192. # [13:45] * Quits: maikmerten (~maikmerte@port-92-201-167-200.dynamic.qsc.de) (Remote host closed the connection)
  193. # [13:47] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  194. # [13:55] <myakura> MikeSmith: I talked with Shiraishi-san on Friday about what we're gonna talk in Fukuoka.
  195. # [13:56] <MikeSmith> OK
  196. # [13:58] <myakura> MikeSmith: and their plan is to: Takuya will do the keynote-like talk (.5hr), and You and I do about Web Standards in general (like what you did at DevFest)
  197. # [13:58] <MikeSmith> sounds good so far
  198. # [13:59] <myakura> MikeSmith: Oli for markup stuff, Shiraishi-san will talk about APIs, and Anne to do about "CSS latest status"
  199. # [13:59] <myakura> and I'm not sure you guys heard about that
  200. # [13:59] <myakura> and whether you guys are okay with that.
  201. # [14:00] <boblet> oh, good timing
  202. # [14:00] <boblet> hey all
  203. # [14:02] <myakura> boblet: heya.
  204. # [14:02] <boblet> myakura: by markup stuff do you mean sectioning elements etc?
  205. # [14:02] <boblet> or also CSS?
  206. # [14:03] <myakura> MikeSmith: btw we have an hour for each session but for yours and Anne's I need to interpret so you guys will have shorter time (40min?)
  207. # [14:04] <MikeSmith> myakura: that sounds fine
  208. # [14:04] <myakura> boblet: the table only shows "HTML5 Mark up" ...
  209. # [14:08] <boblet> myakura: will check it out. thanks for the info. Guess I better read Mike’s slides
  210. # [14:34] * Quits: kennyluck (~kennyluck@tea04.w3.mag.keio.ac.jp) (Quit: kennyluck)
  211. # [14:50] * Joins: maikmerten (~maikmerte@port-92-201-167-200.dynamic.qsc.de)
  212. # [15:08] * Quits: beilabs_ (~beilabs@ppp121-44-76-135.lns20.syd6.internode.on.net) (Ping timeout: 268 seconds)
  213. # [15:09] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Ping timeout: 246 seconds)
  214. # [15:10] * Quits: MikeSmith (~MikeSmith@EM114-48-137-88.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  215. # [15:11] * Quits: Lachy (~Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  216. # [15:15] * Joins: MikeSmith (~MikeSmith@EM114-48-163-186.pool.e-mobile.ne.jp)
  217. # [15:31] * Joins: beilabs (~beilabs@ppp121-44-196-55.lns20.syd7.internode.on.net)
  218. # [15:35] * Quits: surkov (~surkov@client-65-40.sibtele.com) (Quit: surkov)
  219. # [15:39] * Quits: beilabs (~beilabs@ppp121-44-196-55.lns20.syd7.internode.on.net) (Read error: Operation timed out)
  220. # [15:43] * Quits: drry (~drry@unaffiliated/drry) (Read error: Connection timed out)
  221. # [15:47] * Joins: drry (~drry@unaffiliated/drry)
  222. # [16:11] * Joins: beilabs (~beilabs@ppp121-44-196-55.lns20.syd7.internode.on.net)
  223. # [16:16] * Quits: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  224. # [16:43] * Quits: wakaba (~wakaba@96.22.102.121.dy.bbexcite.jp) (Quit: Leaving...)
  225. # [16:53] * Joins: wakaba (~wakaba@96.22.102.121.dy.bbexcite.jp)
  226. # [16:54] * Joins: estellevw (~estellevw@adsl-76-254-5-221.dsl.pltn13.sbcglobal.net)
  227. # [16:58] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Read error: Connection reset by peer)
  228. # [16:59] * Joins: erlehmann (~erlehmann@dslb-088-075-178-218.pools.arcor-ip.net)
  229. # [16:59] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
  230. # [17:00] * Joins: Rik` (~Rik`@173.200.178.70)
  231. # [17:00] * Joins: shepazu (~schepers@64.119.159.231)
  232. # [17:01] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  233. # [17:36] * Quits: shepazu (~schepers@64.119.159.231) (Quit: shepazu)
  234. # [17:42] <jgraham> It seems like AT would want access to the document outline in any case
  235. # [17:44] <jgraham> And presumably webkit will have to implment it anyway once we get :section(n)
  236. # [17:45] <annevk> if we ever decide to do that
  237. # [17:45] <jgraham> Well sure
  238. # [17:45] <jgraham> If we don't decide to do that the whole outline algorithm is likely a waste of time
  239. # [17:48] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  240. # [17:54] * Joins: TabAtkins__ (~chatzilla@76-253-3-102.lightspeed.sntcca.sbcglobal.net)
  241. # [18:21] * Quits: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl) (Quit: Necrathex)
  242. # [18:40] * Joins: micheil (~micheil@124-170-75-25.dyn.iinet.net.au)
  243. # [18:40] <micheil> hmm.. would this be the place to ask a quick question about one of your spec proposals?
  244. # [18:40] <jgraham> Yes
  245. # [18:41] <micheil> okay, with the websocket protocol, would I be right in assuming that one server would be able to server multiple different sockets / data sets to clients based on the paths at which they connect?
  246. # [18:42] <jgraham> With the proviso I am not an expert on that spec, yes
  247. # [18:42] <micheil> okay
  248. # [18:42] <jgraham> The server can do whatever it wants based on anything the client sends including the path part
  249. # [18:43] <jgraham> (subject to it meeting the requirements for a successful connection of course)
  250. # [18:44] <micheil> yeah, I'm just trying to work out how to direct data about by using that, all the reference implementations I can find don't indicate anything on that
  251. # [18:46] <jgraham> Well when the server recieves the client handshake it parses out the path so you can arrange for it to be passed to the app
  252. # [18:46] <jgraham> Not sure what existing implementations do though
  253. # [18:46] * Joins: davidb (~davidb@bas1-toronto06-1242366177.dsl.bell.ca)
  254. # [18:47] <micheil> yeah, just trying to think if it's possible to send data to a specific connection or not
  255. # [18:47] <micheil> (ie, rather then just being a broadcast type service)
  256. # [18:47] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  257. # [18:48] <micheil> I suppose because the writes to the network stream would be done from within a connection, you'd handle it there maybe..
  258. # [18:49] <jgraham> If I follow you, that sounds right
  259. # [18:49] * Quits: erlehmann (~erlehmann@dslb-088-075-178-218.pools.arcor-ip.net) (Ping timeout: 276 seconds)
  260. # [18:50] * Joins: erlehmann (~erlehmann@dslb-088-075-178-218.pools.arcor-ip.net)
  261. # [18:50] <jgraham> From the point of view of the server each client is a seperate connection so you can read and write to each client independently
  262. # [18:51] <micheil> hopefully
  263. # [18:51] <jgraham> I don't really see how it could work otherwise
  264. # [18:52] <micheil> I suppose I should just work out the raw tcp send switching first, then add on the websocket protocol
  265. # [18:54] <MikeSmith> jgraham: conformance checkers should not require access to the document outline
  266. # [18:55] <jgraham> MikeSmith: I didn't mean to have any opinion on conformance checkers
  267. # [18:55] <jgraham> Just other types of UA
  268. # [18:55] <MikeSmith> I see
  269. # [18:55] <MikeSmith> I can see that AT having access to the document outline would be good
  270. # [18:56] <MikeSmith> but then there are many things that AT should be doing that they are not currently
  271. # [18:57] <jgraham> Right, but I disagree with othermaciej's assertion that implementing the outline algorithm in the accessibility code would soley be for this case
  272. # [19:01] <MikeSmith> yeah, it'd certainly seem it could end j useful for
  273. # [19:02] <MikeSmith> .. end up being useful for lth
  274. # [19:02] <MikeSmith> oops
  275. # [19:02] <MikeSmith> ...useful for other things
  276. # [19:02] <MikeSmith> (my fingers are cold)
  277. # [19:03] <jgraham> ah, I was imagining that you had insane keyboard macros that could expand a few characters into whole sentences
  278. # [19:03] <jgraham> and they had broken
  279. # [19:03] <MikeSmith> heh
  280. # [19:07] <MikeSmith> I just came back from sento, in 水風呂 water that's 17.1 degrees
  281. # [19:12] * jgraham assumes that is the kanji for "fucking cold"
  282. # [19:13] <micheil> it'd have to be less then 17 degrees outside here
  283. # [19:14] <jgraham> Well sure it is less than 17 degrees C outside here too
  284. # [19:14] <jgraham> But I wouldn't go in water that temperature
  285. # [19:14] <jgraham> The thermal conduction is a killer
  286. # [19:15] <micheil> actually. 20ºC here is cold.
  287. # [19:16] <AryehGregor> It's barely above 20°C here now, and it's starting to be summer already.
  288. # [19:17] <micheil> jgraham: I think the key to my websocket problem is in the http parsers (I'm working with node.js btw)
  289. # [19:18] <micheil> it's not even winter yet and it's 7.6ºC outside.
  290. # [19:18] <micheil> then again, I'm usually getting 30-45º in summer.
  291. # [19:23] * Quits: erlehmann (~erlehmann@dslb-088-075-178-218.pools.arcor-ip.net) (Quit: Ex-Chat)
  292. # [19:25] <MikeSmith> micheil: I think maybe websocket isn't meant to be used with existing http parsers
  293. # [19:25] <micheil> MikeSmith: it isn't. however, the key to building a robust node.js websocket server implementation lies in how http servers work
  294. # [19:26] <MikeSmith> I'm not familiar with node.js or what its main use cases are
  295. # [19:27] <micheil> async / evented javascript with network and file i/o
  296. # [19:27] <micheil> built on the same javascript engine that powers chrome / chromium
  297. # [19:29] * Joins: divya (~divya@c-24-18-47-121.hsd1.wa.comcast.net)
  298. # [19:42] * Parts: divya (~divya@c-24-18-47-121.hsd1.wa.comcast.net)
  299. # [19:46] <jgraham> micheil: Do you get raw socket access with node.js?
  300. # [19:46] <jgraham> If you do I would start from there rather than with the existing http parser
  301. # [19:46] <micheil> yeah, raw tcp / sockets
  302. # [19:47] <micheil> although, node's http parser is built on it's net sockets, so I can use that as reference
  303. # [19:49] * Quits: davidb (~davidb@bas1-toronto06-1242366177.dsl.bell.ca) (Quit: davidb)
  304. # [19:53] <jgraham> micheil: You might be just as well working from the simple echo server example in the documentation
  305. # [19:54] <micheil> not realy
  306. # [19:54] <micheil> not everything is documented, so there are some different ways to do things under the hood
  307. # [19:54] <jgraham> Or you sould take the existin websocket-in-node.js implementation and check that it supports the new handshake
  308. # [19:54] <jgraham> *could
  309. # [19:54] <micheil> (I wish the current net implementation was around when I started working on node-smtp-client)
  310. # [19:55] <micheil> jgraham: nawh, that takes away half the fun :P
  311. # [19:55] * jgraham should finish his websocket-server-in-python-diesel implementation
  312. # [19:56] <micheil> heh heh, what I'm wanting to get from this is pretty specific
  313. # [20:03] <AryehGregor> Hmm, so Google is funding efficient ARM decoding of Theora. I still have hope that they'll switch YouTube from H.264 someday.
  314. # [20:03] * Joins: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi)
  315. # [20:06] * Parts: micheil (~micheil@124-170-75-25.dyn.iinet.net.au)
  316. # [20:07] * Joins: micheil (~micheil@124-170-75-25.dyn.iinet.net.au)
  317. # [20:07] <jgraham> AryehGregor: Well I don't doubt they will. They question is will it be to theora and soon or to H.264.next and not-so-soon
  318. # [20:07] <AryehGregor> Heh.
  319. # [20:07] <JonathanNeal> updated ie print protector; added summary element, wrapped entire script in ie conditional (instead of individual fns), and compressed window/document variables (all based on remy sharp suggestions)
  320. # [20:09] * Quits: Rik` (~Rik`@173.200.178.70) (Ping timeout: 252 seconds)
  321. # [20:12] * Joins: dbaron (~dbaron@65-122-15-169.dia.static.qwest.net)
  322. # [20:12] * Quits: myakura (~myakura@p1104-ipbf2109marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving...)
  323. # [20:14] * Joins: eighty4 (~eighty4@c-39c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
  324. # [20:15] * Joins: grimboy (~grimboy@78-86-152-156.zone2.bethere.co.uk)
  325. # [20:18] <micheil> hmm.. due to the way the websocket protocol is, I'm not likely to need much of a really heavy parser for the handshake (initial GET request), am I?
  326. # [20:19] <jgraham> micheil: You need to parse out the headers to get the websocket-sec-key (or whatever they are called) values
  327. # [20:20] <jgraham> And you need the random bytes
  328. # [20:20] <micheil> yeah, but I want need the same level of parser as what a standard http server would
  329. # [20:20] <jgraham> and there are some requirements about when you must drop the connection
  330. # [20:20] <micheil> hmm.. random bytes..
  331. # [20:20] * micheil checks it
  332. # [20:20] <jgraham> But no, a full HTTP stack isn't necessary
  333. # [20:21] <micheil> hmm..
  334. # [20:21] <micheil> random bytes as in the ^n:ds[4u from the spec?
  335. # [20:22] <jgraham> The 8 bytes after the end of the part that looks like HTTP headers
  336. # [20:22] <micheil> which, according to http spec should probably be: ...headers..\r\n\r\nDATA\r\n\r\n
  337. # [20:22] <micheil> I think
  338. # [20:23] <jgraham> The HTTP spec isn't really relevant
  339. # [20:23] <jgraham> From the point of view of the HTTP spec they are the first 8 bytes of the body or so, I think
  340. # [20:27] <micheil> yeah, although, I'm just working out what I'll need to do to parser it
  341. # [20:31] * Quits: dbaron (~dbaron@65-122-15-169.dia.static.qwest.net) (Ping timeout: 246 seconds)
  342. # [20:44] <Hixie> simplest answer to that is to follow the rules in the parser section that tell you how to write the parser :-)
  343. # [20:44] <Hixie> section 5.1
  344. # [20:44] <micheil> Hixie: heh, I suppose you'd be the man to ask :P
  345. # [20:45] <micheil> Hixie: is there any sane way that you read those documents?
  346. # [20:48] <Hixie> how do you mean?
  347. # [20:49] * Joins: erikvold (~erikvold@S01060024012860e9.gv.shawcable.net)
  348. # [20:55] <micheil> well, there seems to be a lot of extra formatting on the IEFT / RFC type documents, is there a cleaner way to view them?
  349. # [21:02] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  350. # [21:10] * Quits: MikeSmith (~MikeSmith@EM114-48-163-186.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
  351. # [21:11] * Joins: erlehmann (~erlehmann@dslb-088-075-178-218.pools.arcor-ip.net)
  352. # [21:14] * Joins: cezarsa (~cezarsa@187.18.139.245)
  353. # [21:15] * Joins: MikeSmith (~MikeSmith@EM114-48-26-110.pool.e-mobile.ne.jp)
  354. # [21:16] * Joins: shepazu (~schepers@65.14.229.26)
  355. # [21:32] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  356. # [21:36] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  357. # [21:41] * Joins: Lachy (~Lachlan@85.196.122.246)
  358. # [21:47] * Quits: shepazu (~schepers@65.14.229.26) (Quit: shepazu)
  359. # [21:48] <jgraham> micheil: If you can use the complete.html spec on the WHATWG site. It is a bitch to load but once it is loaded it is rather good to read
  360. # [21:51] * Quits: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote host closed the connection)
  361. # [21:58] * Quits: maikmerten (~maikmerte@port-92-201-167-200.dynamic.qsc.de) (Read error: Connection reset by peer)
  362. # [22:06] * Joins: Rik` (~Rik`@173.200.178.70)
  363. # [22:15] * Joins: othermaciej_ (~mjs@76.14.73.144)
  364. # [22:16] * Quits: erlehmann (~erlehmann@dslb-088-075-178-218.pools.arcor-ip.net) (Quit: Ex-Chat)
  365. # [22:20] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  366. # [22:31] <annevk> http://adactio.com/journal/1654/ -- I still think we should drop <article> and get <content>
  367. # [22:32] <annevk> though maybe just dropping <article> for now and see what patterns emerge
  368. # [22:36] * othermaciej_ is now known as othermaciej
  369. # [22:37] * Quits: Rik` (~Rik`@173.200.178.70) (Ping timeout: 276 seconds)
  370. # [22:39] * Quits: cezarsa (~cezarsa@187.18.139.245) (Quit: cezarsa)
  371. # [22:48] <Hixie> annevk: i don't understand why people are so confused by them... they're completely differnet
  372. # [22:48] <Hixie> one is for chapters and the other is for syndicatable content
  373. # [22:48] <Hixie> they're different use cases with almost no overlap
  374. # [22:50] <Dashiva> Hixie: The confusion seems to be with the descriptions, maybe it's just a matter of condensing it down to a better explanation
  375. # [22:53] * Quits: Lachy (~Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  376. # [22:55] <Hixie> the descriptions are completely different
  377. # [22:55] <Hixie> i think the problem is that the element names aren't intuitive based on the descriptions
  378. # [22:56] * Quits: ROBOd (~robod@89.122.216.38) (Quit: http://www.robodesign.ro)
  379. # [22:56] <Hixie> but that's not a big problem, people will learn the difference in due course
  380. # [22:57] <Hixie> it's like <dl>, <ul>, and <ol>. Given just those element names and then descriptions of what they're for, how would you guess which was which?
  381. # [22:58] <annevk> hmm, would've been good to test that out
  382. # [22:59] <othermaciej> <article> and <section> as names sound very distinct
  383. # [22:59] <othermaciej> maybe the problem is with the descriptions
  384. # [22:59] * Joins: boaz_ (~boaz@64.119.159.231)
  385. # [22:59] * Quits: boaz_ (~boaz@64.119.159.231) (Client Quit)
  386. # [23:02] <othermaciej> "The section element represents a generic document or application section." --> ""The section element represents a generic section of a document or application"
  387. # [23:02] <othermaciej> I bet that by itself would reduce confusion
  388. # [23:02] <othermaciej> if you skim fast, the current text looks like "The ____ element represents a document"
  389. # [23:03] <othermaciej> "The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication."
  390. # [23:03] <othermaciej> and that one reads as "The ____ element represents a component" if you skim
  391. # [23:03] * Quits: TabAtkins__ (~chatzilla@76-253-3-102.lightspeed.sntcca.sbcglobal.net) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.13/2009073109])
  392. # [23:04] * Joins: rauchg (~rauchg@190.231.12.207)
  393. # [23:04] <othermaciej> could be something like "The article element represents a self-contained composition in a document, page, application, or site that is intended to be independently distributable or reusable, e.g. in syndication."
  394. # [23:04] <othermaciej> Hixie: ^
  395. # [23:04] <othermaciej> (annevk also)
  396. # [23:05] * Joins: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  397. # [23:14] * Joins: Lachy (~Lachlan@85.196.122.246)
  398. # [23:17] * Quits: MikeSmith (~MikeSmith@EM114-48-26-110.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  399. # [23:19] * Quits: Lachy (~Lachlan@85.196.122.246) (Ping timeout: 260 seconds)
  400. # [23:24] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  401. # [23:28] * Joins: cpearce (~cpearce@203-97-204-82.dsl.clear.net.nz)
  402. # [23:34] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  403. # [23:42] * Quits: othermaciej (~mjs@76.14.73.144) (Quit: othermaciej)
  404. # [23:45] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  405. # [23:45] * Quits: knowtheory (~knowtheor@bas1-london16-1176190035.dsl.bell.ca) (Quit: Computer has gone to sleep)
  406. # [23:59] * Quits: beilabs (~beilabs@ppp121-44-196-55.lns20.syd7.internode.on.net) (Quit: Leaving)
  407. # Session Close: Mon Apr 12 00:00:00 2010

The end :)