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

Options:

  1. # Session Start: Sat Feb 09 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:11] * Quits: Yudai (n=Yudai@p6e1248.kngwnt01.ap.so-net.ne.jp) (Read error: 113 (No route to host))
  4. # [00:12] * Joins: Yudai (n=Yudai@p9258c3.kngwnt01.ap.so-net.ne.jp)
  5. # [00:20] * Quits: roc (n=roc@121-72-11-14.dsl.telstraclear.net)
  6. # [00:21] * Quits: tantek (n=tantek@70-13-120-189.area2.spcsdns.net)
  7. # [00:29] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  8. # [00:30] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  9. # [00:31] * Quits: Charl (n=charlvn@196-209-214-215-esdw-esr-3.dynamic.isadsl.co.za) ("Leaving")
  10. # [00:58] * Quits: cgriego (n=cgriego@216.138.69.206)
  11. # [01:10] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  12. # [01:25] * Quits: aroben (n=aroben@unaffiliated/aroben)
  13. # [01:30] * Quits: jwalden (n=waldo@STRATTON-SEVEN-FOURTY-SIX.MIT.EDU) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  14. # [01:30] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  15. # [01:30] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  16. # [01:33] * Joins: tantek (n=tantek@adsl-75-48-103-78.dsl.irvnca.sbcglobal.net)
  17. # [01:37] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I get eaten by the worms")
  18. # [01:52] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  19. # [01:56] * Joins: starjive (i=beos@81-233-18-73-no30.tbcn.telia.com)
  20. # [02:06] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.2 (IRC client for Emacs)")
  21. # [02:25] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net) ("durr...")
  22. # [02:49] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  23. # [02:50] * Quits: kingryan (n=ryan@dsl092-219-050.sfo1.dsl.speakeasy.net) (Read error: 113 (No route to host))
  24. # [02:56] * Quits: tndH (i=Rob@87.102.19.44) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  25. # [03:11] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  26. # [03:11] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net) (Remote closed the connection)
  27. # [03:23] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  28. # [03:23] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  29. # [03:28] * Quits: tantek (n=tantek@adsl-75-48-103-78.dsl.irvnca.sbcglobal.net)
  30. # [03:49] * Joins: tantek (n=tantek@99-203-176-219.area2.spcsdns.net)
  31. # [03:51] * Quits: tantek (n=tantek@99-203-176-219.area2.spcsdns.net) (Client Quit)
  32. # [04:00] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  33. # [04:12] * Quits: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  34. # [04:44] * Joins: tantek (n=tantek@99-203-48-53.area2.spcsdns.net)
  35. # [04:44] * Quits: weinig (n=weinig@17.203.15.140)
  36. # [04:46] * Joins: tantek_ (n=tantek@adsl-69-235-47-218.dsl.irvnca.pacbell.net)
  37. # [04:55] * Quits: tantek (n=tantek@99-203-48-53.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  38. # [05:15] * Quits: tantek_ (n=tantek@adsl-69-235-47-218.dsl.irvnca.pacbell.net)
  39. # [05:19] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  40. # [05:25] * weinig is now known as weinig|notReally
  41. # [05:26] * weinig|notReally is now known as weinig
  42. # [05:32] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  43. # [05:34] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) ("Konversation terminated!")
  44. # [05:35] * weinig is now known as weinig|NAP
  45. # [05:42] * Joins: roc (n=roc@121-72-11-14.dsl.telstraclear.net)
  46. # [05:51] <Hixie> firefox is the only browser with any DOM storage support?
  47. # [05:52] <othermaciej> I think that's the case
  48. # [05:52] <Hixie> k
  49. # [05:53] <Hixie> just making sure i set the right flags on my checkin
  50. # [05:55] <othermaciej> are you updating the spec?
  51. # [05:55] <othermaciej> it's definitely something we're interested in for WebKit
  52. # [05:55] <roc> really? I thought SQL obsoleted it
  53. # [05:55] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  54. # [05:56] <Hixie> othermaciej: yep
  55. # [05:56] <Hixie> roc: people have (strongly) argued that there is room for a simple string key/value synchronous api and an asynchronous structured api
  56. # [05:57] <othermaciej> roc: mostly, but I think a simple API for basic key/value storage is still worthwhile
  57. # [05:57] <roc> ok
  58. # [06:12] * Joins: tantek (n=tantek@68-25-229-201.area2.spcsdns.net)
  59. # [06:14] * Quits: tantek (n=tantek@68-25-229-201.area2.spcsdns.net) (Client Quit)
  60. # [06:40] * doublec_ is now known as doublec
  61. # [07:37] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  62. # [08:04] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  63. # [08:19] * Quits: roc (n=roc@121-72-11-14.dsl.telstraclear.net)
  64. # [08:19] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  65. # [08:20] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  66. # [09:13] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  67. # [09:28] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  68. # [09:31] * Joins: roc (n=roc@121-72-11-14.dsl.telstraclear.net)
  69. # [09:56] * Joins: virtuelv (n=virtuelv@ti132110a341-3376.bb.online.no)
  70. # [10:00] <hsivonen> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
  71. # [10:00] <Hixie> yet another reason not to put anything in the doctype...
  72. # [10:06] <jruderman> bonus points if you can find a real-world program that given <!DOCTYPE html> tries to request a DTD from ""
  73. # [10:06] <Hixie> i think the w3c should just make those DTD URIs return infinite streams of bytes
  74. # [10:06] <Hixie> or return constructed gzipped content that unzips to gigantic files
  75. # [10:06] <jruderman> i liked the idea on slashdot to delay the response
  76. # [10:08] <Hixie> or that
  77. # [10:16] * MacDomeSleep is now known as MacDome
  78. # [10:16] * Joins: franksalim_ (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  79. # [10:22] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com) (Read error: 110 (Connection timed out))
  80. # [10:25] * Joins: annevk (n=annevk@77.163.243.203)
  81. # [10:47] <annevk> a great, people resolved the header naming problems :)
  82. # [10:50] * Joins: ROBOd (n=robod@89.122.216.38)
  83. # [10:52] <annevk> maybe I should wait some more and then the spec is suddenly done
  84. # [11:03] <hsivonen> the Slashdot comments on the DTD thing are sad as usual
  85. # [11:03] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  86. # [11:04] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  87. # [11:07] <annevk> someone pointed out in e-mail that HTML 5 is the fourth major revision of HTML and not the fifth
  88. # [11:08] <jruderman> why, because it's not a "revision" until version 2?
  89. # [11:08] <annevk> if you don't count XHTML 1.x it seems he's right, should we change abstract text here and there?
  90. # [11:08] <annevk> that's his reasoning, yes
  91. # [11:08] <annevk> arguably CSS 2.1 follows that reasoning
  92. # [11:08] <jruderman> how about saying it's "a major revision"?
  93. # [11:15] * MacDome is now known as MacDomeSleep
  94. # [11:18] * Joins: eseidel (n=eseidel@72.14.224.1)
  95. # [11:19] * Quits: MacDomeSleep (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  96. # [11:33] <hsivonen> it's interesting that these questions aren't in the Systeam list of questions: 1) Are DTDs a bad idea and should we get rid of them? and 2) Is using URIs as identifiers that aren't meant to be dereferenced a bad idea and should we stop using them that way?
  97. # [11:34] * Joins: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  98. # [11:46] * Quits: eseidel (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
  99. # [12:16] * Joins: tantek (n=tantek@71-92-201-252.dhcp.gldl.ca.charter.com)
  100. # [12:20] * Joins: apfel (n=apfel@gb006.stw.stud.uni-saarland.de)
  101. # [12:20] * Parts: apfel (n=apfel@gb006.stw.stud.uni-saarland.de)
  102. # [12:26] <gsnedders> annevk: I'd argue the IIIR draft was the first major
  103. # [12:29] * Quits: roc (n=roc@121-72-11-14.dsl.telstraclear.net)
  104. # [12:46] * Joins: tndH_ (i=Rob@87.102.19.44)
  105. # [12:46] * tndH_ is now known as tndH
  106. # [12:46] * Joins: maikmerten (n=maikmert@L8a32.l.pppool.de)
  107. # [12:47] * jgraham thinks arguing about whether the first version of something counts as a revision is just as pointless as he arguments about whether the "new millennium" started in 2000 or 2001
  108. # [12:47] <jruderman> hehe
  109. # [12:50] <annevk> to be clear, I'm just wondering how to reply to such a question
  110. # [12:50] <annevk> aesthetically "fifth" sounds better, but other than that I've no opinion on this
  111. # [12:51] <gsnedders> jgraham: 2001, kthxbai
  112. # [12:55] <jruderman> annevk: reword the thing so you're not forced to say that it's the "fourth" or "fifth" revision
  113. # [12:55] <jruderman> call it "a major revision" or "the fifth major version"
  114. # [13:01] <annevk> the latter would not be ok :)
  115. # [13:01] <annevk> I guess I'll just follow whatever Hixie does
  116. # [13:06] <gsnedders> <http://www.onenaught.com/posts/52/ie8-meta-switch-ie7> — heh: "Ian Hixie"
  117. # [13:06] * Quits: heycam (n=cam@124-168-78-30.dyn.iinet.net.au) ("bye")
  118. # [13:12] <jruderman> hah
  119. # [13:13] <hsivonen> gsnedders: that's actually pretty common
  120. # [13:13] <gsnedders> hsivonen: googling just mostly showed up his email address, so I can't really tell
  121. # [13:57] * Joins: virtuelv_ (n=virtuelv@ti132110a341-0704.bb.online.no)
  122. # [13:59] * Quits: virtuelv_ (n=virtuelv@ti132110a341-0704.bb.online.no) (Client Quit)
  123. # [14:00] * Joins: virtuelv_ (n=virtuelv@ti132110a341-0704.bb.online.no)
  124. # [14:06] * Quits: virtuelv (n=virtuelv@ti132110a341-3376.bb.online.no) (Read error: 110 (Connection timed out))
  125. # [14:09] * Quits: maikmerten (n=maikmert@L8a32.l.pppool.de) ("Leaving")
  126. # [14:23] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I get eaten by the worms")
  127. # [14:36] * franksalim_ is now known as franksalim
  128. # [14:57] * Joins: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU)
  129. # [15:05] * Joins: webben (n=benh@82.152.229.45)
  130. # [15:43] * Philip` sees requests with Referer set to `62.101.193.244/lupii;chmod$IFS+x$IFS`echo$IFS\ and to XXXX:++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  131. # [15:44] <annevk> yeah, Referer is wrong quite often already...
  132. # [15:44] <Philip`> and one set to HTTP/1.1 (with a space at the start)
  133. # [15:45] <Philip`> Oh, and some spammy ones like >Link</a> &gt;sterling silver jewelry&lt;/a&gt;<br>&lt;a href= <a href=\
  134. # [15:46] <Philip`> I'm slightly surprised that so few are invalid, though
  135. # [15:51] <hsivonen> Hixie: regarding conference-speaking standardista buy-in and the top errors I identified in Alexa top 500:
  136. # [15:51] <hsivonen> Hixie: I ran the Happy Cog portfolio front pages through Validator.nu and the errors are pretty much the top errors from Alexa 500
  137. # [15:51] <hsivonen> Hixie: http://hsivonen.iki.fi/test/moz/happycog-portfolio-results.txt
  138. # [15:52] * Joins: jdandrea (n=jdandrea@ool-44c09c49.dyn.optonline.net)
  139. # [15:52] * Quits: jdandrea (n=jdandrea@ool-44c09c49.dyn.optonline.net) (Remote closed the connection)
  140. # [15:52] <hsivonen> (The Happy Cog portfolio represents actual well-known standardista output here.)
  141. # [15:54] <Philip`> Presumably those sites were modified by their own developers after the initial design, so it seems hard to tell when the errors were introduced
  142. # [15:54] <hsivonen> Philip`: sure, that's likely, but Zeldman's company keeps them in their portfolio, so this should be as good as it gets in the real world
  143. # [15:56] <annevk> I don't agree with that
  144. # [15:57] <hsivonen> annevk: which part you don't agree with?
  145. # [15:57] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  146. # [15:57] <annevk> The state of the Web ten years ago wasn't what it is now. Change is certainly pssobile
  147. # [15:57] <annevk> possible, even
  148. # [15:58] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  149. # [15:58] <annevk> though some of those errors should not be errors, agreed, _blank
  150. # [15:58] <hsivonen> annevk: sure, change is possible. I'm just arguing that people shouldn't have to focus their effort on benign "errors"
  151. # [15:59] <annevk> seems that for Zeldman there's nothing else left :)
  152. # [16:02] <hsivonen> Moreover, over 50% of the portfolio is in the Almost Standards Mode instead of the Standards Mode
  153. # [16:02] <hsivonen> which demonstrates that even in the standardista circles, the status quo against which HTML5 should be measured is Transitional--not so much Strict
  154. # [16:07] <webben> Note that the use of transitional may reflect the inclusion of the TARGET attribute or ads.
  155. # [16:10] <hsivonen> webben: sure, but that makes target and ads part of the practical reality
  156. # [16:11] <webben> Perhaps. It depends on quite what that means.
  157. # [16:12] <hsivonen> ad boilerplate will come with <img border=0>, <iframe frameborder='0' width='...' height='...'> for the foreseeable future
  158. # [16:12] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  159. # [16:12] <webben> I'd say it reflects a desire to have some links open in new browsing contexts and a desire to include markup from external sources that you basically don't control.
  160. # [16:12] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  161. # [16:12] <webben> Both practices are problematic for reasons other than validation.
  162. # [16:14] <hsivonen> webben: yes, they are problematic, but they are also so common that seeking to make them non-conforming due to the problems would be ivory towerism
  163. # [16:14] <webben> (and both might have better solutions than target or using a document type that is "looser" in the future)
  164. # [16:14] <Philip`> <div dont-validate-since-its-not-my-content-and-i-cant-do-anything-about-it><img border=0 ...></div>
  165. # [16:15] <webben> Philip`: Exactly.
  166. # [16:16] <hsivonen> webben: when there are widely implemented interoperable solutions that pretty much work, seeking to introduce slightly better second systems is bad strategy
  167. # [16:16] <webben> TARGET has triggered a sort of arms race between designers and end-users. I've discussed previously in this context that user-agent behavior could be attached to REL attributes and this would cover the two common use-cases of target: opening external sites and help in new browser windows.
  168. # [16:17] <webben> In that context, target would mainly be a backwards compatibility measure.
  169. # [16:17] <webben> (and might be perfectly valid as such)
  170. # [16:17] <webben> I wouldn't say that invalid ad markup does "work", actually.
  171. # [16:17] <annevk> target could work the same as your rel proposal and in fact does already in UAs
  172. # [16:18] <Philip`> It would be nice if target=_blank let you set the width/height of the window, so you wouldn't have to use ugly JavaScript just for a link
  173. # [16:18] <annevk> hsivonen, transitional may be for layout purposes, dunno
  174. # [16:18] <webben> annevk: You can't configure a UA to do something different depending on what sort of link it is, AFAIK.
  175. # [16:18] <webben> I don't want to load external sites in a new context, but I might well want to load form help in one.
  176. # [16:18] <hsivonen> webben: bikeshedding the attribute name is the kind of second systemitis that has an unfavorable cost/benefit outlook
  177. # [16:19] * Quits: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com) ("Partying in teh intarwebs")
  178. # [16:19] <webben> I'm not sure what that means.
  179. # [16:19] <annevk> rel= doesn't work that way either
  180. # [16:19] <annevk> so i'm not sure if inventing something new is a good way to solve the problem
  181. # [16:20] <webben> annevk: It could do.
  182. # [16:20] <annevk> target= could too
  183. # [16:20] <Philip`> Calling it "bikeshedding" seems to be presupposing that it has an unfavourable cost/benefit outlook
  184. # [16:20] <hsivonen> http://en.wikipedia.org/wiki/Second-system_effect
  185. # [16:21] <webben> annevk: Well you could use target="help" and target="external", but then you're duplicating REL values and probably breaking target in the process.
  186. # [16:21] <webben> http://www.w3.org/TR/html401/types.html#type-links
  187. # [16:21] <hsivonen> target='_blank' is super-simple. a bunch of rel values and a full pref pane of checkboxes for them would be more complex
  188. # [16:21] <annevk> what hsivonen says
  189. # [16:22] <webben> I don't think you'd need that much user configuration, because in fact end-users generally don't want external links to open in new windows unless it would disrupt what they're doing to open in the main browsing context.
  190. # [16:23] <hsivonen> evidence shows that authors feel they need to open new windows
  191. # [16:23] <hsivonen> defaults must cater to the perceived needs of authors
  192. # [16:23] <webben> Yes, and will go way beyond what HTML provides in order to do so.
  193. # [16:23] <hsivonen> otherwise authors endeavor to defeat the defaults
  194. # [16:23] <webben> it's irrelevant if target is valid, since it's trivial for UAs to turn it off.
  195. # [16:24] <webben> so authors who really want to do so are forced into using script.
  196. # [16:24] <hsivonen> webben: that's the very reason why target should be valid and open new windows by default
  197. # [16:24] <hsivonen> webben: this way authors are lulled into the belief that they are in control but users can still easily opt for control
  198. # [16:25] <webben> Some stupid authors are.
  199. # [16:25] <webben> A lot of less stupid but equally user-hostile authors aren't.
  200. # [16:25] <webben> (Otherwise, there would be no arms race.)
  201. # [16:25] <hsivonen> by default, authors need to believe their links don't have focus rings, that they can open windows, etc.
  202. # [16:25] <annevk> there is no arms race
  203. # [16:26] <annevk> there's just an arms race with validators
  204. # [16:26] <annevk> the scripts that use rel=external actually insert target=_blank !
  205. # [16:26] <hsivonen> that's so sad
  206. # [16:26] <webben> Would be better done clientside.
  207. # [16:26] <webben> (by the client)
  208. # [16:27] <hsivonen> (in the way that validators aren't clearly serving authors there)
  209. # [16:27] <webben> I'd say it's the clients that aren't serving authors by not attaching sensible behaviours to rel.
  210. # [16:28] <annevk> oh please, rel is hardly used
  211. # [16:28] <webben> chicken egg
  212. # [16:28] <annevk> and underdefined except for some values
  213. # [16:28] <annevk> also, target=_blank works
  214. # [16:28] <annevk> just fine
  215. # [16:28] <webben> It doesn't work for all the reasons we've just discussed.
  216. # [16:28] <hsivonen> rel=external isn't any better than target=_blank
  217. # [16:28] <hsivonen> they are like <em> and <i>
  218. # [16:29] <webben> If I have to block target to stop external links opening in new windows but this also breaks help in forms, that's not a good outcome.
  219. # [16:29] <hsivonen> except rel=extarnal has a worse compat story than <em>
  220. # [16:30] <webben> Clearly, being able to say why a resource needs a new context rather than just randomly declaring resources need a new context is a better solution; whether it's worth the backwards compatibility friction is obviously debatable.
  221. # [16:30] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  222. # [16:30] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  223. # [16:31] <annevk> your solution sounds too hard for authors and users together
  224. # [16:31] <webben> It doesn't seem "hard" for either.
  225. # [16:31] <webben> target certainly is hard for both
  226. # [16:31] <webben> doesn't achieve what either group wants
  227. # [16:31] <annevk> right...
  228. # [16:32] <hsivonen> webben: rel=help on forms would have an awful backwards compat story
  229. # [16:32] <webben> hsivonen: I didn't suggest using /only/ rel="help", at least initially.
  230. # [16:33] <hsivonen> webben: it seems to me that the really better solution is making forms usable enough that you don't need a new window worth of help
  231. # [16:33] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  232. # [16:33] <hsivonen> webben: then there's the legalese problem
  233. # [16:33] <webben> hsivonen: That seems much more unrealistic.
  234. # [16:34] <webben> (Not least because there is no process so simple that it can't be subject to explanation, rightly or wrongly.)
  235. # [16:34] <hsivonen> that designers want forms to pop up legal mumbo jumbo in a new window
  236. # [16:34] <webben> case in point: http://windowshelp.microsoft.com/Windows/en-US/help/2e680b8d-211e-41c5-a0bf-9ccc6d7e62a21033.mspx
  237. # [16:35] <annevk> webben, so your believe is that you can change the mindset of all authors to start using rel values where they currently use target=_blank (or equivalent) and that users of all clients can be taught by some clever piece of navigation configuration UI?
  238. # [16:35] <webben> hsivonen: This is trying to argue away from the use-cases of target.
  239. # [16:35] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  240. # [16:35] <annevk> i'm so not convinced
  241. # [16:35] <hsivonen> webben: the Leopard box proves the problem is solvable :-)
  242. # [16:35] <webben> hsivonen: It does?
  243. # [16:36] <hsivonen> webben: the Leopard box doesn't need an opening guide because it is better designed than the Vista box
  244. # [16:37] <hsivonen> Web Forms 2.0 already enables form help in title=''
  245. # [16:37] <webben> Or just not as thoroughly documented.
  246. # [16:37] <Philip`> Maybe it's designed with different goals, like not needing to be protected against people walking up to big wall of DVDs in a shop and stealing the disc and license key from the box without anyone noticing
  247. # [16:37] <hsivonen> chances are that if you need more help than that, the design of the form sucks
  248. # [16:38] <webben> TITLE is subject to all the well-rehearsed problems with TITLE.
  249. # [16:38] <hsivonen> yes, it is
  250. # [16:39] <webben> Plus I suspect that would be a lot less usable for end-users without special handling from UAs.
  251. # [16:39] <webben> And also, there's no way you could cram all the help required for a tax form field into TITLE.
  252. # [16:40] <webben> (Now tax forms are indeed too complicated, but redesigning the world's financial system seems rather out of bounds for HTML5. Government5 maybe ...)
  253. # [16:40] * Philip` has used online application forms where it's very useful to have several paragraphs of explanatory text in popup windows, since for most fields most people will easily understand what to enter (so they don't need any explanation) but a few people will have more complex situations and will need more guidance before being able to answer
  254. # [16:41] <webben> So I don't see any real way out of progressive disclosure in forms.
  255. # [16:41] <webben> (Though there might be better ways of providing progressive disclosure, of course.)
  256. # [16:42] <annevk> Philip`, working on planet.html5.org, dreamhost takes quite a while to setup a subdomain though it seems :(
  257. # [16:42] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  258. # [16:42] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  259. # [16:44] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  260. # [16:48] * Philip` thinks the <a ping> Referer header should be "http://www.w3.org/2008/html/ping"
  261. # [16:49] <Philip`> since that won't be misinterpeted as a local referrer by any site (except w3.org), and everyone loves URIs that aren't meant to be dereferenced
  262. # [16:50] <hsivonen> heh
  263. # [16:56] <webben> annevk: I think it probably wouldn't require a typical user to configure anything. Let's say UAs start opening new windows when target and rel="help" are present. Then authors who want to trigger help in a new window in forms or pages with state have an incentive to add rel="help", since the end user is more likely to see the help in the new window. In other words, I don't expect authors to change their mindset particularly, but rather to continue to do "what
  264. # [16:57] <hsivonen> webben: your solution assumes that authors in general want to make it easier for users to turn off new windows of certain kinds
  265. # [16:58] <webben> hsivonen: Not at all. It assumes that authors in general want to make it more likely new windows will be opened.
  266. # [16:58] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  267. # [16:58] <webben> (rather than the form/state breaking or the browser throwing up some sort of notification to check the user wants to open the new window)
  268. # [16:59] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  269. # [16:59] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  270. # [17:01] <Philip`> The people with the strongest desire to open popup windows are those serving popup ads, so they'd probably be the first to use rel=help if it made popups less likely to be blocked
  271. # [17:01] <webben> (And for what it's worth, I don't think authors in /general/ are necessarily hostile to such user configuration, though some authors are I think they're a minority. Ignorance of the very possibility of user configuration is a bigger problem than hostility towards it; and hostility tends to be about pixel-perfection which isn't really a consideration here.
  272. # [17:02] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  273. # [17:02] <webben> Philip`: popup ads typically popup on a trigger other than a link being clicked.
  274. # [17:02] <webben> e.g. page load, mousing over the ad etc
  275. # [17:03] <webben> if you're going to trigger a window opening when a link is actually clicked, you might as well just send the user to the site you're advertising
  276. # [17:03] <webben> I think the "problem" here is more designers who stick all external links into a new window.
  277. # [17:03] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  278. # [17:04] <Philip`> Ah, so the places where rel=help would help are not places where window-opening is currently blocked?
  279. # [17:04] <SadEagle> well, currently link clicks would typically bypass popup blocking.
  280. # [17:04] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  281. # [17:04] <webben> popup blocking is a different issue that what happens when you click a link
  282. # [17:04] <webben> though some popup blockers do control target behavior as well i think
  283. # [17:05] <webben> *than what happens
  284. # [17:06] <webben> (well that's one half of the problem, the other half of the problem is user agents that can't open new windows)
  285. # [17:06] <SadEagle> handheld/mobile?
  286. # [17:08] <hsivonen> annevk: Google translator autodetects your presentation as English...
  287. # [17:08] <webben> kiosk, some text browsers, handhelds
  288. # [17:08] <webben> voice browser perhaps
  289. # [17:08] <annevk> hsivonen, lang= fails then :(
  290. # [17:08] <hsivonen> yay for metadata
  291. # [17:09] <Dashiva> Considering text-based IRC clients can support multiple channels, I'd expect text browsers can support multiple tabs too
  292. # [17:09] <krijnh> annevk: did you expect people to trip over the doctype thing yesterday? :)
  293. # [17:09] <annevk> hsivonen, and yay for quirky detection algorithms :p
  294. # [17:09] <webben> Some text browsers can. IIRC lynx can't.
  295. # [17:10] <Dashiva> But that's just a missing feature, not an inherent problem with text browsers
  296. # [17:10] <SadEagle> there are lots of things lynx can't do, though :-)
  297. # [17:10] <zcorpan_> annevk: what a ripoff ;)
  298. # [17:10] <krijnh> People were shocked to see their lovely xhtml doctype go away
  299. # [17:10] <annevk> zcorpan_, is that another word for "way better"?
  300. # [17:10] <annevk> :p
  301. # [17:10] <webben> SadEagle: Not many in HTML.
  302. # [17:11] <zcorpan_> annevk: perhaps :)
  303. # [17:11] <zcorpan_> annevk: did you get any interesting questions?
  304. # [17:12] <annevk> there were lots of questions throughout the presentation about details of how things work
  305. # [17:12] <annevk> <input type=file> support for multiple files came up again
  306. # [17:12] <annevk> people want that badly it seems
  307. # [17:12] <zcorpan_> interesting
  308. # [17:13] <annevk> question about server-sent events and a better version of HTTP because HTTP is not that fit for it currently
  309. # [17:13] <annevk> (max nr of connections, etc.)
  310. # [17:18] <annevk> krijnh, they didn't really trip, did they?
  311. # [17:18] <hsivonen> is the max # connections thing even useful anymore? is it there just because it has always been there?
  312. # [17:18] <annevk> it's useful for servers
  313. # [17:19] <krijnh> annevk: nah, not really
  314. # [17:19] <annevk> i believe, because it makes it harder to DOS them
  315. # [17:19] <hsivonen> annevk: it seems to me it is the author side that wants to work around the limit, though
  316. # [17:20] <annevk> yeah, doesn't necessarily mean servers are ready i guess
  317. # [17:21] <annevk> but i don't know too much about it, i hope other people will solve it...
  318. # [17:21] <annevk> for server-sent events it's pretty easy to work around using access control and several subdomains...
  319. # [17:23] <webben> Dashiva: Maybe it's a missing feature, yes. Not entirely sure whether the Lynx devs would regard it as such or not.
  320. # [17:26] <jwalden> "I love the irony of the fact that we just renamed _global_ storage to _local_ storage without changing anything of the semantics..."
  321. # [17:26] <Philip`> If you want multiple Lynx windows, just run them inside screen
  322. # [17:26] * webben can't find any discussion of it on the lynx-dev windows.
  323. # [17:27] <webben> *lynx-dev mailing list
  324. # [17:28] <webben> except this discussion of JS where a user discusses preventing new windows opened by JS: http://lists.gnu.org/archive/html/lynx-dev/2002-03/msg00028.html
  325. # [17:28] <webben> (in iCab)
  326. # [17:30] <Dashiva> Well, as long as they don't try to force their one-window approach on the rest of the web, they're free to do whatever they want :)
  327. # [17:34] <annevk> http://planet.html5.org/
  328. # [17:35] <Philip`> annevk: Thanks :-)
  329. # [17:35] <Philip`> (Doesn't actually work since my DNS has updated yet, though...)
  330. # [17:35] <Philip`> s/has/hasn't/
  331. # [17:38] * Philip` still wonders if he's missing some point for http://krijnhoetmer.nl/irc-logs/whatwg/20080208#l-522
  332. # [17:41] <annevk> i'm not sure why html5lib does that, but it does seem the most useful solution given <style scoped>
  333. # [17:42] <zcorpan_> ie and opera keep the style in table. mozilla moves it outside. webkit moves it to head.
  334. # [17:44] <krijnh> annevk: heb je msn in de buurt?
  335. # [17:44] <annevk> pidgin
  336. # [17:44] * zcorpan_ also notes that <table><style scoped> could be useful for column alignment when someone invents a working css solution for that
  337. # [17:45] <Philip`> <table><script> has the same issue in html5lib/validator.nu
  338. # [17:46] <zcorpan_> i think scripts need to work in tables given document.write and roundtripping
  339. # [17:47] <Philip`> but I can't find any other elements that do that
  340. # [17:47] <annevk> i'd expect <title> once we remove the crazy behavior HTML5 specifies for it now
  341. # [17:47] <Philip`> and unless I'm being stupid, style and script fall into the "in table -> anything else" case and should get foster-parented instead of being added to the current (table) node
  342. # [17:48] <annevk> you're right
  343. # [17:48] <zcorpan_> who's gonna send email?
  344. # [17:48] <annevk> i think the way validator.nu and html5lib implement <style> and <script> gives you this behavior instead of what HTML5 defines
  345. # [17:49] * zcorpan_ sends email
  346. # [17:49] <annevk> zcorpan_, seems you're volunteering
  347. # [17:49] <annevk> right
  348. # [17:49] <annevk> :p
  349. # [17:49] <Philip`> Why don't they do <textarea> the same as <style>/etc?
  350. # [17:49] <annevk> <style>/<script> are handled together inhead or so
  351. # [17:50] <annevk> now you're making me check :(
  352. # [17:50] <Philip`> Oh, they get handled by jumping through the "in head" state...
  353. # [17:51] <annevk> yeah
  354. # [17:51] <annevk> and we're using this appendToHead method that does things wrongly in face of <table>
  355. # [17:52] <annevk> (or maybe not)
  356. # [17:52] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  357. # [17:53] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  358. # [17:53] <annevk> 'self.parser.parseError("two-heads-are-not-better-than-one")' :-)
  359. # [18:07] <zcorpan_> annevk: http://simon.html5.org/presentations/ now has some plain text link love
  360. # [18:12] * Joins: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  361. # [18:15] <annevk> Philip`, you missed <base>, <link>, and <meta>
  362. # [18:17] <annevk> Firefox behavior for those is weird
  363. # [18:17] <Philip`> zcorpan_: I don't think your comment about <table><script>document.write(rows)</script></table> is right - regardless of where the script element is added to the DOM, document.write will add characters to the input stream just after the </script> and hence in the "in table" mode
  364. # [18:18] <jwalden> I fail at life
  365. # [18:18] <jwalden> somehow I always manage to forget to add +whatwg to my posts
  366. # [18:18] <jwalden> so I get "held for moderation" delays
  367. # [18:19] <Philip`> Those delays are infinite
  368. # [18:19] <jwalden> sigh
  369. # [18:19] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com) (Read error: 104 (Connection reset by peer))
  370. # [18:19] <jwalden> so I get to spam the non-whatwg receivers with a second copy :-\
  371. # [18:19] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  372. # [18:20] <gsnedders> jwalden: Resent-To!
  373. # [18:20] <gsnedders> jwalden: don't totally resend it :P
  374. # [18:20] <jwalden> yes, I send my resent to the moderation feature of the list
  375. # [18:20] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com) (Client Quit)
  376. # [18:22] * jwalden doesn't see a way to do that in Thunderbird
  377. # [18:22] * jwalden wonders just how many muas actually make doing that easy
  378. # [18:23] <annevk> it will take people a split-second to recognize dupes
  379. # [18:23] * jwalden does things the easy way
  380. # [18:23] <annevk> don't worry about it
  381. # [18:29] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  382. # [18:35] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  383. # [18:42] <zcorpan_> hsivonen: in order to avoid angry users who don't read the about page, perhaps the "valid" message should say that the result might change over time? (i don't know if you've had angry users, perhaps you're being clear enough about it)
  384. # [18:42] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  385. # [18:42] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  386. # [18:43] <zcorpan_> (the message in the html5 interface is clear but in the generic interface less so)
  387. # [18:51] * Joins: DxSadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  388. # [18:52] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) (Read error: 104 (Connection reset by peer))
  389. # [18:53] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  390. # [18:54] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  391. # [19:03] * Joins: Thezilch (i=fuz007@cpe-67-49-89-123.socal.res.rr.com)
  392. # [19:04] * Quits: starjive (i=beos@81-233-18-73-no30.tbcn.telia.com)
  393. # [19:28] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  394. # [19:29] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  395. # [19:31] * Joins: webben__ (n=benh@82.152.229.45)
  396. # [19:32] * Quits: webben (n=benh@82.152.229.45) (Read error: 104 (Connection reset by peer))
  397. # [19:48] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
  398. # [20:16] * Joins: RockinRoel (n=newbie@d54C625E5.access.telenet.be)
  399. # [20:16] <RockinRoel> hello
  400. # [20:25] <annevk> hi
  401. # [20:26] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  402. # [20:26] * Joins: eseidel (n=eseidel@72.14.224.1)
  403. # [20:27] <RockinRoel> I read something in the logs about CanvasRenderingContext2D.prototype not working in Safari
  404. # [20:30] <annevk> dunno about that
  405. # [20:32] <DxSadEagle> may be look at Philip`'s test reports?
  406. # [20:32] * RockinRoel I find it sort of annoying that I can't do:
  407. # [20:33] <RockinRoel> CanvasRenderingContext2D.prototype.newFunction() = function() { etcŠ
  408. # [20:33] <DxSadEagle> get a context object, and access it's __proto__
  409. # [20:34] <RockinRoel> does __proto__ work on Safari?
  410. # [20:34] <RockinRoel> I heard that it did on Firefox, but not Safari
  411. # [20:34] <DxSadEagle> it does.
  412. # [20:35] <RockinRoel> cool. is this a Safari bug actually?
  413. # [20:35] <DxSadEagle> It is a non-standard mozilla extension, but JSC supports it. I think Opera doesn't.
  414. # [20:35] <DxSadEagle> Depends on your definition of bug and your reading of not-yet-finished ECMA-bindings-for-DOM document.
  415. # [20:36] <RockinRoel> well, I thought that every javascript object needed to have a prototype
  416. # [20:36] <RockinRoel> by definition
  417. # [20:37] <RockinRoel> I'll check it out
  418. # [20:37] <DxSadEagle> What makes you think it should be visible in this way?
  419. # [20:37] <RockinRoel> I'm sorry, I don't understand that
  420. # [20:38] <DxSadEagle> CanvasRenderingContext2D isn't even a constructor, so the convention about constructor's .prototype pointing to the prototype of constructed objects doesn't even apply.
  421. # [20:41] <RockinRoel> yet every browser assumes that CanvasRenderingContext2D is an object, except Safari?
  422. # [20:42] <DxSadEagle> What does it being an object have to do with anything? And it's specified as an -interface-.
  423. # [20:43] <RockinRoel> yes, sorry, I haven't quite gotten the hang of "advanced" javascript yet
  424. # [20:43] * Quits: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  425. # [20:44] <DxSadEagle> anyway, just try __proto__. I am not sure they didn't laze out and put stuff straight on the object, but this is all a side conversation.
  426. # [20:49] * Quits: eseidel (n=eseidel@72.14.224.1) (Read error: 104 (Connection reset by peer))
  427. # [20:50] * Parts: RockinRoel (n=newbie@d54C625E5.access.telenet.be)
  428. # [20:57] * Quits: tantek (n=tantek@71-92-201-252.dhcp.gldl.ca.charter.com)
  429. # [21:05] * Joins: tantek (n=tantek@99-200-200-196.area2.spcsdns.net)
  430. # [21:12] * Quits: webben__ (n=benh@82.152.229.45)
  431. # [21:16] * Quits: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com) ("Partying in teh intarwebs")
  432. # [21:16] <Philip`> http://philip.html5.org/tests/canvas/suite/tests/results.html#2d.type.extend
  433. # [21:16] <Philip`> Safari fails because window.CanvasRenderingContext2D doesn't exist
  434. # [21:17] <Philip`> (which I'm considering a bug, though I don't know what spec justifies that)
  435. # [21:24] <DxSadEagle> Philip`: I think ECMA bindings-for-DOM will eventually justify that
  436. # [21:35] * Quits: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com) ("all I want to do is be a full time online furry")
  437. # [21:36] * Joins: Ketsuban (n=ketsuban@cpc2-oxfd8-0-0-cust335.oxfd.cable.ntl.com)
  438. # [21:40] <annevk> http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.html (people asking for a sane version of SVG)
  439. # [21:41] * Quits: tantek (n=tantek@99-200-200-196.area2.spcsdns.net)
  440. # [21:50] <hsivonen> hmm. why do html5lib and Validator.nu interoperate against the spec in the <table><style> case? did the spec change after the summer or something?
  441. # [21:53] <hsivonen> zcorpan: Given current user reactions, the "Highly Experimental" bit in the HTML5 facet may even suggest that the service is less ready for action than it actually is.
  442. # [21:54] <hsivonen> zcorpan: So far I haven't had users complain about schema changes.
  443. # [21:55] <annevk> hsivonen, I think we share an implementation detail
  444. # [21:55] <hsivonen> that's odd
  445. # [21:56] <annevk> where can you see the output of Validator.nu?
  446. # [21:56] <hsivonen> parsetree.validator.nu
  447. # [21:56] <hsivonen> http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/style-in-table.html
  448. # [21:57] <annevk> I wanted to test <table><base> but this makes that harder
  449. # [21:58] <hsivonen> yeah, parsetree.v.nu UI sucks. it is a quick and dirty hack
  450. # [21:59] <annevk> actually, why does everyone suggest this is something weird in HTML5?
  451. # [21:59] <annevk> hmm
  452. # [22:00] <hsivonen> case IN_BODY:
  453. # [22:00] <hsivonen> } else if ("base" == name || "link" == name || "meta" == name
  454. # [22:00] <hsivonen> || "style" == name || "script" == name) {
  455. # [22:00] <hsivonen> // Fall through to IN_HEAD
  456. # [22:00] <Philip`> That sounds like what the spec says to do
  457. # [22:01] <annevk> the spec also suggests to append <style> and <script> etc. to the current node
  458. # [22:01] <annevk> which is <table> and not the foster parent afaict
  459. # [22:01] <Philip`> The in-table bit says that when you would normally append to the current node, you actually append to the foster parent instead
  460. # [22:02] <hsivonen> Philip`: except the foster parenting exception is only implemented IN_BODY, so stuff that falls through to IN_HEAD isn't affected
  461. # [22:02] <Philip`> so that should happen regardless of the route you take before trying to append to the current node
  462. # [22:02] <Philip`> hsivonen: Ah, okay
  463. # [22:03] <hsivonen> hmm. I did implement forster parenting for <base>
  464. # [22:03] <hsivonen> hmm.
  465. # [22:03] <hsivonen> I suppose I should change appendToCurrentNodeAndPushElement to appendToCurrentNodeAndPushElementMayFoster even IN_HEAD if the spec stays the way it is
  466. # [22:04] <annevk> the current spec shouldn't stay the way it is
  467. # [22:04] <Philip`> Why change in IN_HEAD rather than changing it globally?
  468. # [22:04] <hsivonen> (from my method naming you can probably tell that I'm using IDE autocomplete :-)
  469. # [22:04] <Philip`> It only takes one boolean variable test per call to work out whether the special case applies
  470. # [22:04] <Philip`> which shouldn't be at all expensive
  471. # [22:05] <annevk> oh well, thanks to Philip` we uncover some more spec bugs :)
  472. # [22:06] * Philip` has quite a few functions named "f"
  473. # [22:06] <hsivonen> Philip`: it's not a boolean on the runtime stack, so presumably one wouldn't want to poke the heap without reason
  474. # [22:07] <hsivonen> I don't remember if calling the MayFoster variants from outside IN_BODY has any ill effects beyond extra memory access, though
  475. # [22:07] * Philip` really hopes you can't get the append-to-current-node-but-actually-append-to-foster-parent-instead thing inside the adoption agency algorithm
  476. # [22:09] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  477. # [22:12] <hsivonen> gotta love other people's source: the XML parser I use has and unhandled case when a CDATA section end aligns across a read buffer boundary
  478. # [22:13] <hsivonen> of course someone tried to validate a page where the ]]> fell across the read buffer boundary...
  479. # [22:19] * Joins: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  480. # [22:19] <Hixie> annevk: html, html+, html2, html 3.2, html4, html5. it's the fifth major revision.
  481. # [22:20] <annevk> Y! rejected the MS bid
  482. # [22:20] * annevk didn't know
  483. # [22:20] <gsnedders> In need of a shorter to-do list.
  484. # [22:20] <hsivonen> annevk: URL?
  485. # [22:20] * gsnedders is in need of a shorter to-do list (that makes more sense).
  486. # [22:20] <hsivonen> and I just got around to writing a Flickr backup utility
  487. # [22:20] <annevk> found through news.google.com: http://afp.google.com/article/ALeqM5hm0kvkhjrjiA4hTdisbB5PYpTTlg
  488. # [22:21] <hsivonen> annevk: thanks
  489. # [22:21] <annevk> also: http://news.google.com/?ncl=1130039008
  490. # [22:23] <Philip`> gsnedders: Put deadlines on all the tasks in your list, and then don't work on them, and once they've passed their deadlines and the world hasn't ended you can assume that they're obviously not really that important and you can just delete them from the list
  491. # [22:23] <gsnedders> Philip`: So no http-parsing spec or spec-gen clone, then
  492. # [22:25] <Philip`> Hmm, it's harder if the things on your list are things you actually want to do
  493. # [22:25] <gsnedders> Philip`: yeah, that's the issue for most
  494. # [22:25] <gsnedders> it's not really the length: the issue is that what I put on it and don't deal with straight away takes _ages_ to deal with, so even having c. 20 items on it is enough to last months.
  495. # [22:26] <gsnedders> Philip`: one of the things has sorted itself out by the emailing just bouncing, so I can't deal with it :P
  496. # [22:28] <annevk> oh, more good news, the writers strike might finally be over
  497. # [22:32] * gsnedders almosts asks a question about XMLHttpRequest, then realises the answer is two lines above where he was reading
  498. # [22:39] <gsnedders> annevk: do current implementations return the correct ExceptionCode?
  499. # [22:40] <annevk> prolly not
  500. # [22:43] * gsnedders wishes there was a better way that wasn't impl specific to test HTTP parsing
  501. # [22:45] <Philip`> Is the XHR HTTP parser always the same as the normal HTTP parser?
  502. # [22:45] <gsnedders> Philip`: in the case of IE, Fx, Saf/Mac (and I think win too), and Opera yes
  503. # [22:45] <Philip`> (and not e.g. something that gets handed a single string of headers from the network code, and splits it into key:value lines itself)
  504. # [22:46] <Philip`> Ah, okay, that sounds alright then
  505. # [22:47] * gsnedders wonders how to test non-strict server-side parsers
  506. # [22:47] <gsnedders> strict request parsers on servers are easy to test: you just check you get 400 back :P
  507. # [22:48] * Philip` likes how the multipage HTML5 spec is nearly XML, so you can just fix a few bits in the header and then use a standard XML parser
  508. # [22:49] <annevk> Philip`, the solution is to make an HTML5 parser that is faster than an XML parser
  509. # [22:49] <gsnedders> (FWIW: the current intention is to say: "This specification RECOMMENDS using a non-strict parser for parsing responses, and a strict parser for parsing request.")
  510. # [22:50] <Philip`> annevk: The problem is that I'm parsing the HTML5 spec in order to create an HTML5 parser - I wouldn't have to do this if there was an HTML5 parser already :-p
  511. # [22:50] <Philip`> (*if there was an HTML5 parser in Perl already)
  512. # [22:51] <annevk> dogfood :p
  513. # [22:52] <Philip`> Chicken/egg
  514. # [22:52] <Philip`> so it's more like fox food than dog food
  515. # [22:53] <gsnedders> Philip`: egg.
  516. # [22:53] <annevk> hmm, http://habrahabr.ru/blog/webstandards/28107.html
  517. # [22:56] <DxSadEagle> annevk: I could spot-translate stuff if you care, though the markup should be mostly self-explanatory
  518. # [22:57] <annevk> yeah, he translated my article, I'm mostly interested in the comments :)
  519. # [22:57] <virtuelv_> Google translate has become quite good at russian-english
  520. # [22:57] <annevk> if there are interesting comments that would be nice to know
  521. # [22:58] * annevk tries
  522. # [22:58] <DxSadEagle> There is a bug report about input events lacking the last letter :-)
  523. # [22:58] <virtuelv_> http://www.google.com/translate?u=http%3A%2F%2Fhabrahabr.ru%2Fblog%2Fwebstandards%2F28107.html&langpair=ru%7Cen&hl=en&ie=UTF8 fwiw
  524. # [22:59] <virtuelv_> the comments mostly seem to be a giant flamewar :)
  525. # [22:59] * DxSadEagle looks for laughs
  526. # [23:00] <virtuelv_> and people thinking annevk is a girl :P
  527. # [23:01] <annevk> even in Russia, crap :)
  528. # [23:02] <gsnedders> annevk: is male? oh.
  529. # [23:02] <gsnedders> :P
  530. # [23:02] <annevk> hehe, someone posted a photo to show otherwise
  531. # [23:02] <gsnedders> </sarcasm>
  532. # [23:02] <Philip`> annevk: The cowpath is clear, so you should just pave it
  533. # [23:02] <DxSadEagle> yeah, plus dispute on what exactly google suggest means, and complaints about xhtml2 non-support(?) in Opera. So yes, the oninput bug report is the most relevant part :-)
  534. # [23:03] * DxSadEagle laughs at the translation.
  535. # [23:05] <DxSadEagle> virtuelv_: It translates a 'heck' exclamation (which is more like 'crap', etc. in meaning) as features :p
  536. # [23:07] <virtuelv_> DxSadEagle: there's also this: http://google.com/translate_t?hl=en&ie=UTF8&text=Retrieved&langpair=en%7Cde
  537. # [23:08] <annevk> i think we fixed the oninput thingie
  538. # [23:08] * DxSadEagle tries babelfish/systran, for comparison
  539. # [23:09] <Philip`> Google Translate seems slightly more open to abuse than other translation services
  540. # [23:10] <DxSadEagle> heh. "Error decoding translated text."
  541. # [23:10] <Philip`> http://www.news.com/8301-13577_3-9857280-36.html
  542. # [23:17] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  543. # [23:26] <Philip`> http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http://philip.html5.org/misc/fostered-adoption.html vs http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/fostered-adoption.html
  544. # [23:27] <Philip`> They disagree in the number of parse errors
  545. # [23:27] <Philip`> I'm not sure if they're correct according to the spec or not...
  546. # [23:29] * weinig|NAP is now known as weinig
  547. # [23:36] <hsivonen> Philip`: yeah, disagreeing on the exact number of tree construction errors is a known thing when # of errors > 0
  548. # [23:38] <Philip`> http://philip.html5.org/misc/fostered-select.html
  549. # [23:38] <Philip`> HTML5 and html5lib and Validator.nu disagree with all browsers
  550. # [23:40] * Philip` would quite like a graph of mode transitions
  551. # [23:41] <Dashiva> Didn't someone make that a few months ago?
  552. # [23:42] <annevk> not for the parser
  553. # [23:42] <Philip`> http://canvex.lazyilluminati.com/misc/tokeniser_states.png ?
  554. # [23:43] <Philip`> That's only tokeniser
  555. # [23:45] <Dashiva> The parser text is too unstructured to generate from?
  556. # [23:45] * gsnedders bursts out laughing at Philip` suggesting annevk should pave the cowpath (regarding being a woman)
  557. # [23:47] * Dashiva wonders which the photo posted "to show otherwise" was supposed to support
  558. # [23:47] <Dashiva> *which gender
  559. # [23:47] <Philip`> Dashiva: I've already solved that structure problem, by writing a Perl script to translate the HTML/English into OCaml :-)
  560. # [23:47] <Dashiva> So we'll have a parser graph by tomorrow then?
  561. # [23:48] <Philip`> Hopefully sooner than that
  562. # [23:49] <Philip`> ...if I can work out how to write to files
  563. # [23:50] * gsnedders needs to choose between chemistry and psychology for the final year of school
  564. # [23:50] <Dashiva> They're basically the same thing
  565. # [23:51] <Dashiva> Just a question of where you want your chemical reactions to be taking place
  566. # [23:51] <gsnedders> And in what way you study the affects of them :)
  567. # [23:51] <Philip`> Does psychology involve some kind of science?
  568. # [23:53] <gsnedders> Philip`: it's rather unclear whether it's doing it as an arts subject or as a science subject, but it looks as if it's a mixture of both
  569. # [23:59] <kig> Philip`: ocaml html parser?
  570. # Session Close: Sun Feb 10 00:00:00 2008

The end :)