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

Options:

  1. # Session Start: Tue Feb 12 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:00] <Hixie> hsivonen: so that's one way you could justify mismatched declarations as being an error
  4. # [00:02] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  5. # [00:04] * Joins: roc (n=roc@202.0.36.64)
  6. # [00:05] <hsivonen> Hixie: ok. thanks. It could be clearer, though.
  7. # [00:06] <Hixie> yeah
  8. # [00:08] <webben> are there any test-cases for cross-browser syntax for embedding Java applets without applet that don't rely on conditional comments?
  9. # [00:09] <webben> (or alternately, any good description of why the draft currently obsoletes applet?)
  10. # [00:09] <annevk> we need someone to figure out how <applet> works, last i checked
  11. # [00:10] <Philip`> The problem with <applet> is that it's a vendor-prefixed name
  12. # [00:10] <hsivonen> hah
  13. # [00:10] * webben isn't sure what that means
  14. # [00:10] <Hixie> that's funny
  15. # [00:12] <webben> not having worked out how something works doesn't sound like a rationale for obsoleting it.
  16. # [00:12] <annevk> html5 isn't done
  17. # [00:13] <webben> I don't really see how it's un-doneness is relevant. People are being asked to look at a series of draft documents.
  18. # [00:13] <annevk> can't help you there
  19. # [00:14] <webben> if something is simply un-thought-out, it's better to mark it as such
  20. # [00:14] <hsivonen> annevk: is there a reason to expect that how <applet> really works is significantly more complex than what Sun documents?
  21. # [00:14] <Philip`> It might be helpful to add a placeholder section that just says we don't quite know what should be done yet, to avoid misleading people that it's been intentionally removed
  22. # [00:14] <Philip`> Oh, like what webben said
  23. # [00:15] <webben> or alternately, don't publish official drafts
  24. # [00:15] * Joins: heycam` (n=cam@b4F38.static.pacific.net.au)
  25. # [00:15] <annevk> webben, you're overreacting
  26. # [00:16] <annevk> hsivonen, dunno
  27. # [00:16] <Hixie> i have no intention of adding <applet> to the spec, btw
  28. # [00:16] <Hixie> <object> should be enough for any proprietary binary embedding, whether it's activex, java, sliverlight, or whatever.
  29. # [00:17] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  30. # [00:17] <webben> you mean object plus conditional comments?
  31. # [00:17] <annevk> conditional comments are not part of html5
  32. # [00:18] <gsnedders> if anyone wants to do something minor to help the spec-gen clone, can they get Py html5lib's dom treebuilder/walker to work with other dom implementations (i.e., not minidom, I need pxdom). I looked through it very quickly earlier and it really looks like next to no work.
  33. # [00:18] <Hixie> why conditional comments?
  34. # [00:18] <webben> Hixie: to get markup that works in IE too?
  35. # [00:18] <gsnedders> Also, on the subject of the spec-gen clone, I hope to get something working over my half-term (this Wednesday to Sunday).
  36. # [00:19] <Hixie> webben: IE doesn't support java in <object>?
  37. # [00:20] <hsivonen> Hixie: what's in the spec now doesn't cover activex
  38. # [00:20] <hsivonen> Hixie: by the time HTML5 is done, Java will be non-proprietary
  39. # [00:20] <webben> Hixie: AFAIK, you need conditional comments if you want both non-IE and IE to work with OBJECT + Java. I was hoping the idea of deprecating APPLET was prefaced on test cases showing that somehow this wasn't necessary.
  40. # [00:21] <Hixie> hsivonen: in the same way that open office is non-proprietary?
  41. # [00:21] <hsivonen> Hixie: in the way that you can get a Free Software impl
  42. # [00:21] <Hixie> webben: no, the obsoletion of applet is based purely on my prejudices.
  43. # [00:22] <Hixie> hsivonen: "proprietary" may be hte wrong term here.
  44. # [00:22] * Philip` noticed recently that the spec changed from section numbers like "1.2.3." to "1.2.3", and wonders if that's an artifact of the spec-gen script
  45. # [00:22] <gsnedders> webben: HTML 5 is being developed from a clean slate, so everything has made it's way in it through use cases being presented, and not the other way around
  46. # [00:22] <gsnedders> Philip`: yeah, that's all spec-gen
  47. # [00:22] <Hixie> Philip`: no idea, i didn't even notice that
  48. # [00:22] <gsnedders> Hixie: I've seen that elsewhere too
  49. # [00:23] <Philip`> http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000397.html
  50. # [00:23] <gsnedders> <http://www.w3.org/Tools/HTML-XML-utils/> — 4.4 update
  51. # [00:23] <Hixie> wow, i wonder what caused that
  52. # [00:23] <gsnedders> (a lot of the spec-gen is just calling those utils, all of which parse the HTML themselves then serialise it, which makes it that dog slow)
  53. # [00:23] <annevk> Philip`, Bert changed his tool, yes
  54. # [00:24] <hsivonen> what parser does the script use?
  55. # [00:24] <webben> The drafts don't dispute that applet has a /use/.
  56. # [00:24] <gsnedders> num(1), specially
  57. # [00:24] <webben> They claim it's unnecessary for its use.
  58. # [00:24] <Philip`> http://lists.w3.org/Archives/Public/www-html-editor/2005JulSep/0003.html - the non-dot form is apparently an ISO standard
  59. # [00:24] <gsnedders> hsivonen: very naïve ones. download the source and look, it's really basic custom stuff
  60. # [00:24] <webben> "The following elements are not included because they have not been used often, created confusion or can be handled by other elements: .... applet has been obsoleted in favor of object."
  61. # [00:24] <jgraham> gsnedders: Are you really sure you want to use DOM? :)
  62. # [00:25] <gsnedders> jgraham: yes.
  63. # [00:25] <jgraham> why?
  64. # [00:25] <Hixie> webben: the only reason <applet> is not in html5 is my own personal prejudice against Java and my desire to not special-case one particular extension language.
  65. # [00:25] <webben> HTML5 already does special-case JS.
  66. # [00:26] <Hixie> webben: i would personally be quite happy to not support Java at all.
  67. # [00:26] <Hixie> webben: JS isn't an extension language for HTML, it's its scripting language.
  68. # [00:26] <Hixie> java is at the level of flash or silverlight
  69. # [00:26] <gsnedders> jgraham: all the decent XPath impls. require it, and not using XPath means recursing through the document manually, while changing it, even more times than otherwise needed
  70. # [00:26] <gsnedders> (by all the decent XPath impls., I basically mean WebPath)
  71. # [00:26] <webben> oh, I'm not sure "extension" is quite the word for such things.
  72. # [00:27] <jgraham> (btw I will be happy to support pyxdom or whatever in html5lib but I can't promise any time to look at it soon)
  73. # [00:27] <hsivonen> I have a strong prejudice against Java *applets*, but I still think that Java via <applet> is better than Java via <object>
  74. # [00:27] <webben> JS seems more like an "extension" of HTML.
  75. # [00:27] <jgraham> gsnedders: lxml
  76. # [00:27] <Hixie> webben: ok, well, whatever you want to call them :-)
  77. # [00:27] <gsnedders> jgraham: needs to be compiled to be used. I'd really like it to work without compiling anything.
  78. # [00:27] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Remote closed the connection)
  79. # [00:27] <hsivonen> Java applets might have been great if AWT didn't suck so incredibly badly
  80. # [00:28] <jgraham> Any reason for that requirement? easy_install lxml isn't so hard...
  81. # [00:28] <gsnedders> and there was some other reason why lxml wouldn't do.
  82. # [00:28] <hsivonen> webben: please raise the <applet> issue on public-html
  83. # [00:28] <hsivonen> nn
  84. # [00:28] <gsnedders> jgraham: I can't actually get it working locally.
  85. # [00:28] <webben> hsivonen: I'm not a member of the WG. (And I can't join either.)
  86. # [00:28] <gsnedders> (but that wasn't the reason, I admittedly didn't try hard)
  87. # [00:28] <gsnedders> webben: s/public-html/whatwg or public-html-comments/
  88. # [00:29] <webben> gsnedders: Yep, not at all clear to me I can safely post there either.
  89. # [00:29] <gsnedders> why?
  90. # [00:29] * Quits: heycam|sydney (n=cam@b4F38.static.pacific.net.au) (Read error: 110 (Connection timed out))
  91. # [00:29] <webben> Indeed, just chatting here is a bit dodgy.
  92. # [00:29] <Hixie> webben: feel free to e-mail me directly ian@hixie.ch
  93. # [00:29] <Hixie> webben: i can keep any feedback confidential
  94. # [00:30] <jgraham> (actually if specgen requires comments before the html element our current lxml treebuilder won't work so well. Although it could be fixed I think)
  95. # [00:31] <jgraham> webben: that sucks (not being able to post feedback)
  96. # [00:31] <webben> gsnedders: Basically because of the way the W3C patent policy infects pretty much everything employees of member companies do.
  97. # [00:32] <gsnedders> jgraham: you should see what the real spec-gen does. it doesn't actually really parse it then serialise it, it just spits out everything until it finds something it wants to add/remove/change
  98. # [00:32] <Hixie> like i said, feel free to send me unofficial feedback straight to ian@hixie.ch
  99. # [00:32] <Hixie> it will never be made public
  100. # [00:32] <jgraham> webben: Can you say who your employer is?
  101. # [00:33] * jgraham is just curious, it's not important
  102. # [00:33] * gsnedders hasn't set about trying to break the spec-gen (because he don't have access), but it could be easily done
  103. # [00:33] <annevk> http://benjaminhawkeslewis.com/ suggests Y!
  104. # [00:34] <webben> that information is still accurate
  105. # [00:34] * gsnedders wonders where he's seen webben before. rss-public? uf-*?
  106. # [00:34] <roc> maybe not for long, depending on how the takeover struggle goes :-)
  107. # [00:34] * jgraham discovers that reading the specs properly in case the insane behaviour of one's code is actually correct and not a bug is a good idea
  108. # [00:34] <webben> roc: That I definitely can't comment on ;)
  109. # [00:35] <roc> :-)
  110. # [00:35] <webben> gsnedders: Oh, I used to post to whatwg quite a lot and often lurk/grumble in here.
  111. # [00:35] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  112. # [00:35] <gsnedders> ah
  113. # [00:36] <webben> (just to be 100% clear, nothing I say is an official Y! position, or a semi-official Y! position, or likely to be based on even talking to other Y! employees)
  114. # [00:37] <webben> gsnedders: I do post on the uf- mailing lists though, along with a couple other Y! folk.
  115. # [00:38] <gsnedders> webben: ah. I was sure I'd seen you elsewhere. I rarely post on the uf- lists, though I read quite a bit
  116. # [00:39] <Philip`> http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3C!doctype%20html%3Efoo%3Chtml%20x%3E - why is that a parse error?
  117. # [00:39] <Philip`> The <html> shouldn't hit the "If this start tag token was not the first start tag token, then it is a parse error." case since it is the first start tag token
  118. # [00:40] <gsnedders> jgraham: if I allow other dom modules to be used for the dom treebuilder/walker, I assume I should just add a second param (like on etree), and have it default to minidom for backwards compat.?
  119. # [00:41] <gsnedders> Should I just commit it as long as it doesn't break anything?
  120. # [00:41] <Philip`> http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/html-after-chars.html complains too, and I think it shouldn't
  121. # [00:42] <gsnedders> (someone who isn't jgraham who knows about html5lib policy can answer too)
  122. # [00:42] <jgraham> gsnedders: Exactly
  123. # [00:42] <jgraham> I think I even wrote in the docs that that might happen in the future
  124. # [00:42] <gsnedders> yeah, you did
  125. # [00:42] <annevk> Philip`, with implied start tag tokens it's not
  126. # [00:43] <jgraham> gsnedders: You should add the new dom thing to the tests as well. Then check they all pass :)
  127. # [00:43] <gsnedders> jgraham: add in what way?
  128. # [00:44] <gsnedders> jgraham: add param for mindom?
  129. # [00:44] <jgraham> In the tokenizer tests file we run all the tests on every DOM implementation we claim to support, if the user has them installed
  130. # [00:44] <Philip`> annevk: That would be annoying for me, since implied tokens are handled in the same way as reprocess-the-current-token tokens, and the <html> gets reprocessed a couple of times before it's tested for firstness
  131. # [00:45] <Philip`> and the spec isn't clear enough about what it means there, so I'll stick with my interpretation because it's easy
  132. # [00:45] <annevk> either way there's a parse error there
  133. # [00:45] <annevk> i guess it's ok if you collapse them, but Hixie should clarify that
  134. # [00:45] <Philip`> and http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/message/%3C251FD893-EFFA-4A53-9015-21349E494B74%40iki.fi%3E should allow it to work better in the future anyway
  135. # [00:45] <Philip`> annevk: I'm not sure why there's a parse error either way
  136. # [00:46] <gsnedders> jgraham: where?
  137. # [00:46] <annevk> Philip`, oh wait... hmm
  138. # [00:46] <jgraham> gsnedders:
  139. # [00:46] <jgraham> try:
  140. # [00:46] <jgraham> import pyxdom
  141. # [00:46] <jgraham> treeTypes["pyxdom"] = treebuilders.getTreeBuilder("dom", "pyxdom")
  142. # [00:46] <jgraham> except ImportError:
  143. # [00:46] <jgraham> pass
  144. # [00:46] <annevk> Philip`, there should be a parse error there though
  145. # [00:46] <gsnedders> jgraham: what file?
  146. # [00:47] <jgraham> in python/tests/test_parser.py
  147. # [00:47] <Philip`> annevk: Do you mean there should be one according to the spec, or there should be one according to common sense?
  148. # [00:47] * gsnedders will probably have a go tomorrow
  149. # [00:47] <annevk> Philip`, currently only the latter I guess
  150. # [00:47] * Philip` wonders if he should bother emailing about it
  151. # [00:48] * Joins: eseidel (n=eseidel@nat/google/x-9a23cb012dbe3d73)
  152. # [00:49] <annevk> it's also easier to handle this case if you turn insertion modes into phases
  153. # [00:49] * Philip` does that in his implementation
  154. # [00:49] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  155. # [00:50] <annevk> in that you can never end up with <html> in the in body phase
  156. # [00:50] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  157. # [00:51] * Quits: jwalden (n=waldo@STRATTON-FOUR-O-EIGHT.MIT.EDU) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  158. # [00:55] * Quits: tndH (i=Rob@adsl-77-86-99-71.karoo.KCOM.COM) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  159. # [00:59] * Philip` continues hating things that require more than one token at a time
  160. # [01:03] * SadEagle is now known as AwayEagle
  161. # [01:10] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  162. # [01:29] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  163. # [01:37] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  164. # [01:38] * Hixie wonders whether to make Storage.setItem() throw or not after all
  165. # [02:08] * Quits: aroben (n=aroben@unaffiliated/aroben)
  166. # [02:11] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  167. # [02:26] * Quits: webben (n=benh@82.152.229.45) (Read error: 110 (Connection timed out))
  168. # [02:45] * Quits: eseidel (n=eseidel@nat/google/x-9a23cb012dbe3d73)
  169. # [02:50] <Hixie> http://www.hixie.ch/specs/dom/messages/0.9 <-- proposal for a spec for sending messages between end points, including sending end points along
  170. # [02:55] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  171. # [02:57] * Quits: kingryan (n=ryan@dsl092-219-050.sfo1.dsl.speakeasy.net) (Read error: 113 (No route to host))
  172. # [03:04] <roc> uh oh
  173. # [03:04] <roc> you've invented the pi calculus!
  174. # [03:04] <Hixie> oops
  175. # [03:04] <Hixie> i didn't mean to invent anything!
  176. # [03:07] <Hixie> oops, behind schedule. gotta go. back in a bit.
  177. # [03:12] * Joins: jwalden (n=waldo@STRATTON-SEVEN-FOURTY-SIX.MIT.EDU)
  178. # [03:18] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  179. # [03:46] * Joins: MikeSmith (n=MikeSmit@eM60-254-224-251.pool.emnet.ne.jp)
  180. # [04:01] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  181. # [04:03] <AwayEagle> roc: not enough greek letters
  182. # [04:03] * AwayEagle is now known as SadEagle
  183. # [04:09] * Quits: MikeSmith (n=MikeSmit@eM60-254-224-251.pool.emnet.ne.jp) ("Less talk, more pimp walk.")
  184. # [04:20] * Quits: weinig (n=weinig@17.203.15.140)
  185. # [04:55] * Quits: jwalden (n=waldo@STRATTON-SEVEN-FOURTY-SIX.MIT.EDU) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  186. # [05:06] <inimino> what's the reason for target=_blank not being conforming in the current draft?
  187. # [05:07] <inimino> is it to discourage people from trying to open new windows like that?
  188. # [05:10] * Joins: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU)
  189. # [05:12] <inimino> because the consensus in Web-developer-land seems to be that you should use JavaScript to add them back in...
  190. # [05:13] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  191. # [05:28] <Hixie> using javascript to add them back in is just as invalid as having them in in thefirst place
  192. # [05:28] <Hixie> the correct thing to do is to not set target="", and let the user decide on his own what to do with links
  193. # [05:29] <Hixie> inimino: ^
  194. # [05:29] <SadEagle> that sounds awfully polite for a website to do
  195. # [05:30] <Hixie> shocking, i know
  196. # [05:31] <inimino> Hixie: I agree, I'm just seeing people using the JavaScript approach anyway and I'm wondering if that's actually worse than just allowing it
  197. # [05:32] <Hixie> why would it be worse?
  198. # [05:34] <inimino> I was going to say it's harder for the user to configure how it's handled, but that's probably not true
  199. # [05:35] <inimino> though there are people using window.open(), which seems like it might be less configurable
  200. # [05:36] * Joins: MikeSmith (n=MikeSmit@dhcp-246-201.mag.keio.ac.jp)
  201. # [05:36] <Hixie> it's all the same code in the browser in the end
  202. # [05:36] <inimino> right
  203. # [05:37] <inimino> too bad people validate the markup and not the DOM ;-)
  204. # [05:37] <Hixie> yeah
  205. # [05:38] <Hixie> would be nice for there to be scripting-aware validators
  206. # [05:38] <inimino> yeah
  207. # [05:41] <MikeSmith> news about a new Webkit-based browser for mobile devices
  208. # [05:41] <MikeSmith> http://torchmobile.com/press/
  209. # [05:42] <MikeSmith> Iris Browser
  210. # [05:42] <MikeSmith> George Staikos's company
  211. # [05:43] <MikeSmith> product page mentions HTML5 and canvas
  212. # [05:43] <MikeSmith> http://torchmobile.com/products/
  213. # [05:43] <SadEagle> I don't think people involved in QtWebKit want to mention canvas :-)
  214. # [05:47] <MikeSmith> SadEagle - why's that? implementation of canvas on Qt port not work so good?
  215. # [05:48] <SadEagle> MikeSmith: last I checked, "not so good" would be quite an understatement.
  216. # [05:50] <MikeSmith> damn. I want me some canvas on mobile
  217. # [05:55] <SadEagle> may be someone can make a khtml4.0.1 build of konqueror/embedded :-)
  218. # [05:58] <SadEagle> I am sure it works pretty well. And the basics of canvas will work, too, but not things like arcs and shadows.
  219. # [06:03] * Quits: roc (n=roc@202.0.36.64)
  220. # [06:20] * Quits: SadEagle (n=maksim@kde/orlovich) ("(good night)")
  221. # [06:24] <Hixie> so it ironically sucks that we now have multiple implementations of postMessage()
  222. # [06:24] <Hixie> as the ideal way of fixing some of the problems with it would involve minor (but incompatible) changes to how it works
  223. # [06:25] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  224. # [06:26] <Hixie> i don't suppose adam barth is here?
  225. # [06:26] <Hixie> jwalden: i assume we consider it too late to dramatically change postMessage() at this point?
  226. # [06:27] <jwalden> Hixie: depends on what "dramatically" means; adding the extra args suggested for better targeting would be simple enough, createMessageReceiver might be harder, reply() would be easy, I think
  227. # [06:28] <Hixie> well my ideal solution would be to change postMessage() from what it is now to being something that creates two endpoints as defined here: http://hixie.ch/specs/dom/messages/0.9
  228. # [06:28] <Hixie> jwalden: which solves all the problems neatly
  229. # [06:28] <Hixie> but i understand if that's too drastic
  230. # [06:31] <Hixie> i'm tempted to say that we should solve these problems by just waiting til we introduce end points
  231. # [06:31] <jwalden> sec, fighting fire on a tinderbox
  232. # [06:31] <Hixie> hehe
  233. # [06:32] <Hixie> then the solution would be, you postMessage() a hello, then the other side checks the origin and if it likes it, postMessage()s you an ack with an endpoint, and then you check the origin yourself, and if you like it, you use the end points to communicate
  234. # [06:37] <jwalden> so, my first reaction is this interface is waaay too complicated
  235. # [06:41] <jwalden> second, the whole numbering thing just confuses me
  236. # [06:41] <jwalden> and I've implemented Unix pipes before in a toy kernel
  237. # [06:42] <jwalden> I don't think you want to bring the pipe model into the picture here, to be honest
  238. # [06:44] <jwalden> I think there's far more potential for confusion with this API than with one in which it's plain and simple message-passing, perhaps with builtin filtering mechanisms at both ends
  239. # [06:49] <jwalden> and in the end, yes, I'm pretty sure this would be too drastic not just for Mozilla but for Opera and likely WebKit as well
  240. # [06:51] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  241. # [07:02] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  242. # [07:34] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  243. # [07:38] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  244. # [07:44] * Joins: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com)
  245. # [07:45] * Quits: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com) (Client Quit)
  246. # [07:46] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  247. # [07:52] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
  248. # [08:06] * Quits: heycam` (n=cam@b4F38.static.pacific.net.au) ("bye")
  249. # [08:08] <Hixie> jwalden: yeah i figured it would be too much change at this stage
  250. # [08:09] <Hixie> jwalden: the real question is whether it's a bad idea to use this on the long term as a solution for the issues raised
  251. # [08:09] <Hixie> jwalden: (i'm not sure what's complicated about the proposal, are we talking about the same thing? this is a pretty trivial api)
  252. # [08:14] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  253. # [08:14] * Joins: heycam|sydney (n=cam@b4F38.static.pacific.net.au)
  254. # [08:15] * Quits: heycam|sydney (n=cam@b4F38.static.pacific.net.au) (Client Quit)
  255. # [08:22] * Joins: roc_ (n=roc@121-72-32-151.dsl.telstraclear.net)
  256. # [08:28] <webben_> Hixie: re target, I'd tend to agree that websites should let users open links as they want, although sometimes you'd want to open a new browsing context to avoid losing application state (i.e. don't lose the users data opening a link in a multipage tax form). I think there are at least three advantages to target over window.open: it's declarative so you can easily make UI to distinguish such links (iCab does IIRC), it's simpler to author, and if
  257. # [08:29] <webben_> The biggest argument against target in particular (as opposed to against opening new windows in general) is that it shifts application behavior into a document markup layer, but HTML5 does so much of that it hardly seems like a relevant argument.
  258. # [08:29] * Quits: gavin_ (n=gavin@firefox/developer/gavin)
  259. # [08:32] <jeremyb> also, if i have a legit small popup open and something in the popup or an external app triggers a new page open i want the new tab to be on the main win not the popup. (fe, media player)
  260. # [08:33] <jeremyb> so maybe allow specifying that a window isn't available for new tabs unless explicitly requested by user
  261. # [08:33] <webben_> I guess it's worth remembering that plenty of content will continue to be pulled in via iframe, and need target="_top" if it wants to transition the user away from the host page.
  262. # [08:33] <jeremyb> (no idea if this is already covered by a spec but i've been bitten by it a few times recently with different sites)
  263. # [08:34] <webben_> target's horrible and basically bad practice, but it seems to be useful in certain limited but real circumstances
  264. # [08:34] * jeremyb scratches head
  265. # [08:34] <jeremyb> you need to use target=_top for an iframe?
  266. # [08:34] * jeremyb makes testcase
  267. # [08:34] <webben_> I think if you have a form in the iframe you do.
  268. # [08:34] <webben_> (at least)
  269. # [08:35] <webben_> it came up in #javascript the other day for someone making a facebook app
  270. # [08:35] * jeremyb sees not any reason why a form would make a diff
  271. # [08:35] * Quits: MikeSmith (n=MikeSmit@dhcp-246-201.mag.keio.ac.jp) ("Less talk, more pimp walk.")
  272. # [08:35] <webben_> That's why I say "at least".
  273. # [08:37] * Joins: gavins (n=gavin@firefox/developer/gavin)
  274. # [08:37] * gavins is now known as gavin_
  275. # [08:38] <webben_> it might be interesting to see if UAs could detect when state is being stored or when they're in a frame/popup context, and use that to determine whether to obey the command to open a new window
  276. # [08:39] <webben_> yep, a quick test shows it applies to A as well as FORM.
  277. # [08:46] <jeremyb> yup, webben_'s right
  278. # [08:46] <jeremyb> data:text/html,<!doctype html><p>lskfjlakj-lskjf</p> <iframe src="data:text/html,<a%2520href=%2522http://www.google.com%2522>lksjflkj</a>"></iframe>
  279. # [09:01] <webben_> ah looks like the current draft actually allows for _top etc: 'The base element can now have a target attribute as well mainly for consistency with the a element and because it was already widely supported. Also, the target attribute for the a and area elements is no longer deprecated, as it is useful in Web applications, for example in conjunction with iframe.'
  280. # [09:01] <webben_> http://www.w3.org/TR/html5-diff/#new-attributes
  281. # [09:10] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  282. # [09:32] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  283. # [09:37] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  284. # [09:50] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  285. # [09:56] * Joins: ROBOd (n=robod@89.122.216.38)
  286. # [10:03] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  287. # [10:11] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  288. # [10:12] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  289. # [10:13] * Joins: webben (n=benh@149.254.192.192)
  290. # [10:19] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  291. # [10:23] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  292. # [10:25] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Client Quit)
  293. # [10:26] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  294. # [10:30] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  295. # [10:36] * Quits: webben (n=benh@149.254.192.192)
  296. # [10:36] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  297. # [10:36] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  298. # [10:36] * Joins: webben (n=benh@149.254.192.192)
  299. # [10:37] * Quits: webben (n=benh@149.254.192.192) (Client Quit)
  300. # [10:38] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  301. # [10:40] * Joins: webben (n=benh@149.254.192.192)
  302. # [10:45] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("Leaving")
  303. # [10:46] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  304. # [10:46] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  305. # [10:46] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  306. # [10:47] * Joins: mpt (n=mpt@222-155-5-10.jetstream.xtra.co.nz)
  307. # [10:55] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  308. # [11:01] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  309. # [11:03] * Joins: webben_ (n=benh@nat/yahoo/x-9f6bc6e033d741d3)
  310. # [11:15] * Philip` sees that http://www.angelfire.com/tx/rangerexes/heritage.htm really doesn't work very well in Opera (9.2 or 9.5)
  311. # [11:16] <annevk> <table> :(
  312. # [11:16] <annevk> oh, and it's not centered in IE
  313. # [11:19] <annevk> so Firefox renders everything before <table>
  314. # [11:20] <annevk> but it's still centered then
  315. # [11:21] * Quits: webben (n=benh@149.254.192.192) (Read error: 113 (No route to host))
  316. # [11:36] * MacDome is now known as MacDomeSleep
  317. # [11:45] * Joins: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp)
  318. # [11:58] * Joins: MikeSmith (n=MikeSmit@eM60-254-244-76.pool.emnet.ne.jp)
  319. # [12:02] * Joins: mpt_ (n=mpt@222-155-2-153.jetstream.xtra.co.nz)
  320. # [12:13] * Quits: mpt (n=mpt@222-155-5-10.jetstream.xtra.co.nz) (Read error: 110 (Connection timed out))
  321. # [12:20] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  322. # [12:25] * Quits: mpt_ (n=mpt@222-155-2-153.jetstream.xtra.co.nz) (Read error: 110 (Connection timed out))
  323. # [12:59] * Philip` thinks more tree construction tests are needed, given that his code is full of 'XXX' and 'TODO' comments but still passes the current test cases
  324. # [13:01] <Dashiva> Philip`: Maybe there should be a list of such todos somewhere so it's easy to find out which testcases need writing
  325. # [13:03] <Philip`> I'm just trying to fill in the gaps myself at the moment - if I wrote down a list, I'd forget what anything meant by the time I looked at it again :-)
  326. # [13:08] <annevk> Philip`, awesome
  327. # [13:08] <annevk> we wrote our code and later added some tests on top of the 71 hixie made but that's it
  328. # [13:08] <annevk> then henri added some and we fixed some more bugs, mostly in unicode handling
  329. # [13:09] * Philip` 's implementation only handles ASCII :-(
  330. # [13:09] <annevk> reminds me of arc
  331. # [13:10] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  332. # [13:10] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  333. # [13:19] * Quits: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  334. # [13:20] <virtuelv> annevk: :)
  335. # [13:20] <annevk> "SVGSVGTextElement.getNumberOfChars() counts UTF-16 surrogates as separate characters"
  336. # [13:21] <roc_> mmmm
  337. # [13:21] <annevk> given that various languages already have surrogates build in, maybe SVG should follow?
  338. # [13:21] <Dashiva> The SVGSVG prefix seems accident-prone
  339. # [13:21] <annevk> (failure for test 69 in Opera)
  340. # [13:21] <annevk> (in Acid3)
  341. # [13:39] * Quits: webben_ (n=benh@nat/yahoo/x-9f6bc6e033d741d3)
  342. # [13:51] <hsivonen> annevk: the DOM is pretty deeply in the territory of counting UTF-16 code units
  343. # [13:51] <hsivonen> annevk: and too late to fix
  344. # [13:56] <Philip`> http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3C!doctype%20html%3E%3Ctable%3E%3Cp%3E%3C/table%3E - the </table> should generate implied end tags, which should imply a </p>, which should cause a table-voodoo error
  345. # [13:57] * Philip` doesn't know if that can have a more significant effect than a lack of error
  346. # [14:19] <annevk> hsivonen, right, does it make sense for SVG to be different?
  347. # [14:20] <hsivonen> annevk: oh it's different? no, that doesn't make sense at all
  348. # [14:30] * Joins: webben (n=benh@nat/yahoo/x-816d3d37efcbe35a)
  349. # [14:44] * Quits: roc_ (n=roc@121-72-32-151.dsl.telstraclear.net)
  350. # [14:46] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  351. # [14:49] <zcorpan_> hmm. is it defined anywhere in the html5 spec that elements implement appropriate interfaces when put in the dom by the xml processor? or elements created with createElementNS?
  352. # [14:50] <zcorpan_> i note that the html5 parser says that elements should implement the appropriate interfaces
  353. # [14:51] <zcorpan_> perhaps it should be defined in a higher layer? like "when an element is created and it is in the html namespace, it must implement the appropriate interfaces..." or some such
  354. # [14:53] <Lachy> zcorpan_, since HTML5 is defined in terms of the DOM, it doesn't matter where the elements come from, they still implement the DOM APIs
  355. # [14:54] <zcorpan_> Lachy: so why is there a requirement in the parser about elements implementing appropriate interfaces?
  356. # [14:54] <Lachy> I don't know
  357. # [14:54] <Lachy> seems kind of redundant
  358. # [14:54] <hsivonen> zcorpan_: I think the spec needs to say that XML stuff needs to implement the right stuff
  359. # [15:56] <annevk> hsivonen, is there a summary somewhere of how DOM and ECMAScript assume UTF-16?
  360. # [16:03] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  361. # [16:15] * Joins: phsiao (n=shawn@nat/ibm/x-a3b565f112f5e93a)
  362. # [16:21] <annevk> defining it at an intermediate layer seems cleaner to me
  363. # [16:25] * Quits: MikeSmith (n=MikeSmit@eM60-254-244-76.pool.emnet.ne.jp) ("Less talk, more pimp walk.")
  364. # [16:30] * Joins: billmason (n=billmaso@ip129.unival.com)
  365. # [16:41] * Quits: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  366. # [16:44] * Joins: aroben (n=aroben@68.63.169.23)
  367. # [16:50] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  368. # [16:59] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  369. # [17:00] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  370. # [17:20] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  371. # [17:26] * gsnedders lets his frustration out at the httpbis wg
  372. # [17:29] <gsnedders> <http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0227.html>
  373. # [17:31] * Philip` now has 2000 lines of generated JavaScript to implement a tree constructor
  374. # [17:32] <Philip`> though unfortunately most of the lines say things like debug("TODO: ReprocessAsIf"); because I haven't implemented them yet :-(
  375. # [17:33] <SadEagle> gsnedders: User-Agents MUST ignore the user preferences? That's a nice one.
  376. # [17:33] * SadEagle wonders whether someone has stats on wrong content-type w/in http headers. He surely has seen it with http-equiv
  377. # [17:33] <gsnedders> SadEagle: most of what the HTTPbis WG is working on is totally idealistic and backwards incompatible (well, compatible with conforming impls. of RFC2616, if there are any)
  378. # [17:34] <gsnedders> SadEagle: content-type or charset?
  379. # [17:34] <gsnedders> SadEagle: charset's not that widespread. The issue is with implicit charsets (like on text/xml)
  380. # [17:35] <SadEagle> I meant charset within content-type.
  381. # [17:35] <gsnedders> yeah, if it is explicitly given, it's normally right (except for one or two things, like ISO-8859-1 and GB2302)
  382. # [17:36] <gsnedders> (not GB2302, GB2312)
  383. # [17:37] <annevk> text/xml doesn't have explicit charsets
  384. # [17:37] <annevk> see RFC 3023
  385. # [17:37] <annevk> (within the file, that is)
  386. # [17:37] * annevk -> food
  387. # [17:38] <gsnedders> annevk: I mean on the actual MIME type
  388. # [17:38] <gsnedders> (i.e., parameters on the MIME type
  389. # [17:39] <SadEagle> well, I've seen e.g. <meta http-equiv="content-type:text/html;charset=utf-16"> .... encoded as ASCII. Also koi8/cp1251 messups. Now, w/meta one can claim it's html that defines it anyway, but still, I would expect the sequence in case of a misconfigured server to be:
  390. # [17:39] <gsnedders> SadEagle: that's specific to HTML, though. I'm talking in general HTTP terms. UTF-16 in meta@charset must be ignored
  391. # [17:40] <SadEagle> 1) User open a webpage, sees garbage. 2) User activates encoding auto-detection, which picks the right decoding. 3) The user keeps browsing the webpage with auto-detection (or manualyl chosen charset) "sticky", and has no problem. It seems to me that the proposal would require the user to repeat (2) every time they navigate.
  392. # [17:41] <gsnedders> yeah, it would
  393. # [18:02] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  394. # [18:12] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  395. # [18:12] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  396. # [18:12] <zcorpan_> hsivonen: v.nu says that <p/> is an html4-only error
  397. # [18:23] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
  398. # [18:24] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) (Remote closed the connection)
  399. # [18:25] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  400. # [18:27] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  401. # [18:42] <zcorpan_> hsivonen: it seems that your encoding declaration warnings have gone amok: http://validator.nu/?doc=http%3A%2F%2Fvalidator.w3.org%2F
  402. # [18:46] <Hixie> webben: target=_top is allowed, it's only _blank that isn't.
  403. # [18:47] * zcorpan_ notes that v.w.o has "Group Error Messages by type"
  404. # [18:47] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  405. # [18:47] <webben> Hixie: Thanks, I did note that. :)
  406. # [18:47] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  407. # [18:49] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  408. # [18:49] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  409. # [18:49] * Quits: MacDomeSleep (n=eric@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  410. # [18:50] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  411. # [19:07] * Joins: kingryan (n=ryan@dsl092-219-050.sfo1.dsl.speakeasy.net)
  412. # [19:07] * Parts: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  413. # [19:22] * Joins: maikmerten (n=maikmert@T7c14.t.pppool.de)
  414. # [19:28] <hsivonen> zcorpan_: oops. thanks
  415. # [19:30] * gsnedders is feeling very naïve at the moment
  416. # [19:30] * gsnedders knows nowhere near enough about Python
  417. # [19:35] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  418. # [19:38] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  419. # [19:38] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  420. # [19:39] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  421. # [19:40] * Joins: weinig (n=weinig@64.81.49.105)
  422. # [19:42] * Joins: jgraham_mibbit (i=836f44b5@gateway/web/ajax/mibbit.com/x-33899a2424d8be08)
  423. # [19:43] * Quits: weinig (n=weinig@64.81.49.105) (Client Quit)
  424. # [19:45] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  425. # [19:46] <hsivonen> zcorpan_: fixed. thanks
  426. # [20:00] * Joins: jwalden (n=waldo@STRATTON-ONE-FORTY-THREE.MIT.EDU)
  427. # [20:02] * Joins: roc (n=roc@121-72-32-151.dsl.telstraclear.net)
  428. # [20:02] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  429. # [20:07] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  430. # [20:08] * Joins: dbaron (n=dbaron@guest-228.mountainview.mozilla.com)
  431. # [20:08] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  432. # [20:09] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  433. # [20:23] * Joins: hober (n=ted@unaffiliated/hober)
  434. # [20:27] * Quits: maikmerten (n=maikmert@T7c14.t.pppool.de) (Remote closed the connection)
  435. # [20:34] * Quits: roc (n=roc@121-72-32-151.dsl.telstraclear.net)
  436. # [20:38] * Joins: dbaron_ (n=dbaron@corp-241.mountainview.mozilla.com)
  437. # [20:39] * Joins: eseidel (n=eseidel@nat/google/x-43006ebfc0104abc)
  438. # [20:52] * Quits: dbaron (n=dbaron@guest-228.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
  439. # [21:00] <Hixie> jwalden: yt?
  440. # [21:01] <jwalden> Hixie: sorta; you caught me just before a phone conference actually :-)
  441. # [21:02] <Hixie> i just made a change to MessageEvent/postMessage() for security that fixed a separate problem from the one that was raised earlier
  442. # [21:02] <Hixie> i'm about to send mail to whatwg explaining it
  443. # [21:02] <Hixie> annevk: see above also
  444. # [21:02] <Hixie> basically changing message.domain and message.uri to just message.origin
  445. # [21:02] <Hixie> which is what the .uri value used to be, but without the path
  446. # [21:02] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  447. # [21:03] <jwalden> hm
  448. # [21:03] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  449. # [21:03] <jwalden> I await the explanation!
  450. # [21:03] <Hixie> :-)
  451. # [21:03] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  452. # [21:04] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  453. # [21:05] <Hixie> sent
  454. # [21:06] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  455. # [21:15] * Quits: jgraham__ (n=jgraham@81-86-208-197.dsl.pipex.com) ("Ex-Chat")
  456. # [21:16] * Joins: roc (n=roc@202.0.36.64)
  457. # [21:20] <jwalden> nice catch on username/password; I should have thought of that in my testing
  458. # [21:20] <jwalden> I *did* think of it once you summarized the change above, tho :-)
  459. # [21:20] <Hixie> :-)
  460. # [21:20] <Hixie> i think this, as a sideeffect, will simplify addressing one of the other problems
  461. # [21:21] <Hixie> instead of postMessage(message, [domain, [uri]]); we can just have postMessage(message, [origin]);
  462. # [21:21] <jwalden> so everything before the path, *except* for username/password, then
  463. # [21:21] <Hixie> yeah
  464. # [21:21] <Hixie> (and later make it postMessage(message, [endPoint], [origin]), since those two are type-distinguishable)
  465. # [21:27] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I'll hit the bottom and escape")
  466. # [21:37] <aroben> Hixie: what commit did this change occur in? I can't find it in the tracker
  467. # [21:37] <jwalden> I sent my response
  468. # [21:38] * aroben is writing a bug report for WebKit and wants to link to the change
  469. # [21:38] <jwalden> I'll note that I originally wanted .domain to always include a port number, which would have avoided the first problem even if I'd never have noticed that we'd avoided it :-P
  470. # [21:38] <jwalden> and I definitely wouldn't have noticed the first problem
  471. # [21:39] <jwalden> I'm still a bit chagrined I missed the second
  472. # [21:39] <jwalden> GAAAAH
  473. # [21:40] * jwalden gets bitten by forgetting +whatwg AGAIN
  474. # [21:40] * Joins: jgraham (n=jgraham@81-86-208-197.dsl.pipex.com)
  475. # [21:43] * Joins: jgraham_ (n=james@81-86-208-197.dsl.pipex.com)
  476. # [21:44] * gsnedders bits jwalden
  477. # [21:44] <jwalden> ?
  478. # [21:44] <gsnedders> *bites
  479. # [21:45] <gsnedders> jgraham: I took a good look at the treebuilders today, and I really can't work out how the etree stuff works.
  480. # [21:45] <jgraham_> gsnedders: By magic :)
  481. # [21:46] <gsnedders> :)
  482. # [21:46] <gsnedders> (i.e., I can't get DOM to work in a similar way)
  483. # [21:46] <jgraham_> What do you actually want to know?
  484. # [21:46] <gsnedders> I just don't really understand how the etree stuff works _at all_.
  485. # [21:47] <gsnedders> as in, how it works out what etree impl to use from the second param to getTreeBuilder
  486. # [21:48] <jgraham_> So, from memory, we do something like create a module-like object at runtime with a module-level variable ElementTree set to the module of the Element Tree implementation that we're using
  487. # [21:49] <gsnedders> what does getETreeBuilder() do?
  488. # [21:49] * jgraham_ decides looking t the code would help
  489. # [21:49] <gsnedders> what's **kwargs?
  490. # [21:50] <gsnedders> heck, what does *arg and **arg mean?
  491. # [21:50] <webben> it's different ways of passing arguments in Python
  492. # [21:50] <webben> IIRC kwargs is named parameters
  493. # [21:50] <webben> can't remember the difference between *arg and **arg
  494. # [21:51] <jgraham_> *args means take the tuple args and expand its value as a set of arguments to a function
  495. # [21:51] <gsnedders> ah
  496. # [21:52] <jgraham_> so something like func(*(True, 3)) calls func with the args True and 3
  497. # [21:52] <gsnedders> and ** is reference?
  498. # [21:52] <jgraham_> similarly **kwargs expands a dict kwargs as a set of named parameters to a function
  499. # [21:52] <gsnedders> ah
  500. # [21:52] <jwalden> Hixie: you didn't update initMessageEvent(NS)?
  501. # [21:52] <gsnedders> then how do you pass by reference?
  502. # [21:53] <jgraham_> so func(**{"foo":True, "bar":3}) == func(foo=True, bar=3)
  503. # [21:53] <jgraham_> gsnedders: You don't
  504. # [21:53] <gsnedders> yeah. that makes sense.
  505. # [21:53] <gsnedders> jgraham_: ah.
  506. # [21:53] <gsnedders> jgraham_: that's simple.
  507. # [21:53] <jgraham_> or rather, you always pass by _object_
  508. # [21:53] <gsnedders> now, back to treebuilders
  509. # [21:56] <jgraham_> so something like "a = [1,2]; func = lambda x:x.append(3);func(a);print a" will print [1,2,3]
  510. # [21:56] <gsnedders> ya
  511. # [21:59] <jgraham_> gsnedders: So, getETreeBuilder is like a function to return a set of functions which are all closures over the value of ElementTreeImplementation
  512. # [22:00] <jgraham_> notice the return locals() at the end
  513. # [22:00] <jgraham_> those functions are turned into a module on the fly in getEtreeModule
  514. # [22:01] <jgraham_> This is kinda icky but I wasn't sure how else to reuse all the code for multiple etree implementations
  515. # [22:01] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  516. # [22:01] * jgraham_ has to go eat now, will be back later
  517. # [22:01] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  518. # [22:02] <gsnedders> Hixie: you have <code title""> in html5, what's this meant to be?
  519. # [22:02] <gsnedders> (or is my in-head parser not got some quirky error handling?)
  520. # [22:03] <gsnedders> Hixie: (see "<p>For the purposes of the interaction of HTML with Selectors' <code")
  521. # [22:10] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  522. # [22:10] * gsnedders throws this proposal for recreating toc(1) and num(1) out the window for being far too expensive
  523. # [22:12] <gsnedders> Hixie: that is per HTML 5 seemingly an empty title"" attribute. I guess you didn't mean that :)
  524. # [22:12] * Quits: aroben (n=aroben@unaffiliated/aroben) ("bbl")
  525. # [22:23] <Philip`> Is there some way I can construct a DOM element using JS so it has an attribute called something like title"" without throwing exceptions?
  526. # [22:24] <Philip`> I can't make a very good HTML parser if there's no way to construct the things that are parsed :-(
  527. # [22:24] <blooberry> can you use String.fromCharCode?
  528. # [22:25] * Joins: weinig (n=weinig@nat/apple/x-c190df363f08456c)
  529. # [22:25] <Philip`> The problem is just when trying to pass the string into setAttribute
  530. # [22:25] <blooberry> it throws an exception in that case?
  531. # [22:26] <Philip`> In Firefox 2, yes
  532. # [22:26] <Philip`> (In Opera 9.5, no)
  533. # [22:26] <Philip`> (In Safari 3, yes)
  534. # [22:27] <Philip`> presumably because it's a totally bogus attribute name
  535. # [22:31] <SadEagle> It should.
  536. # [22:32] <jgraham_> gsnedders: Did any of that help?
  537. # [22:32] <gsnedders> jgraham_: I'm still in the middle of finishing off an email :P
  538. # [22:32] <gsnedders> (ironically, this one email is probably longer than the total amount of writing I've done at school over the past two days)
  539. # [22:33] * weinig is now known as weinig|talksToMi
  540. # [22:38] * weinig|talksToMi is now known as weinig
  541. # [22:38] <jwalden> hm
  542. # [22:39] <jwalden> isn't this domain hazard also common to document.domain as well?
  543. # [22:39] <gsnedders> OK, now what jgraham_ said
  544. # [22:57] * Quits: eseidel (n=eseidel@nat/google/x-43006ebfc0104abc)
  545. # [22:59] <Hixie> jwalden: as i understand it, doc.domain doesn't allow you to cross ports or schemes
  546. # [23:00] <jwalden> Hixie: I could have sworn Mozilla did differently last time I looked
  547. # [23:00] <Hixie> ah
  548. # [23:01] * Joins: eseidel (n=eseidel@nat/google/x-fae2a7ba657e964a)
  549. # [23:04] <gsnedders> jgraham_: OK, that makes sense now.
  550. # [23:04] <gsnedders> (no, it didn't take 20 minutes, I went and procrastinated)
  551. # [23:05] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  552. # [23:05] <gsnedders> From the looks of things, it'd be simplest to just do the same as etree does
  553. # [23:05] * Quits: webben (n=benh@nat/yahoo/x-816d3d37efcbe35a) (Connection timed out)
  554. # [23:05] <gsnedders> Though it looks like the only thing that'll change for each DOM impl is the TreeBuilder class itself
  555. # [23:07] <gsnedders> Or rather, that's the only one that needs to reference the actual impl.
  556. # [23:07] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Remote closed the connection)
  557. # [23:18] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  558. # [23:19] * Joins: heycam|sydney (n=cam@b4F38.static.pacific.net.au)
  559. # [23:19] <met_> Has any browser implemented datagrid already?
  560. # [23:19] * met_ is trying nigthtly build without success
  561. # [23:21] <jgraham_> met_: not as fr as I know
  562. # [23:21] <jgraham_> s/fr/far/
  563. # [23:22] * jgraham_ wonders how much effort it would be to implement in js
  564. # [23:22] <met_> thx, it looks same for me
  565. # [23:22] <met_> preparing some examples for html5 presentation and some datragrid example should be nice and powerfull 8-)
  566. # [23:23] <met_> but I have nowhere to check it
  567. # [23:25] * Quits: eseidel (n=eseidel@nat/google/x-fae2a7ba657e964a)
  568. # [23:26] <gsnedders> jgraham_: would you say just chucking everything in dom.py into a function, like etree.py, would be the best way to go about it?
  569. # [23:27] <gsnedders> brb
  570. # [23:27] * Quits: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com) ("Partying in teh intarwebs")
  571. # [23:28] <jgraham_> gsnedders: I don't like to make claims about best :) But consistency is good and if we decide the whole design sucks later it's easier to change two similar things than two different things
  572. # [23:28] <zcorpan_> Philip`: no, you can't (re title"")
  573. # [23:32] * Joins: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  574. # [23:37] * Joins: eseidel (n=eseidel@nat/google/x-25fe566378539277)
  575. # [23:39] * Joins: webben (n=benh@82.152.229.45)
  576. # [23:45] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  577. # [23:52] * Quits: kingryan (n=ryan@dsl092-219-050.sfo1.dsl.speakeasy.net) (Read error: 113 (No route to host))
  578. # [23:53] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  579. # [23:54] * Quits: phsiao (n=shawn@nat/ibm/x-a3b565f112f5e93a)
  580. # [23:59] * Quits: eseidel (n=eseidel@nat/google/x-25fe566378539277)
  581. # [23:59] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  582. # Session Close: Wed Feb 13 00:00:00 2008

The end :)