/irc-logs / freenode / #whatwg / 2007-06-04 / end

Options:

  1. # Session Start: Mon Jun 04 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:03] * Joins: webben (n=benh@82.152.242.81)
  4. # [00:18] * Joins: Welly (n=Welly@62-31-160-20.cable.ubr11.azte.blueyonder.co.uk)
  5. # [00:18] * Quits: webben_ (n=benh@82.152.242.81) (Read error: 110 (Connection timed out))
  6. # [00:22] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  7. # [00:26] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  8. # [00:35] * Quits: webben (n=benh@82.152.242.81) (Read error: 104 (Connection reset by peer))
  9. # [00:35] * othermaciej is now known as om_coffee
  10. # [00:36] * Joins: webben (n=benh@82.152.242.81)
  11. # [00:54] * om_coffee is now known as othermaciej
  12. # [01:01] * Joins: weinigLap_ (n=weinig@17.255.100.166)
  13. # [01:03] * Quits: Yudai (n=Yudai@p931d95.tokyte00.ap.so-net.ne.jp) (Read error: 110 (Connection timed out))
  14. # [01:03] * Joins: Yudai (n=Yudai@p931010.tokyte00.ap.so-net.ne.jp)
  15. # [01:08] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  16. # [01:13] * Quits: weinigLap (n=weinig@17.203.15.158) (Read error: 110 (Connection timed out))
  17. # [01:15] * Quits: weinigLap_ (n=weinig@17.255.100.166)
  18. # [01:21] * Joins: weinigLap_ (n=weinig@17.255.100.166)
  19. # [01:24] * Quits: hendry (n=hendry@91.84.53.136) (Remote closed the connection)
  20. # [01:32] * Joins: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  21. # [01:36] * Quits: weinigLap_ (n=weinig@17.255.100.166)
  22. # [01:38] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  23. # [01:40] * Joins: weinigLap (n=weinig@17.255.100.166)
  24. # [01:47] * Joins: weinigLap_ (n=weinig@17.203.15.158)
  25. # [01:56] * Joins: karlUshi (n=karl@dhcp-247-173.mag.keio.ac.jp)
  26. # [01:57] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 104 (Connection reset by peer))
  27. # [01:57] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  28. # [02:04] * Quits: weinigLap (n=weinig@17.255.100.166) (Read error: 110 (Connection timed out))
  29. # [02:09] * Quits: bzed (n=bzed@dslb-084-059-112-189.pools.arcor-ip.net) ("Leaving")
  30. # [02:15] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 110 (Connection timed out))
  31. # [02:15] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  32. # [02:38] * Quits: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com) (Read error: 110 (Connection timed out))
  33. # [02:41] * Joins: nlogax_ (n=nlogax@71-219.lerstenen.t3.se)
  34. # [02:42] * Quits: nlogax_ (n=nlogax@71-219.lerstenen.t3.se) (Client Quit)
  35. # [02:53] * Quits: Welly (n=Welly@62-31-160-20.cable.ubr11.azte.blueyonder.co.uk) (Client Quit)
  36. # [03:13] * Quits: Toolskyn88 (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Read error: 110 (Connection timed out))
  37. # [04:31] * Quits: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  38. # [04:36] * Joins: billyjack (n=MikeSmit@58.157.21.204)
  39. # [04:37] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 104 (Connection reset by peer))
  40. # [04:48] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  41. # [04:51] * Quits: mpt (n=mpt@121-72-131-30.dsl.telstraclear.net) ("Leaving")
  42. # [04:56] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  43. # [04:56] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  44. # [04:57] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  45. # [05:01] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  46. # [05:05] * Quits: othermaciej (n=mjs@17.255.100.150)
  47. # [05:12] * Joins: othermaciej (n=mjs@17.255.100.150)
  48. # [05:17] * Quits: billyjack (n=MikeSmit@58.157.21.204) (Read error: 104 (Connection reset by peer))
  49. # [05:17] * Joins: billyjack (n=MikeSmit@58.157.21.204)
  50. # [05:58] * Joins: mpt (n=mpt@121-72-131-30.dsl.telstraclear.net)
  51. # [06:17] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  52. # [06:17] * Quits: billyjack (n=MikeSmit@58.157.21.204) ("Get thee behind me, satan.")
  53. # [06:34] * Joins: bzed (n=bzed@dslb-084-059-119-181.pools.arcor-ip.net)
  54. # [08:07] * Quits: othermaciej (n=mjs@17.255.100.150)
  55. # [08:29] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  56. # [08:45] * Joins: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  57. # [08:53] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  58. # [08:54] * Quits: h3h (n=w3rd@cpe-66-75-149-197.san.res.rr.com)
  59. # [09:28] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  60. # [09:30] * Quits: karlUshi (n=karl@dhcp-247-173.mag.keio.ac.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
  61. # [09:34] * Joins: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net)
  62. # [09:36] * Joins: weinigLap (n=weinig@17.203.15.158)
  63. # [09:36] * Quits: weinigLap_ (n=weinig@17.203.15.158) (Read error: 104 (Connection reset by peer))
  64. # [09:47] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  65. # [09:48] * Quits: weinigLap (n=weinig@17.203.15.158)
  66. # [09:55] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  67. # [09:56] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  68. # [09:57] * Quits: webben (n=benh@82.152.242.81) (Client Quit)
  69. # [09:59] * Joins: webben (n=benh@82.152.242.81)
  70. # [10:01] * Quits: webben (n=benh@82.152.242.81) (Client Quit)
  71. # [10:10] * Joins: weinigLap (n=weinig@c-67-188-78-122.hsd1.ca.comcast.net)
  72. # [10:18] * Quits: kfish (n=conrad@61.194.21.25) ("switch")
  73. # [10:23] * Joins: hendry (n=hendry@91.84.53.136)
  74. # [10:34] * Joins: webben (i=benh@nat/yahoo/x-043811b38e1c4326)
  75. # [10:36] * Joins: Toolskyn88 (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  76. # [10:36] * Joins: ROBOd (n=robod@86.34.246.154)
  77. # [10:37] * Joins: Welly (n=Welly@62-31-160-20.cable.ubr11.azte.blueyonder.co.uk)
  78. # [10:41] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  79. # [10:50] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) ("Chatzilla 0.9.75.1 [SeaMonkey 1.1.1/2007031702]")
  80. # [10:51] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  81. # [11:00] * Quits: annevk (n=annevk@pat-tdc.opera.com) (Remote closed the connection)
  82. # [11:00] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  83. # [11:06] * Joins: karlUshi (n=karl@124-144-94-188.rev.home.ne.jp)
  84. # [11:06] * Quits: karlUshi (n=karl@124-144-94-188.rev.home.ne.jp) (Remote closed the connection)
  85. # [11:09] * Quits: weinigLap (n=weinig@c-67-188-78-122.hsd1.ca.comcast.net)
  86. # [11:39] * Joins: zcorpan (n=zcorpan@84-216-41-162.sprayadsl.telenor.se)
  87. # [11:47] * Joins: ddfreyne (n=ddfreyne@d54C57894.access.telenet.be)
  88. # [11:55] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne) ("kthxbai")
  89. # [12:03] * Joins: kfish (n=conrad@61.194.21.25)
  90. # [12:03] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Get thee behind me, satan.")
  91. # [12:06] * Quits: Welly (n=Welly@62-31-160-20.cable.ubr11.azte.blueyonder.co.uk) (Remote closed the connection)
  92. # [12:19] * Joins: maikmerten (n=maikmert@L8a95.l.pppool.de)
  93. # [12:37] * Quits: webben (i=benh@nat/yahoo/x-043811b38e1c4326) (Client Quit)
  94. # [12:44] <maikmerten> meh, Firefox hates me and won't load http://www.whatwg.org/specs/web-apps/current-work/#video
  95. # [12:44] * Joins: Toolskyn_ (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  96. # [12:44] <annevk> you can always try http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video
  97. # [12:48] <maikmerten> hmmm... that works
  98. # [12:48] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  99. # [12:49] <maikmerten> somehow my Firefox 2 (plain vanilla what comes with Ubuntu 7.04 plus a few extensions) is picky at times. It often gets into a "no, I won't load pages for you anymore until you kill and restart me" state
  100. # [12:50] <maikmerten> could be a profile issue, this profile may date back into Firefox alpha days ;)
  101. # [12:50] <maikmerten> err.. Phoenix alpha builds of course
  102. # [12:52] <maikmerten> I'm going to propose that http://wiki.xiph.org/index.php/OggPlayJavascriptAPI perhaps should be as close to the WHATWG API as possible
  103. # [12:53] <met_> annevk: what are reasons for XML5?
  104. # [12:53] <met_> it's only academic project or something more?
  105. # [12:54] <met_> oh www.xml5.com
  106. # [12:56] <zcorpan> http://code.google.com/p/xml5/
  107. # [12:56] <annevk> it might be worth something actually
  108. # [12:56] <annevk> ah, Phoenix!
  109. # [12:57] * annevk wondered about the third name for some time
  110. # [12:57] <zcorpan> was it phoenix -> firebird -> firefox?
  111. # [12:57] <annevk> maikmerten, they are already implementing support for Ogg and <video> in Firefox
  112. # [12:57] <annevk> zcorpan, yeah
  113. # [12:58] <met_> worth something? do you think webbrowsers will implement it?
  114. # [12:58] <annevk> maybe
  115. # [12:58] <annevk> dunno
  116. # [12:58] <annevk> it would certainly solve some issues
  117. # [12:59] <met_> so you are only playing with and will see the results later?
  118. # [12:59] * met_ just writing some article and want mention xml5
  119. # [13:00] <maikmerten> annevk, yup, Chris Double is working on that
  120. # [13:00] <annevk> I'm doing research into it and making a draft proposal as well as an experimental implementation
  121. # [13:00] <annevk> maikmerten, doesn't that make the plugin effort kind of pointless?
  122. # [13:00] <annevk> (which is what I was after)
  123. # [13:00] <maikmerten> annevk, well, I consider the plugin more or less a testbed for liboggplay
  124. # [13:01] <maikmerten> annevk, plus Chris mentioned he may look into the plugin/liboggplay to see if some things can be harvested
  125. # [13:01] <annevk> guess I should read up on liboggplay
  126. # [13:01] * Quits: Toolskyn88 (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Read error: 110 (Connection timed out))
  127. # [13:02] <annevk> hsivonen, I think UTF-32 is part of the deal
  128. # [13:02] <maikmerten> well, it's mostly a lightweight top-level abstraction library to play back Ogg streams in a sane way. It also handles A/V sync, which is nontrivial to do crossplatform
  129. # [13:04] <annevk> thans
  130. # [13:04] <maikmerten> only problem I see for use in browsers: It depends on libfishsound (abstraction layers for the multitude of Ogg audio codecs.... Speex, FLAC, Vorbis...) and on liboggz (abstraction layer for libogg, which is the very opposite of high-level)...
  131. # [13:04] <annevk> thanks*
  132. # [13:05] <maikmerten> so it may be a bit problematic to have such a deep stack of layers when it comes to security
  133. # [13:09] * Joins: karlUshi (n=karl@124-144-94-188.rev.home.ne.jp)
  134. # [13:10] <virtuelv> annevk: mind setting properties on html files in subversion?
  135. # [13:11] <virtuelv> that way, you could view http://xml5.googlecode.com/svn/trunk/specification/Overview.html in a regular browser
  136. # [13:11] <zcorpan> so xml5 parsers don't need to implement doctypes... they can abort instead :)
  137. # [13:12] <annevk> yeah, quite the opposite from HTML5 :)
  138. # [13:12] <zcorpan> heh
  139. # [13:13] <zcorpan> comments work exactly the same?
  140. # [13:14] <annevk> with less parse errors
  141. # [13:14] <annevk> atm
  142. # [13:15] <zcorpan> for the <!-- ---> case?
  143. # [13:15] <zcorpan> also <!-- -- -->
  144. # [13:16] <zcorpan> perhaps they shouldn't be parse errors in html5
  145. # [13:17] <zcorpan> <!------------------> looks good ;)
  146. # [13:24] <zcorpan> annevk: <!DOCTYPE >> is a doctype token with the name ">", correct?
  147. # [13:24] <annevk> <!-- opens a comment and --> closes it
  148. # [13:24] <annevk> what's in between doesn't matter as long as it's not -->
  149. # [13:25] <zcorpan> right
  150. # [13:25] <annevk> zcorpan, that might be a bug
  151. # [13:25] <zcorpan> DOCTYPE root name before state
  152. # [13:28] <annevk> It seems that's handled correctly by the parser...
  153. # [13:28] <annevk> as in, > does not give the name
  154. # [13:29] <zcorpan> ok
  155. # [13:29] <annevk> (though the specification suggests otherwise, indeed)
  156. # [13:30] <annevk> guess it makes sense to end if > is spotted
  157. # [13:30] <zcorpan> yeah
  158. # [13:30] <zcorpan> not sure about <!DOCTYPE a ">">
  159. # [13:31] <annevk> I think the spec is correct there now...
  160. # [13:31] <annevk> as in, the > is part of the non-reported identifier
  161. # [13:33] <zcorpan> wait, what about PUBLIC and SYSTEM?
  162. # [13:34] <zcorpan> are they fed through the root name states?
  163. # [13:34] <annevk> they're safely skipped over iirc
  164. # [13:35] <annevk> that's the goal anyway
  165. # [13:35] <zcorpan> ah
  166. # [13:35] <zcorpan> right
  167. # [13:36] <annevk> during the DOCTYPE state only a few tokens are created that only affect the rest of the tokenization stage
  168. # [13:36] <annevk> not the parsing stage
  169. # [13:37] <zcorpan> DOCTYPE identifier double quoted state, EOF, shouldn't it reprocess?
  170. # [13:40] <annevk> yeah
  171. # [13:40] <annevk> there are some minor glitches like that here and there still
  172. # [13:40] <annevk> I've also yet to write out entities and attlist
  173. # [13:43] <maikmerten> annevk, oh, one thing I told Chris Double and which I tried to tell howcome (by email, but no response): I recommend not using one of the released Theora alphas for in-browser usage. It makes sense to use Theora SVN trunk, as this features a completely rewritten decoder that is felt to be much safer when it comes to malformed content. There's a compatibility layer, so you don't need to worry about yet another API.
  174. # [13:46] <annevk> thanks
  175. # [13:46] <maikmerten> however, if you adapt to a slightly revised API (theoradec.h instead of theora.h) you have access to e.g. a system of postprocessing filters, which increases the perceived picture quality
  176. # [13:46] <maikmerten> http://img454.imageshack.us/my.php?image=bildschirmfoto1fx6.png <-- no postprocessing, default, old decoder will look like this
  177. # [13:47] <maikmerten> http://img454.imageshack.us/my.php?image=bildschirmfoto2xp3.png <- new decoder, with maximum postprocessing (notice how the blocky artifacts are nicely smoothed out)
  178. # [13:47] <maikmerten> meh, and yet again I spam this channel with irrelevant stuff, sorry :(
  179. # [13:48] <annevk> it's not that irrelevant I think
  180. # [13:49] <maikmerten> well, but it's far away from actual WHATWG specification work
  181. # [13:49] <zcorpan> so? :)
  182. # [13:51] <maikmerten> my point is that I assume most people here aren't thaaaat interested in codec discussion or how a particular codec exposes what functions over what API, so I should keep that topic fairly low-profile
  183. # [13:58] <hsivonen> it is hard to get notify the tokenizer about the byte stream crossing the 512 byte mark while supporting UTF-8 sequences landing across the boundary and maintaining otherwise efficient buffering
  184. # [14:02] <hsivonen> s/get //
  185. # [14:04] <annevk> why do it through the tokenizer?
  186. # [14:06] <hsivonen> to check for the requirement that the internal encoding declaration has to occur within the first 512 bytes if it does occur
  187. # [14:07] * Quits: Lachy (n=Lachlan@124-168-18-235.dyn.iinet.net.au) ("This computer has gone to sleep")
  188. # [14:07] * Quits: mpt (n=mpt@121-72-131-30.dsl.telstraclear.net) ("Leaving")
  189. # [14:07] <hsivonen> annevk: this isn't about detecting the encoding but about detecting misplaced charset metas
  190. # [14:08] <zcorpan> what about <style>/*<meta charset=utf-8>*/</style>? it will be detected but isn't an element in the parsed tree
  191. # [14:09] <annevk> oh right
  192. # [14:09] <hsivonen> zcorpan: as far as I can tell, having <style>/*<meta charset=utf-8>*/</style> after the first 512 bytes is not an error and my implementation plan doesn't cover detecting it
  193. # [14:10] <annevk> the algorithm doesn't deal with <style>, <script>, <plaintext>, etc?
  194. # [14:10] <annevk> interesting
  195. # [14:11] <hsivonen> annevk: the byte-level sniffer doesn't
  196. # [14:11] <zcorpan> hsivonen: ok
  197. # [14:11] <hsivonen> annevk: as Hixie why not :-)
  198. # [14:11] <zcorpan> because that's what current browsers are doing
  199. # [14:11] <hsivonen> zcorpan: really? I thought current browsers run the full parser twice
  200. # [14:12] <zcorpan> yeah, really
  201. # [14:12] <hsivonen> wow
  202. # [14:12] <hsivonen> very interesting
  203. # [14:12] <zcorpan> indeed :)
  204. # [14:13] <annevk> so current browsers are not reusing the tokenizer?
  205. # [14:14] <annevk> or are using the tokenizer but not using the contentmodelflag...
  206. # [14:14] <annevk> whoa
  207. # [14:14] <zcorpan> something like that
  208. # [14:14] <zcorpan> they detect meta charset in <style>
  209. # [14:14] <hsivonen> annevk: anyway, as far as I can tell, http://www.whatwg.org/specs/web-apps/current-work/#charset makes a statement about document conformance requirements about the byte placement of an attribute (where the attributeness is determined on the character stream-reading tokenizer level)
  210. # [14:14] <hsivonen> joy
  211. # [14:15] <hsivonen> I'd like to know now if I am misunderstanding requirements for conformance checkers on this point
  212. # [14:17] <annevk> when I last read that it's indeed as you say
  213. # [14:18] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  214. # [14:19] <hsivonen> so as far as I can tell, I have to make sure that both byte buffering and UTF-16 code unit buffering have a forced buffer boundary at that point so that a notification can happen between buffers
  215. # [14:20] <annevk> it only matters for ASCII compatible encodings though
  216. # [14:21] <hsivonen> that doesn't help much considering that UTF-8 is variable-length and various Asian encodings, too
  217. # [14:26] <annevk> can't you just sniff for <meta in the first 512 bytes and combine those results with the result from the tree construction?
  218. # [14:26] <hsivonen> annevk: what if there is no meta in the first 512 bytes but there is one afterwards?
  219. # [14:27] <hsivonen> annevk: I should emit an error, shouldn't I?
  220. # [14:27] <annevk> yeah
  221. # [14:27] <annevk> it wouldn't be detected
  222. # [14:27] <annevk> (well, for <meta charset> that is)
  223. # [14:29] <hsivonen> also, using the java.nio.charset stuff with reported errors *and* recovery requires a lot of work that doesn't come from the libraries by default
  224. # [14:29] <annevk> maybe you should focus on something else first?
  225. # [14:30] * annevk notes that it charset detection might change...
  226. # [14:30] <zcorpan> the 512 requirement might be dropped altogether, aiui
  227. # [14:30] <annevk> as opposed to the other bits, which should be more stable
  228. # [14:30] <zcorpan> if browser vendors find that they have to examine the entire document anyway
  229. # [14:31] <annevk> zcorpan, if the entire document is several megabytes though that doesn't seem useful
  230. # [14:31] <zcorpan> right
  231. # [14:33] <zcorpan> annevk: is namespace association dealt with after the tree construction?
  232. # [14:33] <hsivonen> annevk: perhaps. but usually when abstraction layers are violated, it is good to cover the violation points first, because if you design with clean abstractions, it is harder to punch the holes later
  233. # [14:34] <kfish> maikmerten, I'd suggest another advantage of using liboggplay (apart from being cross-platform, having good sync and being simple to program against) is that it supports Ogg Skeleton, which allows streaming from time offsets, seeking by time/chapter over HTTP etc.
  234. # [14:34] <maikmerten> oooh, right, I totally forgot that
  235. # [14:35] <hsivonen> annevk: besides, reporting and recovering from malformed byte sequences is more work anyway and is likely to stay
  236. # [14:36] <kfish> how can i tell (from a web app) if the user agent supports html5?
  237. # [14:37] <annevk> you can't
  238. # [14:37] <zcorpan> kfish: for what purpose?
  239. # [14:37] <annevk> "supporting html5" is kind of broad too
  240. # [14:37] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  241. # [14:37] <hsivonen> kfish: you should check for the features you need
  242. # [14:37] <kfish> sure ... i want to offer an html5 page, with <video>, if the browser supports that
  243. # [14:37] <zcorpan> then just place the fallback inside the <video> element
  244. # [14:38] <annevk> var v = document.createElement("video"); if (v.play) { // prolly some support }
  245. # [14:38] <annevk> zcorpan, "create an element" should do the namespace stuff
  246. # [14:38] * Quits: hendry (n=hendry@91.84.53.136) ("leaving")
  247. # [14:38] <zcorpan> annevk: ok
  248. # [14:38] <annevk> zcorpan, with a similar algorithm that's already in the XML spec
  249. # [14:38] <annevk> zcorpan, I've yet to implement it though
  250. # [14:39] <kfish> zcorpan, thanks
  251. # [14:39] <kfish> annevk, thanks
  252. # [14:40] <annevk> basically just going up the open elements array and going through the attributes for xmlns: and xmlns= magic
  253. # [14:41] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  254. # [14:43] <zcorpan> http://simon.html5.org/sandbox/html/simply-complex
  255. # [14:46] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 110 (Connection timed out))
  256. # [14:51] <annevk> hmm
  257. # [14:52] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  258. # [14:52] * annevk doesn't really understand that table to begin with
  259. # [14:53] * Joins: ROBOd (n=robod@86.34.246.154)
  260. # [14:53] <zcorpan> Gez' table is the same as my two tables placed on top of each other
  261. # [14:54] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 104 (Connection reset by peer))
  262. # [14:54] <annevk> I don't understand his
  263. # [14:54] <annevk> I would love to see these on some real site
  264. # [14:54] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  265. # [14:54] <annevk> Wikipedia for instance
  266. # [14:55] * Joins: hendry (n=hendry@91.84.53.136)
  267. # [14:59] <zcorpan> i have the periodic table with headers on 3 sides in print
  268. # [15:00] <annevk> so with headers on three sides, is <td> connected with all of them?
  269. # [15:00] <zcorpan> period on the left side (1..7), group on the top (1..18), and shells on the right (K..Q)
  270. # [15:00] * annevk thinks the unbound algorithm should be improved
  271. # [15:01] <zcorpan> yeah. that is not how gez' table works though
  272. # [15:01] <annevk> I know
  273. # [15:01] <annevk> I know how his table works, I'm not sure I understand the use case
  274. # [15:01] <hsivonen> perhaps a table is too complex if sighted users need AT to grok it
  275. # [15:01] * annevk ponders about creating some javascript that hilites headers
  276. # [15:02] <annevk> especially if you need to press ctrl+atl+5...
  277. # [15:06] <zcorpan> i also note that in my periodic system, the headers have headers
  278. # [15:07] <zcorpan> much like http://www.webelements.com/ ("Group" and "Period")
  279. # [15:10] <zcorpan> to make it read ok with the current system in html5, you'd have to write "Period 1", "Period 2" etc in each header cell
  280. # [15:11] <zcorpan> which would make the table less foreseeable for sighted users
  281. # [15:13] <annevk> does HTML5 forbid headers to have headers?
  282. # [15:13] <zcorpan> no, but the algorithm don't associate them together
  283. # [15:14] <zcorpan> only td->th
  284. # [15:14] <annevk> that should be fixable
  285. # [15:15] <zcorpan> in my printed table, one cell is split up to form two header cells
  286. # [15:15] <hsivonen> the algorithm should probably (conceptually) walk the table from the center outwards and associate outer ths as headers for inner ths
  287. # [15:16] * Joins: mpt (n=mpt@121-72-131-30.dsl.telstraclear.net)
  288. # [15:20] <hsivonen> calculating line and col numbers for malformed byte sequences is also a fun case of violating abstraction layers
  289. # [15:24] <zcorpan> http://www.radiochemistry.org/periodictable/periodic_table.jpg
  290. # [15:26] <zcorpan> how do you mark up that?
  291. # [15:30] <zcorpan> would each cell contain a DL that lists all the properties of the element?
  292. # [15:31] <Philip`> Would you actually want to mark it up, rather than stepping back and working out what data you want to present to the user, and how you could better present it without relying on complex visual associations and patterns?
  293. # [15:31] <zcorpan> dunno
  294. # [15:32] <zcorpan> it might perhaps be more like a graph, so if you wanted it in that form, you'd use SVG
  295. # [15:33] <Philip`> If someone wanted to find information about a specific element, I would expect it'd be much easier if they could type in the name and get the data back
  296. # [15:33] <Philip`> (i.e. using an input box on a form, rather than a table)
  297. # [15:35] <zcorpan> yeah
  298. # [15:37] <zcorpan> or use a table, where each cell just contains the symbol (and/or full name) that is a link to a page that lists the properties of that element
  299. # [15:37] * Joins: BenWard (i=BenWard@nat/yahoo/x-fb3d441d34631bae)
  300. # [15:44] <zcorpan> annevk: it seems like whitespace outside the root element is a parse error in xml5
  301. # [15:44] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 110 (Connection timed out))
  302. # [15:50] * Joins: jcgregorio (i=chatzill@nat/ibm/x-26dfc76398c9963c)
  303. # [15:51] <annevk> hmm
  304. # [15:57] <annevk> doing some simple table iterating isn't that hard it seems
  305. # [15:58] <annevk> just start at a cell and go in some direction :)
  306. # [16:00] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  307. # [16:17] * Joins: yod (n=ot@cpe-72-224-179-1.maine.res.rr.com)
  308. # [16:19] <annevk> http://www.andybudd.com/archives/2007/06/rebooted/ "although I still maintain that re-introducing the font tag is a VERY BAD IDEA, and sends out all the wrong signals"
  309. # [16:20] * annevk was on stage defending the font tag :)
  310. # [16:20] <annevk> never thought I'd do that a couple of years back
  311. # [16:24] <gsnedders> I still have my doubts about it
  312. # [16:24] <annevk> oh, me too
  313. # [16:24] <annevk> although I don't really see a viable alternative
  314. # [16:24] <annevk> <span style=font-family:verdana> is worse
  315. # [16:24] <gsnedders> what were the reasons for not using <span>?
  316. # [16:25] <annevk> what are the reasons for using span?
  317. # [16:25] <gsnedders> some editors (like iWeb) already use it, we get screamed at less, etc.
  318. # [16:25] <annevk> and some don't
  319. # [16:26] <annevk> using <span style> over <font> for political reasons seems bad
  320. # [16:26] <gsnedders> agreed
  321. # [16:27] <annevk> <font> also seems easier to parse than <span style=> given that <span style=> has way more use cases
  322. # [16:27] <krijnh> They both seem bad
  323. # [16:27] <annevk> well yeah, but there's no semantic editor that's actually used so far
  324. # [16:28] <krijnh> Mine is :]
  325. # [16:39] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  326. # [16:44] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  327. # [16:55] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  328. # [17:11] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  329. # [17:19] * Quits: hendry (n=hendry@91.84.53.136) ("leaving")
  330. # [17:26] * Joins: hendry (n=hendry@91.84.53.136)
  331. # [17:36] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  332. # [17:47] * Joins: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net)
  333. # [18:00] * Quits: ianloic (n=ian@71.5.56.162.ptr.us.xo.net) (Client Quit)
  334. # [18:11] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  335. # [18:20] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  336. # [18:23] <zcorpan> an <img> that is display:none won't request the image, right?
  337. # [18:25] <annevk> I believe <img> is always fetched
  338. # [18:25] <zcorpan> really?
  339. # [18:25] <annevk> (for instance, var i = new Image(); i.src = "blah")
  340. # [18:25] <zcorpan> oh sure, but that's a different case from <img> in the markup, no?
  341. # [18:26] <annevk> it's the same <img>
  342. # [18:26] <zcorpan> hrm
  343. # [18:26] <annevk> though I suppose Opera may have not loaded display:none <img> at some point...
  344. # [18:28] <zcorpan> data:text/html,<img style=display:none src=javascript:alert('foo')>
  345. # [18:28] <zcorpan> doesn't alert in opera (but removing display:none does)
  346. # [18:31] <zcorpan> what is a simple way to test it in other browsers?
  347. # [18:32] <annevk> src=img onload=fires?
  348. # [18:32] <hsivonen> has anyone tested what happens when C1 range Unicode characters are document.written?
  349. # [18:33] <hsivonen> do they stay intact or are they turned into the Unicode characters that occupy the C1 byte range in Windows-1252?
  350. # [18:34] <zcorpan> data:text/html,<img style=display:none src=data:, onerror=alert('foo')>
  351. # [18:34] <zcorpan> hm, so firefox does load
  352. # [18:35] <zcorpan> so does ie7
  353. # [18:35] * Joins: aroben (i=adamrobe@nat/apple/x-0cf9c468309f8250)
  354. # [18:37] <annevk> it's funny how the table examples given use <td><b>...
  355. # [18:43] * Quits: BenWard (i=BenWard@nat/yahoo/x-fb3d441d34631bae) ("Fades out again…")
  356. # [18:49] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  357. # [19:07] <zcorpan> i've figured something out
  358. # [19:07] <zcorpan> if there is one thing about web design that is future proof, it's quirks mode
  359. # [19:09] * Joins: tantek (n=tantek@corp.technorati.com)
  360. # [19:18] * Joins: Ducki (n=Alex@dialin-145-254-186-170.pools.arcor-ip.net)
  361. # [19:18] * Quits: Ducki (n=Alex@dialin-145-254-186-170.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  362. # [19:19] <hsivonen> zcorpan: XHTML!
  363. # [19:19] <zcorpan> ha
  364. # [19:19] <zcorpan> that's just a middle-step to XML+XSLT anyway, isn't it ;)
  365. # [19:20] <zcorpan> (XSLT converting it back to HTML)
  366. # [19:25] * Joins: dev0 (i=Tobias@unaffiliated/icefox0)
  367. # [19:26] <hsivonen> annevk: FWIW, Python doesn't come with a UTF-32 codec by default, either
  368. # [19:26] * Joins: weinigLap (n=weinig@17.203.15.158)
  369. # [19:26] <hsivonen> hard to generate test data :-)
  370. # [19:31] <othermaciej> UTF-32 is so simple to transcode to UTF-16 or UTF-8, I'm surprised any reasonably complete text system would be missing the codec
  371. # [19:32] <hsivonen> othermaciej: well, both Sun's/Apple's JDK and Python are missing it
  372. # [19:33] <hsivonen> ICU4J has an optional jar that adds support to Java 1.4 or later
  373. # [19:49] * Joins: KevinMarks (i=KevinMar@nat/google/x-c68d587cc08b3ab9)
  374. # [20:00] * Joins: kingryan (n=kingryan@corp.technorati.com)
  375. # [20:07] <zcorpan> forums.whatwg.org won't load for me
  376. # [20:08] * Joins: kingryan_ (n=kingryan@corp.technorati.com)
  377. # [20:11] * Joins: markp (n=markp@207.47.10.130.static.nextweb.net)
  378. # [20:15] * Philip` wonders if it's possible in JS to evaluate a string in a clean scope, so it can't access the variables that are visible to the evaluator, except for a set of explicitly shared variables, like with Python's eval(string, globals, locals)
  379. # [20:23] * Quits: kingryan (n=kingryan@corp.technorati.com) (Read error: 110 (Connection timed out))
  380. # [20:29] * Joins: SavageX (n=maikmert@T73f2.t.pppool.de)
  381. # [20:36] * Quits: kingryan_ (n=kingryan@corp.technorati.com)
  382. # [20:46] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  383. # [20:47] * Quits: maikmerten (n=maikmert@L8a95.l.pppool.de) (Connection timed out)
  384. # [20:48] * Joins: kingryan (n=kingryan@corp.technorati.com)
  385. # [21:28] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  386. # [21:29] * Quits: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
  387. # [21:56] * Quits: SavageX (n=maikmert@T73f2.t.pppool.de) ("Leaving")
  388. # [21:57] * Quits: dev0 (i=Tobias@unaffiliated/icefox0) ("dev0 has no reason")
  389. # [21:59] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  390. # [22:10] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  391. # [22:28] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 104 (Connection reset by peer))
  392. # [22:29] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  393. # [22:57] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) (Read error: 104 (Connection reset by peer))
  394. # [22:58] * Joins: KevinMarks (i=KevinMar@nat/google/x-272fec7cabddbcca)
  395. # [23:01] * Quits: jcgregorio (i=chatzill@nat/ibm/x-26dfc76398c9963c) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007040314]")
  396. # [23:05] * othermaciej is now known as om_out
  397. # [23:10] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  398. # [23:24] * Quits: zcorpan (n=zcorpan@84-216-41-162.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  399. # [23:24] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  400. # [23:24] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  401. # [23:25] <Hixie> annevk: yt?
  402. # [23:26] <Hixie> annevk: http://bugs.webkit.org/show_bug.cgi?id=8872 might be relevant for you
  403. # [23:29] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  404. # [23:30] * Quits: jruderman (n=jruderma@corp-242.mountainview.mozilla.com) (Client Quit)
  405. # [23:44] * Joins: weinigLap_ (n=weinig@17.203.15.158)
  406. # [23:45] * Joins: jruderman (n=jruderma@corp-242.mountainview.mozilla.com)
  407. # [23:45] * Quits: weinigLap (n=weinig@17.203.15.158) (Read error: 104 (Connection reset by peer))
  408. # [23:48] * Joins: KevinMarks (i=KevinMar@nat/google/x-76b304d390d131b7)
  409. # [23:51] * Quits: hendry (n=hendry@91.84.53.136) ("nn")
  410. # [23:53] * Joins: zcorpan (n=zcorpan@84-216-40-36.sprayadsl.telenor.se)
  411. # [23:53] * Quits: tantek (n=tantek@corp.technorati.com) (Read error: 104 (Connection reset by peer))
  412. # [23:53] * Joins: tantek (n=tantek@corp.technorati.com)
  413. # [23:53] * Quits: psa (n=yomode@posom.com) (Remote closed the connection)
  414. # Session Close: Tue Jun 05 00:00:00 2007

The end :)