/irc-logs / freenode / #whatwg / 2009-09-18 / end

Options:

  1. # Session Start: Fri Sep 18 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:00] * Joins: slightlyoff (n=slightly@72.14.229.81)
  4. # [00:01] * Joins: jamesr (n=jamesr@nat/google/x-mddprglllqdbihdj)
  5. # [00:02] * tantekc withholds comments about sending lots of emails and what that does or does not imply.
  6. # [00:02] <jamesr> Hixie: as a meta-point on the storage mutex, it seems like it's a bad idea to encourage browser venders to ship major releases with not-fully-baked spec implementations if that short-circuits the rest of the spec process
  7. # [00:02] <gsnedders> jgraham_: Mainly just complain.
  8. # [00:02] <jamesr> while it's great to get UA feedback it's not so great if that becomes the end of the entire process
  9. # [00:03] <jamesr> maybe specs should be namespaced until there's some degree of consensus that it could work out?
  10. # [00:03] <jamesr> i'm sure this has been hashed through before (i'm a bit new to the w3 working group process) but there are way too many web standards and de facto web standards that are complete shite but unchangable because browser X shipped a major release with it and then got market share
  11. # [00:04] <annevk2> the theory that worked so far is that if there's more than 2 impl it's good enough
  12. # [00:04] <jamesr> 1 impl seems to be enough if it ships as a 'major' release
  13. # [00:04] <annevk2> that is, it gave both reasonable quality and progress
  14. # [00:05] <annevk2> jamesr, no
  15. # [00:05] <annevk2> jamesr, e.g. globalStorage which Firefox shipped with is gone
  16. # [00:05] <jamesr> yeah, but according to Hixie's email the localStorage API is set in stone because IE8 shipped with it
  17. # [00:05] <annevk2> not just IE
  18. # [00:05] <annevk2> also Firefox and Safari
  19. # [00:06] <jamesr> that's not what his email said
  20. # [00:06] <tantekc> whoa really?
  21. # [00:06] * tantekc is now known as tantek
  22. # [00:06] <annevk2> jamesr, I guess it didn't list all the reasons then
  23. # [00:07] <annevk2> and arguments
  24. # [00:07] <jamesr> "However, localStorage is more or less fixed because Microsoft shipped it and their release cycle means they won't ship changes to it before it is solidly embedded in too many sites to risk changes."
  25. # [00:07] <tantek> HTML5 is already being saddled by legacy implementations of the *new* stuff?
  26. # [00:07] <gsnedders> tantek: That happened a while ago.
  27. # [00:07] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  28. # [00:07] <annevk2> I shouldn't say "I guess", I read the email
  29. # [00:08] * Joins: farhan (n=farhanma@host81-129-217-229.range81-129.btcentralplus.com)
  30. # [00:08] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 104 (Connection reset by peer))
  31. # [00:09] * Parts: itpastorn (n=gunther@139.57.227.87.static.th.siw.siwnet.net)
  32. # [00:09] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  33. # [00:09] * Quits: farhan (n=farhanma@host81-129-217-229.range81-129.btcentralplus.com) (Client Quit)
  34. # [00:09] <jamesr> annevk2: it doesn't seem like the other implementors (Mozilla/Apple) are in love with the current API either
  35. # [00:09] <tantek> jamesr - re: namespaced. there is vendor prefixing in CSS to reduce this kind of problem there: http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords
  36. # [00:09] * Quits: heycam (n=cam@210-84-56-211.dyn.iinet.net.au) ("bye")
  37. # [00:10] <jamesr> tantek: right - why not use that for all new APIs before they get a bit of bake time? if a vendor shipped the 'document.experimentalLocalStorage API' then i don't think anyone would be quite so worried about mucking with it
  38. # [00:11] * Joins: tantekc (n=tantek@adsl-70-231-142-66.dsl.snfc21.sbcglobal.net)
  39. # [00:11] <annevk2> jamesr, I guess not
  40. # [00:12] <jamesr> the situation now means that even if everyone has the best intentions and does everything right there's still a chance that we get stuck with a bad API and can never ever fix it
  41. # [00:12] <annevk2> you always have that
  42. # [00:12] <jamesr> you can try to discourage it
  43. # [00:13] <annevk2> even if you have bake time it can still happen
  44. # [00:13] <annevk2> e.g. localStorage has been around for a long time
  45. # [00:13] <annevk2> it's only recently that it attracted fierce opponents
  46. # [00:13] * tantekc notes that the CSS vendor prefixes are not bound to URLs.
  47. # [00:14] <tantekc> annevk2 - the CSS vendor prefixes have allowed experimenting without saddling with legacy.
  48. # [00:14] <tantekc> especially in some particularly difficult/useful areas like border-radius etc.
  49. # [00:14] <tantekc> nevermind animations and transforms
  50. # [00:14] <jamesr> but you can't, as a browser developer, experiment with new APIs without running the risk of locking it into place
  51. # [00:14] <annevk2> CSS vendor prefixes are scattered around all over the Web
  52. # [00:14] <gsnedders> jamesr: There's a fair amount of unwillingness to change -moz-border-radius to match the current spec, IIRC. The problem arises once something is widely used, whether or not it is prefixed. (Although it is true that in the long-run a non-prefixed version could work.)
  53. # [00:14] <annevk2> and we actually get bug reports on them
  54. # [00:14] <tantekc> annevk2 - right, but they are not preventing "proper" use of non-prefixed keywords
  55. # [00:14] <annevk2> (for the -moz- and -webkit- ones)
  56. # [00:15] * gsnedders blinks
  57. # [00:15] <gsnedders> seriously!?
  58. # [00:15] <gsnedders> wow.
  59. # [00:15] <jamesr> gsnedders: but that's better than if it had been border-radius from the beginning. then there would be no possibility to change border-radius
  60. # [00:15] <tantekc> precisely jamesr
  61. # [00:15] <gsnedders> jamesr: Then Moz ends up with two impls, which is less than ideal
  62. # [00:16] <tantekc> gsnedders, the ideal is the enemy of the quite good.
  63. # [00:16] <gsnedders> Then you get into the debates about when to remove the prefix
  64. # [00:16] <tantekc> gsnedders - I call theoretical
  65. # [00:16] <annevk2> I'm not really convinced CSS is that comparable
  66. # [00:16] <tantekc> gsnedders - I haven't seen anything like that in CSS
  67. # [00:16] <annevk2> for one there's often experimental CSS around without a public spec that already received a bunch of attention
  68. # [00:16] <gsnedders> tantekc: I have.
  69. # [00:17] <tantekc> annevk2 - the DOM APIs could have similarly had x- prefixes
  70. # [00:17] <annevk2> so the new properties have received far less public scrutiny compared to say localStorage
  71. # [00:17] <tantekc> the history of using vendor prefixes is quite old actually
  72. # [00:17] <tantekc> IETF x- stuff
  73. # [00:17] <annevk2> and therefore it's all the more likely it'll change
  74. # [00:17] <tantekc> not sure why the markup folks have not used it...
  75. # [00:17] <annevk2> x- stuff is also an epic fail imo
  76. # [00:17] <jamesr> gsnedders: i agree that -vendor-prefix is not perfect but i think it's better
  77. # [00:17] <gsnedders> tantekc: For one example, look at some of the comments on IE8 prefixing IE-origin CSS3 properties
  78. # [00:17] <annevk2> there's x- stuff all over the place
  79. # [00:17] <annevk2> that you actually need to use and cannot be changed to x-less
  80. # [00:18] <tantekc> annevk2 - x- stuff gradually transitions to non x-
  81. # [00:18] <tantekc> e.g. image/png
  82. # [00:18] <gsnedders> tantekc: There are some x prefixed charset names that have been around for decades for which support is still eeded
  83. # [00:18] <tantekc> there's always going to be early "x-" stuff that hasn't matured to the point of not needing a prefix - that's how the system works
  84. # [00:18] <tantekc> gsnedders, like for example?
  85. # [00:19] <tantekc> with what stats?
  86. # [00:19] <annevk2> x-x-big5 is pretty widely used
  87. # [00:19] <annevk2> as is x-euc-jp or some such
  88. # [00:19] <annevk2> x-mac-roman etc.
  89. # [00:19] <tantekc> start writing that stuff up on a wiki with URLs to examples and I'll believe you
  90. # [00:19] <tantekc> otherwise it's just hearsay
  91. # [00:19] <Hixie> jamesr: not much we can do about it
  92. # [00:19] <annevk2> see philip's charset stats and see web encodings on the WHATWG Wiki
  93. # [00:19] * tantekc gave up arguing with theoretical (or undocumented) examples
  94. # [00:20] <annevk2> HTML form submission uses an x- prefixed media type
  95. # [00:20] <gsnedders> tantekc: http://philip.html5.org/data/charsets.html#charset-x-euc-jp
  96. # [00:20] <gsnedders> tantekc: There's a list of URLs.
  97. # [00:20] <tantekc> thank you gsnedders
  98. # [00:21] <annevk2> Microsoft recently spread an x-ua-compatible all over the Web
  99. # [00:22] * annevk2 is not a fan of prefixes
  100. # [00:22] <annevk2> (well, except when it's truly experimental, but it hardly ever is)
  101. # [00:22] <annevk2> (usually it's just to hard to register a name)
  102. # [00:23] <jamesr> Hixie: :(
  103. # [00:23] <tantekc> annevk2 "recently" is part of how x- works - that's not a criticism.
  104. # [00:24] <annevk2> it is
  105. # [00:24] <annevk2> x- is for experimental purposes, not for widescale deployment
  106. # [00:26] <tantekc> experimental is orthogonal to widescale
  107. # [00:27] * Quits: fishd (n=darin@nat/google/x-igxwatemunjkwfno) (Read error: 110 (Connection timed out))
  108. # [00:27] * Quits: tantek (n=tantek@adsl-71-141-229-148.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  109. # [00:27] * tantekc is now known as tantek
  110. # [00:27] * Quits: MikeSmith (n=MikeSmit@EM114-48-135-155.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  111. # [00:29] * Joins: MikeSmith (n=MikeSmit@EM114-48-205-225.pool.e-mobile.ne.jp)
  112. # [00:34] * Quits: tantek (n=tantek@adsl-70-231-142-66.dsl.snfc21.sbcglobal.net)
  113. # [00:39] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  114. # [00:47] * Joins: ap_ (n=ap@17.246.19.174)
  115. # [00:47] * Quits: ap (n=ap@17.246.19.174) (Read error: 131 (Connection reset by peer))
  116. # [00:48] * ap_ is now known as ap
  117. # [00:56] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 113 (No route to host))
  118. # [01:00] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  119. # [01:03] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  120. # [01:03] * Joins: Rik`_ (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  121. # [01:06] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 113 (No route to host))
  122. # [01:06] * Quits: Rik`_ (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 60 (Operation timed out))
  123. # [01:07] * Joins: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz)
  124. # [01:07] * Quits: annodomini (n=lambda@wikipedia/lambda)
  125. # [01:16] * Quits: benward (n=benward@nat/yahoo/x-ajftldheqpawllff) (Read error: 110 (Connection timed out))
  126. # [01:17] * Joins: boblet_ (n=boblet@p1254-ipbf304osakakita.osaka.ocn.ne.jp)
  127. # [01:22] * Joins: dimich (n=dimich@74.125.59.73)
  128. # [01:30] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 113 (No route to host))
  129. # [01:37] * Joins: alyoshka (n=anime4ch@67.174.150.213)
  130. # [01:38] <alyoshka> I think we have a problem with the new <details>
  131. # [01:38] <alyoshka> are we allowed to have nested <details>?
  132. # [01:39] <alyoshka> here's a short description of the problem I posted on the html5doctor blog: http://html5doctor.com/september-html5-spec-changes/comment-page-1/#comment-1028
  133. # [01:39] * Quits: dbaron (n=dbaron@nat/mozilla/x-hwihhpqdbzpugwht) ("8403864 bytes have been tenured, next gc will be global.")
  134. # [01:41] * Quits: TabAtkins (n=chatzill@adsl-76-195-204-109.dsl.hstntx.sbcglobal.net) (Read error: 113 (No route to host))
  135. # [01:42] <Hixie> alyoshka: yeah nesting <details> requires a browser that supports the new parser
  136. # [01:43] <Hixie> alyoshka: but nesting <details> is pretty crazy
  137. # [01:43] <Hixie> alyoshka: so that's not really a problem
  138. # [01:43] * Quits: dglazkov (n=dglazkov@nat/google/x-ufgzxstpiarfxobn)
  139. # [01:44] <alyoshka> well, I actually have a website where I nest <details>, but I guess the site just has too many details then (pun intended)
  140. # [01:44] <alyoshka> it's a rare case, but I've run into it
  141. # [01:44] <Hixie> i don't think you're using <Details> correctly then
  142. # [01:45] <Hixie> i don't think i've ever seen a disclosure triangle widget that had another one inside it
  143. # [01:45] <Hixie> that's really bad ui
  144. # [01:45] <alyoshka> in a way
  145. # [01:46] <alyoshka> the part that uses it is for admins
  146. # [01:46] <alyoshka> it contains the details for a record that may be useful to the admin
  147. # [01:47] <Hixie> fair enough
  148. # [01:47] <Hixie> well, the spec allows it
  149. # [01:47] <alyoshka> and nested are more technical details that only the developers need
  150. # [01:47] <Hixie> and it'll work once the parser is more widely deployed
  151. # [01:47] <Hixie> but it will indeed be problematic for now
  152. # [01:47] <Hixie> generally speaking i'm a bit scared of how much people are eager to use html5
  153. # [01:47] <Hixie> i'd rather people waited til CR
  154. # [01:47] <Hixie> so we were sure the spec was stable
  155. # [01:48] <alyoshka> so, I guess the solution for now is just to avoid nested <details> (even in the rare cases it might make some sense)
  156. # [01:48] * Quits: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  157. # [01:48] * Quits: starjive (i=beos@213-66-216-93-no30.tbcn.telia.com)
  158. # [01:49] <alyoshka> yeah, <details> is the only major thing I use that's not supported by default in browsers
  159. # [01:49] * nessy is now known as johnf1
  160. # [01:50] * johnf1 is now known as nessy
  161. # [01:50] <alyoshka> we used to do the same thing with DHTML anyways, now there's a (semi) standard way to do it, so why not (as long as you keep up with the spec)?
  162. # [01:50] <Hixie> because people won't do the parenthetical bit
  163. # [01:50] <Hixie> and we end up forced into decisions based on having to support the "legacy" content
  164. # [01:50] * Joins: webben (n=benh@91.85.72.193)
  165. # [01:51] <alyoshka> I agree, I don't recommend anyone using new elements right now because of the same reason
  166. # [01:52] <alyoshka> but I among other people who do keep up with the spec use it
  167. # [01:52] <alyoshka> for personal things and testing the spec
  168. # [01:53] <alyoshka> there's only one site that I use <details> on, and maybe three that use new sectioning content
  169. # [01:53] <alyoshka> *elements
  170. # [01:53] <alyoshka> not content
  171. # [01:54] <alyoshka> but the bright side to it is that people are enthusiastic about the new spec. must mean we're doing something right
  172. # [01:54] <Hixie> i hope so :-)
  173. # [01:55] <alyoshka> do you know if there are any other elements that browsers might vomit from <dd>?
  174. # [01:59] * Joins: jacobolus (n=jacobolu@dhcp-0019802748-5f-28.client.student.harvard.edu)
  175. # [01:59] * Quits: weinig (n=weinig@17.246.16.129)
  176. # [02:00] <Hixie> alyoshka: <dd> and <dt> as far as i'm aware are the only ones
  177. # [02:03] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  178. # [02:04] <alyoshka> except when inside a <dl> (just tested, so definition lists should be safe)
  179. # [02:08] <Hixie> how so?
  180. # [02:09] <Hixie> i don't understand what you mean
  181. # [02:10] <alyoshka> I mean <dd><dl><dt>term</dt><dd>definition</dd></dl></dd> seemed to work
  182. # [02:11] <Hixie> ah, yes
  183. # [02:12] <Hixie> you can substitute various elements for <dl> in that
  184. # [02:12] <Hixie> in most browsers, for table, <ol><li> would also "protect" the nested <dd>
  185. # [02:12] <Hixie> in html5 browsers, all elements described as "special" except <div>, <address>, and another that i forget off hand are "safe"
  186. # [02:13] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  187. # [02:20] <alyoshka> If I understood the spec correctly, if a <details> element contains no <dd> element, it is to be completely ignored, right?
  188. # [02:20] <Hixie> i don't think it says to ignore it per se
  189. # [02:21] <Hixie> but yeah it's not valid
  190. # [02:21] * Quits: BlurstOfTimes (n=blurstof@168.203.117.59) ("Leaving...")
  191. # [02:23] <alyoshka> I'm just wondering how a browser should behave if it comes accross <details><dt>summary</dt><p>content</p></details> or <details><p>content</p></details>
  192. # [02:23] * alyoshka goes to reread the spec
  193. # [02:24] * Quits: ap (n=ap@17.246.19.174)
  194. # [02:25] <boblet_> Hixie: I think the interest in using HTML5 is good—despite casualties real-world use is catching a lot of the edge cases
  195. # [02:25] * boblet_ is now known as boblet
  196. # [02:25] <Hixie> spec http://www.whatwg.org/specs/web-apps/current-work/#the-details-element-0
  197. # [02:25] * Joins: tantek (n=tantek@99.13.242.166)
  198. # [02:26] <alyoshka> "If there is no child dd element, then there are no details."
  199. # [02:26] <alyoshka> I would interpret that as not rendering anything there, but would that be correct?
  200. # [02:26] <Hixie> alyoshka: the rendering section is what matters as far as rendering goes
  201. # [02:27] <alyoshka> I'm doing it for this: http://code.google.com/p/fiks-html5/
  202. # [02:28] <alyoshka> although I wouldn't code invalid <details> elements, I just want to make my js handle all the possibilities
  203. # [02:29] <Hixie> yeah
  204. # [02:29] <Hixie> i gotta go afk for a bit, back in a few hours
  205. # [02:29] <Hixie> let me know if the rendering section isn't clear enough when i get back
  206. # [02:31] <alyoshka> I won't be here in a few hours, wrapping it up for the day in about half an hour, but yeah, the rendering doesn't seem to describe that case
  207. # [02:32] * Quits: ttepasse (n=ttepas--@dslb-084-060-012-022.pools.arcor-ip.net) ("?Q")
  208. # [02:33] <alyoshka> and before rendering, it'd help to know what the DOM should look like in that case too
  209. # [02:34] * Quits: tantek (n=tantek@99.13.242.166) (Read error: 145 (Connection timed out))
  210. # [02:35] * Joins: annodomini (n=lambda@c-75-69-96-104.hsd1.nh.comcast.net)
  211. # [02:36] * Quits: nessy (n=nessy@124-170-13-58.dyn.iinet.net.au) (Read error: 60 (Operation timed out))
  212. # [02:37] * Joins: nessy (n=nessy@124-170-205-120.dyn.iinet.net.au)
  213. # [02:38] * Joins: dglazkov (n=dglazkov@67.188.0.62)
  214. # [02:38] * Joins: wakaba_ (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  215. # [02:39] <boblet> alyoshka: apart from new element support in IE, what other major browser support issues are there?
  216. # [02:40] <boblet> (re: fiks-html5.js)
  217. # [02:40] * Quits: nessy (n=nessy@124-170-205-120.dyn.iinet.net.au) (Client Quit)
  218. # [02:41] <boblet> just details right? (plus some default styling)
  219. # [02:42] * Joins: tantekc (n=tantek@99.13.242.166)
  220. # [02:44] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  221. # [02:45] <alyoshka> boblet: yeah, so far it's new elements, <details>, and default styling
  222. # [02:46] <alyoshka> there's a lot in web forms 2, but my project is aiming for all except web forms 2
  223. # [02:46] <alyoshka> I believe WF2 belongs in a separate module
  224. # [02:52] * Quits: dglazkov (n=dglazkov@67.188.0.62) (Read error: 145 (Connection timed out))
  225. # [02:52] * dglazkov_ is now known as dglazkov
  226. # [02:53] * Joins: tantekc_ (n=tantek@99.13.242.166)
  227. # [02:55] * Quits: jianli (n=jianli@74.125.59.65) (Read error: 110 (Connection timed out))
  228. # [02:55] * Joins: jianli (n=jianli@74.125.59.73)
  229. # [03:00] <Hixie> alyoshka: if it doesn't describe the case, it might just mean there's nothing to describe :-)
  230. # [03:00] <Hixie> alyoshka: i notice it doesn't mention <dd> at al
  231. # [03:00] <Hixie> all
  232. # [03:01] <alyoshka> Hixie: which would mean that technically there's nothing there so it wouldn't render any details? Or would it?
  233. # [03:02] <Hixie> the rendering section says that <details> renders its first <dt>, and hides everything else when closed, and shows it all when open, iirc
  234. # [03:02] <Hixie> so the <dd> doesn't matter
  235. # [03:03] * Quits: tantekc (n=tantek@99.13.242.166) (Read error: 110 (Connection timed out))
  236. # [03:04] <alyoshka> so if there is no explicit <dd> it would still work by wrapping the rest in a dynamically created <dd>?
  237. # [03:05] <alyoshka> I'm just working with the DOM too, so I need to know how that looks too
  238. # [03:05] <Hixie> what i'm saying is that the <dd> is irrelevant
  239. # [03:06] <alyoshka> "If there is no child dd element, then there are no details." <- would that affect the DOM though?
  240. # [03:06] <Hixie> <details> <dt> A </dt> B </details> -- B is shown or hidden based on whether the details has an open attribute or not, A is always shown
  241. # [03:06] <alyoshka> ok, I guess that works
  242. # [03:06] <alyoshka> but nothing to hook into really if there is no <dd>
  243. # [03:07] <alyoshka> for backwards compatibility
  244. # [03:08] <alyoshka> that would obviously be the authors' problem though
  245. # [03:09] <Hixie> yeah
  246. # [03:09] <Hixie> maybe it should be changed
  247. # [03:09] <Hixie> i dunno
  248. # [03:09] * Joins: slightlyoff_ (n=slightly@72.14.229.81)
  249. # [03:09] <alyoshka> I think it should
  250. # [03:09] * Quits: slightlyoff_ (n=slightly@72.14.229.81) (Client Quit)
  251. # [03:09] <alyoshka> so that the two sections would be consistent
  252. # [03:10] <alyoshka> I gotta run now though
  253. # [03:10] <alyoshka> bye
  254. # [03:10] * Joins: slightlyoff_ (n=slightly@72.14.229.81)
  255. # [03:10] * Parts: alyoshka (n=anime4ch@67.174.150.213)
  256. # [03:11] * Quits: slightlyoff_ (n=slightly@72.14.229.81) (Client Quit)
  257. # [03:11] * Quits: tantekc_ (n=tantek@99.13.242.166) (Read error: 110 (Connection timed out))
  258. # [03:13] * Joins: crow (n=miketayl@user-0cdf5gs.cable.mindspring.com)
  259. # [03:14] * crow is now known as miketaylrrrrrrr
  260. # [03:14] * miketaylrrrrrrr is now known as miketaylrrrrr
  261. # [03:21] * Quits: cying_ (n=cying@70.90.171.153)
  262. # [03:22] * Joins: slightlyoff_ (n=slightly@72.14.229.81)
  263. # [03:23] * Quits: slightlyoff_ (n=slightly@72.14.229.81) (Client Quit)
  264. # [03:24] * Quits: slightlyoff (n=slightly@72.14.229.81) (Read error: 110 (Connection timed out))
  265. # [03:24] <MikeSmith> Hixie: thanks for the sotd change -- the wording is fine by me, better than what I suggested
  266. # [03:26] * Quits: tyoshino (n=tyoshino@220.109.219.244) ("Leaving...")
  267. # [03:31] <MikeSmith> I often use too many words where fewer will do
  268. # [03:31] <MikeSmith> IanJ is also powerful good at stating things succinctly in writing
  269. # [03:31] <MikeSmith> you guys should collaborate more
  270. # [03:38] * Quits: dglazkov (n=dglazkov@72.14.224.1)
  271. # [03:39] * Joins: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  272. # [03:41] * Quits: jacobolus (n=jacobolu@dhcp-0019802748-5f-28.client.student.harvard.edu) (Remote closed the connection)
  273. # [03:42] * Quits: Super-Dot (n=Super-Do@66-240-27-50.isp.comcastbusiness.net)
  274. # [03:46] * Joins: othermaciej_ (n=mjs@17.246.17.71)
  275. # [03:53] * Joins: weinig (n=weinig@17.246.16.129)
  276. # [04:03] * Quits: othermaciej (n=mjs@nat/apple/x-rnirwtkzdxrsnwin) (Read error: 110 (Connection timed out))
  277. # [04:03] * othermaciej_ is now known as othermaciej
  278. # [04:10] * Joins: nessy (n=nessy@hendrix.mega-nerd.net)
  279. # [04:11] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 113 (No route to host))
  280. # [04:15] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  281. # [04:18] * Quits: jamesr (n=jamesr@nat/google/x-mddprglllqdbihdj)
  282. # [04:19] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  283. # [04:22] * Quits: drunknbass_work| (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net) ("Bye!")
  284. # [04:23] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net) (Client Quit)
  285. # [04:25] * Quits: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  286. # [04:33] * Joins: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  287. # [04:35] <karlcow> [12:37] <MikeSmith> and karlcow does too a little
  288. # [04:35] <karlcow> I speak Mooish!
  289. # [04:38] * Quits: weinig (n=weinig@17.246.16.129)
  290. # [04:43] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  291. # [04:59] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  292. # [05:08] * Quits: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  293. # [05:09] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  294. # [05:10] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  295. # [05:12] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  296. # [05:14] <heycam> so what are 'dc' and 'ds'?
  297. # [05:20] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Connection timed out)
  298. # [05:21] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  299. # [05:21] * Joins: fishd_ (n=darin@72.14.224.1)
  300. # [05:24] <othermaciej> reserved for future use I guess?
  301. # [05:25] <othermaciej> but I'm not sure reserving them in the parsing rules is either necessary or helpful
  302. # [05:25] <othermaciej> <ds> might be for "stage direction" in a future resurrected <dialog>
  303. # [05:27] <heycam> haha
  304. # [05:27] <heycam> (that is a joke right?)
  305. # [05:29] * Quits: jwalden (n=waldo@nat/mozilla/x-cvyrlwqpxjvxltty) ("home")
  306. # [05:32] * fishd_ is now known as fishd
  307. # [05:33] * Quits: dpranke (n=Adium@nat/google/x-yuzyjszytwtbckwx) ("Leaving.")
  308. # [05:34] * Quits: othermaciej (n=mjs@17.246.17.71) (Remote closed the connection)
  309. # [05:34] * Joins: othermaciej (n=mjs@nat/apple/x-uxzbralcurhgqejp)
  310. # [05:35] <othermaciej> heycam: no -- it would be the way to include either literal stage directions or things like IRC lave/join notifications or /me actions or out-of-band timestamps from AIM logs or the like
  311. # [05:35] <heycam> huh, ok,
  312. # [05:35] <othermaciej> heycam: whether all that put together would be a good idea, I don't know
  313. # [05:35] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  314. # [05:36] <heycam> <-- heycam has joined #whatwg, stage left.
  315. # [05:38] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  316. # [05:39] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  317. # [05:39] * Joins: tantek (n=tantek@70.36.139.108)
  318. # [05:46] <tantek> Hixie, you said "i don't think i've ever seen a disclosure triangle widget that had another one inside it" - nested folders in any Finder list view, since the 1990s.
  319. # [05:46] <tantek> and any ftp/gopher/web interface that has sought to imitate that UI for browsing a hierarchical system of resources/files/objects etc
  320. # [05:51] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  321. # [05:53] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  322. # [05:53] * dglazkov_ is now known as dglazkov
  323. # [05:54] <othermaciej> tantek: the outline view is kind of a special case - it's something that should be supported by <datagrid> whenever that comes back
  324. # [05:58] * Joins: tyoshino (n=tyoshino@220.109.219.244)
  325. # [05:59] * jcranmer is now known as jcranmer|away
  326. # [05:59] * Quits: othermaciej (n=mjs@nat/apple/x-uxzbralcurhgqejp)
  327. # [06:08] <tantek> othermaciej - people will use <details> for that because they can.
  328. # [06:11] * Quits: sicking (n=chatzill@nat/mozilla/x-nszrtczdyvlugjtq) (Read error: 110 (Connection timed out))
  329. # [06:19] * Joins: dglazkov_ (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  330. # [06:25] * Joins: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  331. # [06:33] * Quits: MikeSmith (n=MikeSmit@EM114-48-205-225.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  332. # [06:39] * Quits: dglazkov (n=dglazkov@72.14.224.1) (Read error: 110 (Connection timed out))
  333. # [06:39] * dglazkov_ is now known as dglazkov
  334. # [06:41] * Quits: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  335. # [06:42] * Quits: shepazu (n=schepers@adsl-221-74-58.rmo.bellsouth.net) ("Core Breach")
  336. # [06:43] * Quits: dave_levin (n=dave_lev@74.125.59.73)
  337. # [06:43] * Joins: dave_levin (n=dave_lev@nat/google/x-lvvdmunbszjiuwai)
  338. # [06:46] * Joins: lazni (n=lazni@118.71.115.2)
  339. # [06:47] <Hixie> anyone remember who did that research recently looking at various sites that marked up conversations?
  340. # [06:56] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  341. # [06:59] * Joins: shepazu (n=schepers@adsl-221-74-58.rmo.bellsouth.net)
  342. # [07:00] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  343. # [07:03] * Quits: miketaylrrrrr (n=miketayl@user-0cdf5gs.cable.mindspring.com)
  344. # [07:11] <heycam> Hixie, it was sicking iirc
  345. # [07:12] <Hixie> yeah that matches my memory too, but i couldn't find any e-mails from him about that
  346. # [07:12] <Hixie> what is last month maybe?
  347. # [07:12] <Hixie> i thought it was recently
  348. # [07:12] <heycam> yeah i thought it was only a week ago or so
  349. # [07:13] <Hixie> i looked in public-html and whatwg and couldn't find it
  350. # [07:13] <Hixie> do you remember what he had searched for?
  351. # [07:13] <heycam> it was some shakespeare
  352. # [07:14] <heycam> ah here it is, on whatwg
  353. # [07:14] <heycam> Date: Wed, 2 Sep 2009 22:33:01 -0300
  354. # [07:14] <Hixie> aah, found it also
  355. # [07:14] <heycam> it'd be nice if the mailing list software you're using inserted Archived-At headers :)
  356. # [07:14] <Hixie> the subject line threw me off
  357. # [07:15] <Hixie> it would be nice if the mailing list software we used didn't suck like an industrial vacuum
  358. # [07:16] <Hixie> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022576.html
  359. # [07:16] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  360. # [07:17] <othermaciej> I love how o:p makes an appearance
  361. # [07:23] * Quits: annodomini (n=lambda@wikipedia/lambda)
  362. # [07:24] <tantek> opp = other people's paragraphs?
  363. # [07:25] <othermaciej> the second p - it stands for proprietary
  364. # [07:25] * Joins: derferman (n=kjconroy@c-76-126-163-164.hsd1.ca.comcast.net)
  365. # [07:26] <derferman> so, I was hoping to looking into the notification standard that google has proposed
  366. # [07:26] <derferman> where would I find it?
  367. # [07:27] <tantek> dererman *the* notification standard?
  368. # [07:27] <tantek> do you mean PubSubHubbub?
  369. # [07:28] <tantek> or Google Wave?
  370. # [07:28] * Quits: virtuelv (n=virtuelv@125.175.251.212.customer.cdi.no) (Read error: 110 (Connection timed out))
  371. # [07:32] * Quits: lazni (n=lazni@118.71.115.2) ("Leaving.")
  372. # [07:34] * Joins: takkaria_ (n=takkaria@isparp.co.uk)
  373. # [07:36] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  374. # [07:37] * Quits: derferman (n=kjconroy@c-76-126-163-164.hsd1.ca.comcast.net)
  375. # [07:37] * Joins: MikeSmith (n=MikeSmit@EM114-48-113-101.pool.e-mobile.ne.jp)
  376. # [07:39] * Joins: drunknbass (n=drunknba@cpe-76-173-187-247.socal.res.rr.com)
  377. # [07:43] * Quits: boblet (n=boblet@p1254-ipbf304osakakita.osaka.ocn.ne.jp)
  378. # [07:47] * Quits: takkaria (n=takkaria@isparp.co.uk) (Read error: 110 (Connection timed out))
  379. # [07:51] * Joins: zalan (n=zalan@catv-89-135-144-193.catv.broadband.hu)
  380. # [08:01] * Quits: dave_levin (n=dave_lev@nat/google/x-lvvdmunbszjiuwai)
  381. # [08:04] * Quits: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz) ("Leaving")
  382. # [08:10] * Joins: sbublava (n=stephan@77.118.93.70.wireless.dyn.drei.com)
  383. # [08:10] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  384. # [08:15] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  385. # [08:15] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  386. # [08:19] * Joins: derferman (n=kjconroy@136.152.170.253)
  387. # [08:21] <derferman> neither
  388. # [08:22] <derferman> One of the lead chrome product managers was at Berkeley the other day
  389. # [08:26] <derferman> and mentioned google had proposed a javascript api for notifications
  390. # [08:41] <tantek> Webhooks
  391. # [08:41] <tantek> http://blog.webhooks.org/
  392. # [08:41] <tantek> used by Google Wave and others
  393. # [08:49] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  394. # [08:49] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  395. # [08:51] * takkaria_ is now known as takkaria
  396. # [08:52] * Joins: lazni (n=lazni@113.22.64.141)
  397. # [09:10] * Joins: cohitre (n=cohitre@24.18.158.106)
  398. # [09:14] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  399. # [09:15] * Joins: sicking (n=chatzill@c-69-181-197-163.hsd1.ca.comcast.net)
  400. # [09:18] * Joins: workmad3 (n=davidwor@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  401. # [09:25] * Joins: heycam (n=cam@210-84-56-211.dyn.iinet.net.au)
  402. # [09:25] * Joins: boblet (n=boblet@p3029-ipngn100101osakakita.osaka.ocn.ne.jp)
  403. # [09:32] * Quits: cohitre (n=cohitre@24.18.158.106)
  404. # [09:39] * Joins: pesla (n=retep@procurios.xs4all.nl)
  405. # [10:00] * Joins: ROBOd (n=robod@89.122.216.38)
  406. # [10:01] * Joins: slightlyoff (n=slightly@72.14.229.81)
  407. # [10:03] * Quits: slightlyoff (n=slightly@72.14.229.81) (Client Quit)
  408. # [10:05] * Quits: workmad3 (n=davidwor@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  409. # [10:11] * Quits: sicking (n=chatzill@c-69-181-197-163.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  410. # [10:13] * Quits: fishd (n=darin@72.14.224.1) (Read error: 110 (Connection timed out))
  411. # [10:15] * Quits: webben (n=benh@91.85.72.193) (Client Quit)
  412. # [10:17] * Joins: til (n=IRC@93-32-244-255.ip36.fastwebnet.it)
  413. # [10:17] <til> has anyone got custom attributes working in IE8?
  414. # [10:17] <til> elm.setAttribute('data-propname', 'data-propname') works in every browser (incl. IE7), but not 8
  415. # [10:37] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  416. # [10:44] <annevk2> Hixie, "new language that was no" should be "... was not"
  417. # [10:45] <Hixie> hx
  418. # [10:45] <Hixie> thanks even
  419. # [10:45] <annevk2> Hixie, also, it is "DOM Level 2 Core" and "DOM Level 2 HTML"
  420. # [10:45] <annevk2> not DOM HTML Level 2
  421. # [10:46] <Hixie> will fix
  422. # [10:46] <annevk2> "all the Level 3 drafts were published" I think they were all published, just not finished (i.e. published as Note)
  423. # [10:47] <Hixie> changed to completed
  424. # [10:48] <annevk2> it reads quite objective btw; nice job
  425. # [10:48] * Joins: Steve^ (n=steve@92.40.71.190.sub.mbb.three.co.uk)
  426. # [10:49] <Hixie> i tried
  427. # [10:49] <Hixie> :-)
  428. # [10:53] <Steve^> I read that article is being considered for a renaming. I thought section was causing the confusion?
  429. # [10:54] * Joins: mpt (n=mpt@canonical/mpt)
  430. # [10:54] <annevk2> Hixie, btw, the Web Storage or Web Database or maybe both still use DOM attribute in their boilerplate
  431. # [10:55] <Hixie> Steve^: things are always being considered, but i think currently nothing is really going to change on that front
  432. # [10:55] <Hixie> annevk2: thanks, forgot about those files
  433. # [10:56] <Steve^> I think the names are fine and when outliners are added to web dev tools, people should understand better
  434. # [11:00] <Hixie> hsivonen: "If, after doing so, the insertion mode is still "in foreign content", but there is no element in scope that has a namespace other than the HTML namespace, switch the insertion mode to the secondary insertion mode."
  435. # [11:00] * Joins: mookid (i=mookid@ROFL.name)
  436. # [11:00] <Hixie> hsivonen: is that text well-defined enough in your opinion? If it needs tightening up, what do you suggest it should be tightened to?
  437. # [11:00] <mookid> hello internet friends
  438. # [11:01] <mookid> I have a request
  439. # [11:01] <Hixie> i guess it's well-defined
  440. # [11:02] * heycam wonders if mookid and karlcow are related =)
  441. # [11:02] <mookid> can you please change the accept attribute on file input fields
  442. # [11:02] <mookid> so it's a content-type attribute instead
  443. # [11:03] <mookid> using accept for that is arse-about-face
  444. # [11:03] <Hixie> it's consistent with <form>
  445. # [11:03] <Hixie> from html4
  446. # [11:03] <mookid> change it it's wrong
  447. # [11:03] <mookid> :)
  448. # [11:04] <mookid> Accept is for client preferences for responses
  449. # [11:05] <annevk2> we still have that attribute?
  450. # [11:05] <Hixie> we can't change it, it's from html4
  451. # [11:05] * annevk2 thought it was useless
  452. # [11:05] <mookid> so you can't change anything from html4?
  453. # [11:05] <Hixie> annevk2: nah it's useful for saying "i just want images"
  454. # [11:05] <annevk2> ah right
  455. # [11:06] <Hixie> mookid: the rule isn't quite so black and white, but in this case, it is indeed something we can't change
  456. # [11:06] <annevk2> though <form> does not have it (well it has accept-charset)
  457. # [11:06] <mookid> yeah erm
  458. # [11:06] <mookid> that doesn't make sense
  459. # [11:06] <mookid> circular justification
  460. # [11:07] <Hixie> annevk2: <form accept> is in html4
  461. # [11:07] <Hixie> woo, below 100 XXX markers too!
  462. # [11:07] * Parts: til (n=IRC@93-32-244-255.ip36.fastwebnet.it)
  463. # [11:07] <Hixie> and still below 100 e-mails!
  464. # [11:07] <annevk2> Hixie, but not in HTML5 :)
  465. # [11:08] <mookid> yeah I would drop it
  466. # [11:08] <mookid> it's stupidly named
  467. # [11:08] <Hixie> annevk2: oh? did we move it off <form>? interesting
  468. # [11:08] <annevk2> but HTML4 has it on <input>
  469. # [11:08] <annevk2> and so does HTML5
  470. # [11:08] <Hixie> oh ok
  471. # [11:08] <mookid> hmm
  472. # [11:08] <annevk2> doesn't seem like something we want to change indeed
  473. # [11:08] <mookid> why?
  474. # [11:09] <Hixie> mookid: your interest in http content negotiation is a lost cause here, i fear
  475. # [11:09] <Lachy> we need to keep it on input, on the condition that browsers actually implement it and do something useful with it. I'm not aware of any browser that does, though
  476. # [11:09] <mookid> Hixie: this isn't content-negotiation actually
  477. # [11:09] <annevk2> changing the name of something has cost and marginal benefit
  478. # [11:09] <mookid> this is just horrendously named attributes
  479. # [11:09] <mookid> that are confusing
  480. # [11:09] <Hixie> mookid: html has lots of horrendously named things
  481. # [11:09] <mookid> you've called the content-type control.. Accept
  482. # [11:09] <Hixie> live with it :-)
  483. # [11:10] <mookid> which is completely WRONG
  484. # [11:10] <Hixie> "accept" makes plenty of sense
  485. # [11:10] <Hixie> it's what the server wants to accept
  486. # [11:10] <mookid> no it doesn't.
  487. # [11:10] <takkaria> ps fear the axiomatic proof
  488. # [11:10] <Lachy> mookid, it makes sense because it says which content types are accepted by the file upload control
  489. # [11:10] <krijnh> http://twitter.com/ppk/statuses/4075175585
  490. # [11:10] <virtuelv> I really, really miss the index of elements from the html 4 spec
  491. # [11:10] <mookid> yes I guessed that was the reason
  492. # [11:10] <krijnh> He's at LC already! :(
  493. # [11:11] <annevk2> krijnh, haha
  494. # [11:11] <Lachy> haha
  495. # [11:11] <mookid> in HTTP - Accept has a specific meaning in a request; it means the media types the client wants to recieve back in the response
  496. # [11:11] <Hixie> virtuelv: if you can write the script that generates the index for html5, i'll put it in immediately. :-)
  497. # [11:11] <annevk2> krijnh, I have the feeling it's not going away with three implementations, but I look forward to his pile of shit rant and tests he uses to back it up :)
  498. # [11:11] <mookid> what that attribute is actually controlling is the content-type header
  499. # [11:11] <Lachy> has no-one told PPK that we're pretty much stuck with the overall design of drag and drop for compatibility reasons?
  500. # [11:11] <Hixie> virtuelv: http://www.whatwg.org/specs/web-apps/current-work/#index
  501. # [11:11] <mookid> so it should be called content-type
  502. # [11:11] <krijnh> annevk2: yeah, me too
  503. # [11:12] <mookid> and not accept
  504. # [11:12] <annevk2> dude, you're over a decade too late with that name change
  505. # [11:12] <mookid> ....
  506. # [11:12] <mookid> so you cna't make changes?
  507. # [11:12] <Hixie> mookid: "content-type" is the type, it's not what it is
  508. # [11:12] <Hixie> mookid: it'd be like calling the min="" attribute "integer"
  509. # [11:13] <Hixie> mookid: and no, it's too late to change this
  510. # [11:13] <virtuelv> the whatwg section of the spec is cruel to my laptop
  511. # [11:13] <mookid> in the run up to 2032?
  512. # [11:13] <mookid> -_-
  513. # [11:13] <mookid> yeah ok.
  514. # [11:15] <Lachy> virtuelv, if you block the scripts, it helps the spec load faster
  515. # [11:15] <Hixie> mookid: actually the run up is to next month
  516. # [11:15] <Hixie> the plan is to reach LC in october 2009
  517. # [11:15] <Hixie> and we seem to be on track! http://www.whatwg.org/issues/data.html
  518. # [11:16] * Joins: mpt_ (n=mpt@canonical/mpt)
  519. # [11:16] <Lachy> Hixie, do you expect the HTMLWG to actually publish LC at that time, or just that the spec itself will be ready for it in theory?
  520. # [11:16] <mookid> Hixie: nice =)
  521. # [11:16] <takkaria> Hixie: your script is borked
  522. # [11:17] <Lachy> and will there be a Last Call snapshot published on whatwg.org, independently from the HTMLWG, regardless of what they do?
  523. # [11:17] <takkaria> Hixie: it appears to not be plotting the lines on the issues graph
  524. # [11:18] <Lachy> takkaria, which browser are you using?
  525. # [11:18] <Lachy> the script relies on canvas text apis, which is why it breaks in Opera
  526. # [11:18] <Steve^> Is this some new form of art?
  527. # [11:18] <takkaria> ah, I need to use Fx3.5 then
  528. # [11:18] <takkaria> apparently I've never look at that on my work computer before
  529. # [11:19] <Steve^> Firefox 3.0 shows a more graph-like thing.. but I have no idea what it means
  530. # [11:19] * Steve^ doesn't have a browser on his system capable of viewing that graph
  531. # [11:20] <jgraham_> Steve^: You need more browsers
  532. # [11:20] <takkaria> ah, Chrome works
  533. # [11:20] <Hixie> Lachy: i expect the whatwg to publish an LC draft in october
  534. # [11:20] <annevk2> for those without capable browsers: "77 e-mails remaining; 92 issues remaining; 158 bugs remaining. Last updated 0.2 hours ago."
  535. # [11:21] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 113 (No route to host))
  536. # [11:21] <mookid> Hixie: content-type is the content-type for that file input; what's the problem with that?
  537. # [11:22] <Steve^> isn't content-type used elsewhere with a different meaning?
  538. # [11:22] <mookid> that's how the Content-Type header shuold be set for any request going out
  539. # [11:22] <annevk2> no
  540. # [11:22] <annevk2> the content-type is application/form-data or some such
  541. # [11:23] <mookid> right - that's pretty wrong
  542. # [11:23] <mookid> if my browser is upload a pdf it should be setting the content-type header for that chunk to application/pdf
  543. # [11:23] <Hixie> mookid: content-type is the type of a parameter, not a name of a parameter.
  544. # [11:24] <mookid> eh? dunno what you saying there Ian
  545. # [11:24] <Hixie> mookid: both enctype="" and accept="" take content types on <input>, and we can't name them both content-type
  546. # [11:24] <annevk2> mookid, not if the pdf is encoded as application/form-data (or whatever the actual type is)
  547. # [11:24] <Hixie> actually it's called formenctype now
  548. # [11:24] <Hixie> not enctype
  549. # [11:24] <Hixie> but the point is the same
  550. # [11:24] <mookid> wait what
  551. # [11:25] <mookid> what does formectype do then?
  552. # [11:25] * Joins: brucel (n=brucel@92-236-144-120.cable.ubr10.smal.blueyonder.co.uk)
  553. # [11:26] <mookid> annevk2: if the browser is sending a pdf it should be setting the content-type header to applicaiton/pdf suyrely?
  554. # [11:26] <mookid> that's what that header is for..
  555. # [11:26] <mookid> application/form-data is meaningless
  556. # [11:26] <Steve^> last time I tried looking at them, I found the values to be very inconsistent
  557. # [11:27] <Hixie> mookid: i recommend reading the spec before sending feedback :-)
  558. # [11:27] <Steve^> but this was some years ago
  559. # [11:27] <annevk2> mookid, no, but I'm bowing out of this discussion no
  560. # [11:27] <mookid> hmm ok
  561. # [11:27] <mookid> very odd.
  562. # [11:28] <brucel> So, Mike Smith said yesterday that IRC rocks http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1066 and I should hang out in this party. Question about classid being non-conformant in html5. Someone at a conference I spoke at needs to do Hixie's Flash fallback thang http://damowmow.com/playground/demos/flash/001.html but it's illegal in html5. How can this be achived?
  563. # [11:28] <mookid> what do you people have against HTTP? -_-
  564. # [11:28] <boblet> hey brucel :)
  565. # [11:28] <krijnh> Howdy brucel!
  566. # [11:28] <mookid> did Fielding piss in your corn flakes or something?~
  567. # [11:28] <virtuelv> Lachy: that might be, but just loading the spec is painful when I've clamped my CPUs to 800MHz
  568. # [11:28] <brucel> hi gang. Now this IS a nice party
  569. # [11:28] <krijnh> Not it is, yes ;)
  570. # [11:29] <krijnh> *Now
  571. # [11:29] <virtuelv> because you know, that's only about as fast as a mobile phone these days
  572. # [11:29] <krijnh> brucel: so, why aren't you coming to Fronteers 2009, damnit!
  573. # [11:29] <mookid> Hixie: where abouts on the spec are you suggesting I read
  574. # [11:29] <Hixie> brucel: people didn't have a problem violating the html4 spec to get it working in IE, why would they have a problem violating the html5 spec? :-)
  575. # [11:30] * virtuelv had expected brucel to show up with clownabuser as his nick
  576. # [11:30] <Hixie> (IE's use of clsid="" and codebase="" both violate HTML4's definitions)
  577. # [11:31] <boblet> “IE, the Violator”
  578. # [11:31] <Hixie> i suppose we should find someone way to include flash in html5 that works in IE, though, even if we never had one for html4
  579. # [11:31] <boblet> woah, that sounds way too scary
  580. # [11:31] <brucel> Hixie, fair point but this guy wants to Do It Right TM
  581. # [11:32] <Hixie> let's see...
  582. # [11:32] <mookid> Hixie: wait, I just read it - and it doesn't explain anything at all it just repeats the same nonsense from html4; why did you tell me to read the spec?
  583. # [11:32] <brucel> krijnh - Fronteers possibly clashes with a trip elsewhere. Plus, I can never find decent beer in the Netherlands
  584. # [11:33] <Hixie> mookid: you read the whole spec in 5 minutes?!
  585. # [11:33] <mookid> why do I need to read the whole spec in order to have a discussion on this specific issue?
  586. # [11:34] <Philip`> It's a subtle to plan to keep you busy for three weeks
  587. # [11:34] <Steve^> mookid, you just want the name of "accept" changed?
  588. # [11:34] * Joins: adactio (n=adactio@host86-138-101-27.range86-138.btcentralplus.com)
  589. # [11:34] <Hixie> what Philip` said
  590. # [11:34] <mookid> well yeah but I think this whole thing about content-type header on upload would be useful
  591. # [11:34] <krijnh> brucel: hmm, okay :)
  592. # [11:34] <Philip`> s/subtle to/subtle/
  593. # [11:35] <krijnh> No decent beers, tsk
  594. # [11:35] * Parts: boblet (n=boblet@p3029-ipngn100101osakakita.osaka.ocn.ne.jp)
  595. # [11:35] <Hixie> brucel: ok so say you wanted to embed the flash file "http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf"
  596. # [11:35] <annevk2> brucel, really? I hardly ever have that problem
  597. # [11:35] <mookid> why are we using application/form-data when the mime type can be specified properly
  598. # [11:35] <Hixie> brucel: it looks like the easiest way to do that in IE is the following markup:
  599. # [11:35] <Hixie> <embed src="http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf">
  600. # [11:35] <annevk2> brucel, what kind of beer are you into?
  601. # [11:36] <annevk2> mookid, that you do not understand that indicates you should read the spec
  602. # [11:36] <Hixie> brucel: and that is valid in HTML5
  603. # [11:36] <mookid> annevk2: why don't you just explain it, it's not that complicated a question :/
  604. # [11:36] <Philip`> mookid: When you're uploading a PDF file via <input type=file>, the data it sends is not simply the file content, it has to include the field name and other input fields and stuff, so it's sending some special type of form data and not just a PDF
  605. # [11:36] <Philip`> I think
  606. # [11:37] <mookid> isn't that why it's chunked?
  607. # [11:37] <mookid> the actually payload chunk can have the content-type specified
  608. # [11:37] <mookid> actual^
  609. # [11:37] <Steve^> that seems sensible
  610. # [11:38] * Hixie wonders where brucel went
  611. # [11:38] <mookid> it's extremely useful if you're trying to write layered HTTP systems
  612. # [11:38] <mookid> like CDNs
  613. # [11:38] <Steve^> mookid, can you trust that though? Maybe you'll need to do a server side check on the file content still?
  614. # [11:38] <mookid> potentially
  615. # [11:38] <mookid> implementation detail
  616. # [11:39] <mookid> you might just want to store a bogus file anyway
  617. # [11:39] <brucel> Hixie, went on reverie about beer. Back now
  618. # [11:40] <brucel> So, the outer <object> that you used (with classid for IE) can be replaced by embed, which is now legal in html5?
  619. # [11:41] <Steve^> mookid, do browsers not already do that?
  620. # [11:41] <Hixie> brucel: the whole thing can be replaced by embed
  621. # [11:41] <mookid> I don't think so
  622. # [11:41] <brucel> didn't think embed had fallback for non-flash browsers?
  623. # [11:42] <Hixie> it doesn't
  624. # [11:43] <brucel> customer wants to "embed" Flash, with fallback to static <img>, but validate as html5
  625. # [11:43] <Hixie> oh, you didn't say that
  626. # [11:43] <Hixie> said customer has users who actually don't have flash and would be happy with a static img instead? wow
  627. # [11:44] <brucel> sorry, should've; that's why I went for your double object menthod.
  628. # [11:44] * Joins: mat_t (n=mattomas@91.189.88.12)
  629. # [11:44] <brucel> Hixie: fallback for Safari, Opera and other mobile browsers so there's no big white space
  630. # [11:44] <krijnh> Why not use SWFObject for that?
  631. # [11:44] <Hixie> set a background image on the container
  632. # [11:45] <brucel> while I understand why classid is not allowed - and speaking of Flash is distasteful here - it seems likie a valid request
  633. # [11:46] <brucel> SWFObject is good - but there should be a markup-only way imo to get to the static fallback content
  634. # [11:46] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  635. # [11:47] <Steve^> (doesn't <video> allow that?)
  636. # [11:48] <Hixie> brucel: damowmow.com/playground/demos/flash/003.html
  637. # [11:48] <Hixie> er
  638. # [11:48] <Hixie> brucel: http://damowmow.com/playground/demos/flash/003.html
  639. # [11:48] <mookid> Steve^: no they don't do that
  640. # [11:49] <mookid> Hixie: that's right, yeah - browser send the data chunked but the don't set the conte-type header on the way out?
  641. # [11:49] <Hixie> mookid: i really have no idea what you're talking about
  642. # [11:49] <Steve^> mookid, I'm by no means important around here, but it seems logical for that to be set on the correct chunk. Could be added to the spec
  643. # [11:49] <brucel> Hixie v nice
  644. # [11:49] <mookid> that was rationale for calling 'accept' 'content-type'
  645. # [11:50] <mookid> because it's constraining what those headers can be set to
  646. # [11:50] <Hixie> mookid: and your rationale for not calling formenctype content-type is what?
  647. # [11:50] <mookid> well I don't know why there's 2
  648. # [11:50] <mookid> feel free to explain
  649. # [11:50] <Hixie> one is to set what file types the <input> element accepts, and the other is to sent what the encoding type will be when the form is submitted
  650. # [11:50] <brucel> another attendee question: is there any use in the <header> element if surrounds a heading <h1>..<h6> and nothing else? (I said no)
  651. # [11:50] <Steve^> mookid, I think Hixie's integer example was marvellous. min="" rather than integer=""
  652. # [11:50] <mookid> how could those.. be different? -_-
  653. # [11:51] <Steve^> mookid, accept-content-type would be better, it says what it is and what type of thing it takes. Or shorten to accept
  654. # [11:51] <mookid> yeah ok fair enough
  655. # [11:51] * Joins: webben (n=benh@nat/yahoo/x-vbpxufxpvgvolesh)
  656. # [11:51] <Hixie> mookid: if i submit a form with three form fields, i can submit it either using multipart/formdata, or using the foo=bar&baz=quux&a=b format, or using the foo: bar\nbaz: quux format
  657. # [11:52] <Hixie> mookid: that's the enctype
  658. # [11:52] <Steve^> we must assume that developers can read the spec and know what type each attribute takes, and refer to the attributes only by name
  659. # [11:52] <Hixie> mookid: and a single form can have multiple <input type=file>s, one accepting images, one accepting PDF files, etc
  660. # [11:52] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) ("ChatZilla 0.9.85 [Firefox 3.5.4pre/20090917030727]")
  661. # [11:52] <Hixie> you really should read the spec
  662. # [11:52] <mookid> mmmhmmm
  663. # [11:53] <mookid> you should write better specs
  664. # [11:53] <beowulf> miaow
  665. # [11:53] <mookid> :)
  666. # [11:53] <Philip`> Do you have concrete suggestions that would make it better?
  667. # [11:53] <mookid> fire Ian.
  668. # [11:53] <mookid> :D
  669. # [11:53] <Philip`> That would result in the spec not being written, so I'm not sure that'd be any better
  670. # [11:54] <mookid> really?
  671. # [11:54] <mookid> I don't know about that.
  672. # [11:54] <mookid> as things stand anyway
  673. # [11:54] <Steve^> Some of what mookid says it good. Uploaded files should be sent with the corrent content-type.
  674. # [11:54] <annevk2> mookid, the relevant specs are not written by Ian
  675. # [11:54] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  676. # [11:55] <annevk2> mookid, that is, you could chose to read HTML4 and the relevant RFCs instead
  677. # [11:55] <mookid> I'm being jovial, relax
  678. # [11:55] <mookid> deep breaths
  679. # [11:55] <Hixie> let me know when you're done writing the specs instead of me :-)
  680. # [11:55] <annevk2> mookid, I'm just explaining he does not need to be a barrier to your learning process
  681. # [11:56] <mookid> ok, look I'm just trying to help you write a hypermedia format that works better with the protocol which makes it worth something
  682. # [11:56] <mookid> blablabla email not just HTTP
  683. # [11:56] <brucel> hixie your demo page, nothing at all shows in FF3.5 for some reason; when I disable Flash in Opera I don't get fallback content. (Dunno how to disable Flash in the other browsers)
  684. # [11:57] <mookid> HTTP is pretty important and what HTML5 provides will constrain/inhibit developers to use it
  685. # [11:57] <Hixie> brucel: huh, dunno what's up with firefox
  686. # [11:57] <annevk2> mookid, what you've said so far indicates you do not have a basic understanding of HTML forms and yet you want to propose changes to it
  687. # [11:58] <annevk2> mookid, that does not work
  688. # [11:58] <mookid> the reason I'm tlaking to you on here is because I accept that fact
  689. # [11:58] <mookid> if you spent less time telling me I was wrong and more time explaining why
  690. # [11:58] <mookid> perhaps this wouldnt drag out everytime
  691. # [11:59] <annevk2> several people already explained your misunderstanding but it didn't improve matters apparently
  692. # [11:59] <mookid> I don't think you did actually
  693. # [12:00] <brucel> annevk2, krijnh (I have found good beer in Holland, but last time I felt really bad after just 2 pints of that Jenever beer.)
  694. # [12:00] <Hixie> brucel: try now
  695. # [12:00] * mpt_ is now known as mpt
  696. # [12:00] <annevk2> brucel, lol
  697. # [12:00] <krijnh> Jenever beer :D
  698. # [12:00] <takkaria> mm, Jenever
  699. # [12:01] <Hixie> mookid: when i tried to explain to you what you were misunderstanding, you told me to write better specs
  700. # [12:01] <mookid> annevk2: why is there any need to specify the formenctype for a file input field that already has the acceptable content-types specified?
  701. # [12:01] <Hixie> mookid: this is not conducive to a good working relationship
  702. # [12:01] <mookid> the content-type header will need to be set according to the file selected
  703. # [12:01] <mookid> it needs to be dynamic
  704. # [12:01] <annevk2> wtf, twitter changed my avatar
  705. # [12:02] <mookid> hence why I don't see a need for accept and formectype
  706. # [12:02] <brucel> Hixie works in FF3.5, still no fallback in Opera. Need to test other browsers too. Cheers
  707. # [12:02] <Steve^> annevk2, there were some issues, yes
  708. # [12:02] <Hixie> dunno what's up with the new fallback
  709. # [12:03] <mookid> Hixie: surely it doesnt make any sense to pre-define the enc type for a file input that hasn't been selected?
  710. # [12:03] <annevk2> mookid, formenctype doesn't apply to file input
  711. # [12:03] * Quits: lazni (n=lazni@113.22.64.141) ("Leaving.")
  712. # [12:04] <mookid> are you sure? its linked under the file type
  713. # [12:04] <Hixie> mookid: enctype isn't important to your point, the point is just that there are many attributes that take content-types, so namign the attribute "content-type" makes no sense
  714. # [12:04] <annevk2> mookid, yes
  715. # [12:04] <Hixie> mookid: just like we wouldn't name the name="", value="", title="", and class="" attributes string=""
  716. # [12:04] <Hixie> or the min="", max="", and step="" attributes number=""
  717. # [12:04] <mookid> Hixie: ok how about accept-content-type
  718. # [12:04] <mookid> or content-types-accepted
  719. # [12:04] <Hixie> accept="" is fine
  720. # [12:05] <Hixie> we don't say min-number="" or title-string="" or class-list-of-keywords="" or id-unique-string="" or whatever
  721. # [12:05] * Joins: zcorpan__ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  722. # [12:05] <zcorpan__> Hixie, brucel: you can have one object that has both data="" and <param name=movie>
  723. # [12:05] <zcorpan__> data="" works in all but ie
  724. # [12:05] <zcorpan__> <param> works in all but firefox
  725. # [12:06] <zcorpan__> (someone file a bug in moz bugzilla?)
  726. # [12:07] <MikeSmith> my irc client beeped a beer sound.. somebody said "beer"
  727. # [12:07] <Hixie> zcorpan__: i considered that but it looks silly :-)
  728. # [12:07] <MikeSmith> ./lastlog beer
  729. # [12:07] <MikeSmith> whoah
  730. # [12:07] <takkaria> MikeSmith: ah, we know how to summon you now you've told us that
  731. # [12:07] <MikeSmith> brucel!
  732. # [12:07] <Hixie> ok 3am, i should go to bed
  733. # [12:08] <Hixie> nn
  734. # [12:08] <mookid> Hixie: is it the job of the HTML5 spec to mandate that the chunk containing the file contents have the apropriate content-type header set ?
  735. # [12:08] <zcorpan__> Hixie: having two objects makes things harder for scripts
  736. # [12:08] * Joins: lazni (n=lazni@123.24.188.206)
  737. # [12:08] <mookid> =/
  738. # [12:09] <MikeSmith> annevk2: cantillon gueuze
  739. # [12:09] <zcorpan__> mookid: file a spec bug to make Hixie reply :)
  740. # [12:09] <MikeSmith> oh man
  741. # [12:09] * zcorpan__ is now known as zcorpan
  742. # [12:09] <MikeSmith> mookid: hey
  743. # [12:09] <mookid> ?
  744. # [12:09] <mookid> hi
  745. # [12:09] <mookid> how's it going?
  746. # [12:09] <MikeSmith> good good
  747. # [12:09] <mookid> sound
  748. # [12:10] <annevk2> Steve^, do you know if the avatars come back?
  749. # [12:10] <mookid> anyone help? - is it the job of the HTML5 spec to mandate that the chunk containing the file contents have the apropriate content-type header set ?
  750. # [12:11] <Steve^> annevk2, "Update (5:30p): Weve identified the root cause of this problem and expect the issue to be resolved within the next several hours."
  751. # [12:11] <annevk2> mookid, no
  752. # [12:11] <Steve^> annevk2, keep an eye on twitter.com/twitter
  753. # [12:11] <annevk2> Steve^, ta
  754. # [12:11] <mookid> annevk2: which body would spec that out?
  755. # [12:11] <annevk2> mookid, IETF
  756. # [12:11] <mookid> really? o.O
  757. # [12:12] <mookid> it seems pretty relevant to HTML
  758. # [12:13] <brucel> cheers zcorpan
  759. # [12:13] <zcorpan> hi brucel
  760. # [12:13] <zcorpan> mookid: file a spec bug
  761. # [12:13] <mookid> gah I can't do dorky things like that
  762. # [12:13] <mookid> have no idea what I'm doing there
  763. # [12:13] <zcorpan> mookid: sure you can, it's simple as pie. use the comment box in the whatwg spec
  764. # [12:14] <brucel> zcorpan, thx for advice on the flash thang
  765. # [12:14] <mookid> yeah but I'll word it like I'm on IRC
  766. # [12:14] <zcorpan> so?
  767. # [12:14] <mookid> and then people will laugh at me and I wont be cool anymore
  768. # [12:14] <zcorpan> it's anonymous :)
  769. # [12:14] <mookid> oh ok cool
  770. # [12:15] <zcorpan> brucel: it's basically the same thing as the old ALA article
  771. # [12:15] <annevk2> mookid, it's defined in RFC 2388
  772. # [12:15] <zcorpan> brucel: iirc, ie would wait with showing the flash until it has downloaded the whole file
  773. # [12:17] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
  774. # [12:17] <mookid> hmm interesting annevk2: As with all multipart MIME types, each part has an optional "Content-Type", which defaults to text/plain. If the contents of a file are returned via filling out a form, then the file input is identified as the appropriate media type, if known, or "application/octet-stream"
  775. # [12:18] <Steve^> mookid, that's from the spec?
  776. # [12:18] <mookid> from the RFC he just told me to look at
  777. # [12:18] <mookid> http://www.ietf.org/rfc/rfc2388.txt section 3
  778. # [12:18] <Steve^> oh, I see
  779. # [12:18] <Steve^> if its not in the spec, file a bug report to have it added
  780. # [12:18] <zcorpan> does html5 reference it?
  781. # [12:18] * Quits: tantek (n=tantek@70.36.139.108)
  782. # [12:18] <annevk2> zcorpan, yes
  783. # [12:18] <Steve^> and then when it is added, file a bug report against each of the browsers :
  784. # [12:19] <annevk2> zcorpan, but mookid refuses to read the spec
  785. # [12:19] <mookid> link to the part of html5 I shoul dbe looking at?
  786. # [12:19] <mookid> ok just show me the part I should be looking at please =-/
  787. # [12:19] <annevk2> Steve^, is there actually a bug in browsers? I somewhat doubt it
  788. # [12:19] <mookid> doesn't seem like they are conforming to the spec
  789. # [12:19] <Steve^> annevk2, if the spec changes and they don't follow the spec, then you can raise a bug/feature against it
  790. # [12:20] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  791. # [12:20] <zcorpan> mookid: 4.10.17.5
  792. # [12:20] <Steve^> Opera Turbo makes captchas an extra challenge
  793. # [12:20] <mookid> URL? -_-
  794. # [12:20] <annevk2> Steve^, really? :)
  795. # [12:20] <takkaria> mookid: christ, just open the spec... http://www.whatwg.org/specs/web-apps/current-work/multipage/
  796. # [12:21] * Quits: sbublava (n=stephan@77.118.93.70.wireless.dyn.drei.com)
  797. # [12:21] <mookid> see I was here
  798. # [12:21] <mookid> http://www.w3.org/TR/html5/forms.html
  799. # [12:21] <mookid> thank you.
  800. # [12:21] <zcorpan> mookid: TR/ is always outdated, fwiw
  801. # [12:21] <mookid> ok sorry I'm not a spec dork :/
  802. # [12:21] <mookid> guilty.
  803. # [12:21] <zcorpan> just trying to help :)
  804. # [12:22] <mookid> I know just frustrated
  805. # [12:22] <mookid> thanks :)
  806. # [12:24] <mookid> hmm
  807. # [12:24] * Quits: tkent (n=tkent@220.109.219.244) ("Leaving...")
  808. # [12:25] <brucel> zcorpan so there still isn't a way to get flash in a page that 1) doesn't make IE wait, 2) works x-browser and 3) allows fallback in the markup and 4) validates as html5? The fallback in the markup is necessary for non-JS users, and validation is an important part of lots of corporate QA
  809. # [12:26] <annevk2> just make a small swf that loads the big swf
  810. # [12:27] <annevk2> or ... don't use Flash :)
  811. # [12:27] <zcorpan> brucel: what annevk2 said
  812. # [12:27] <mookid> zcorpan: so you think I should provide a comment about specifying how file input's are handled?
  813. # [12:27] <zcorpan> brucel: it might be the case that it's fixed in ie8, haven't tested
  814. # [12:28] <brucel> annevk2 with you on both points, but a nasty SWF hack feels uber-dirty and many corporates do use Flash at the moment
  815. # [12:28] <zcorpan> mookid: html5 references the rfc, so i don't know what's not specified
  816. # [12:29] <brucel> feels like classid should be made "conformant but minging" or whatever the specspeak is so Hixie's double object method will validate
  817. # [12:31] <annevk2> just for IE8?
  818. # [12:31] <annevk2> hmm
  819. # [12:31] <annevk2> HTML5 is not done yet, maybe it's better to file a bug on IE
  820. # [12:31] <zcorpan> i think classid makes other browsers ignore the object
  821. # [12:31] <zcorpan> no?
  822. # [12:31] <annevk2> some browsers have hacks for classid
  823. # [12:32] * annevk2 forgot the details
  824. # [12:32] <mookid> so this Content-Disposition: form-data; name="user"
  825. # [12:32] <mookid> name is taken from the input id attribute?
  826. # [12:33] <Steve^> My understanding was that the video element was created to solve video problems like this
  827. # [12:33] <Steve^> the HTML5 way would be to use that
  828. # [12:33] <Steve^> but, I'm new here
  829. # [12:33] <zcorpan> brucel: i'd try to get firefox fix their lack-of-data="" bug and ie fix their wait-until-loaded bug (if they haven't already)
  830. # [12:34] <mookid> I think I've asked this before but I can't remember what the answer was
  831. # [12:34] <annevk2> Steve^, video is not the only use case for Flash
  832. # [12:35] <mookid> is there a channel/group for browser devs or is this the best place to be for that?
  833. # [12:36] * Quits: nessy (n=nessy@hendrix.mega-nerd.net) ("This computer has gone to sleep")
  834. # [12:37] <takkaria> nattokirai: taken from <input name="">
  835. # [12:37] <takkaria> uh
  836. # [12:37] <takkaria> mookid: taken from <input name="">
  837. # [12:38] <Philip`> mookid: There are other channels that are better for specific browsers
  838. # [12:39] <Philip`> (like #webkit for WebKit, and Mozilla IRC for Mozilla)
  839. # [12:39] <jgraham_> But his one is good for browsers in general
  840. # [12:39] <jgraham_> Well some browsers
  841. # [12:39] <Philip`> (For IE, you can, uh, I suppose comment in a random post on the IEBlog and then be ignored)
  842. # [12:40] <hsivonen> Hixie: I think the "in foreign" exit is well-defined
  843. # [12:40] <mookid> ha
  844. # [12:40] <mookid> ok thanks :)
  845. # [12:41] <hsivonen> so it turns out that the people digging up the phone copper weren't doing it because I complained about my ADSL
  846. # [12:41] <mookid> gypos?
  847. # [12:41] <hsivonen> they are doing it because a different person in the building and customer of a different ISP
  848. # [12:42] <zcorpan> for IE you can participate in their yearly sheduled IE Team Chat Session for 60 minutes, or similar
  849. # [12:42] <jgraham_> and be ignored
  850. # [12:42] <zcorpan> yeah
  851. # [12:42] <mookid> hey
  852. # [12:42] <mookid> at least they're trying
  853. # [12:42] <Philip`> It's not the greatest feedback system in the world
  854. # [12:43] <mookid> IE is going to die anyway
  855. # [12:43] <mookid> I have a plan
  856. # [12:43] <mookid> a genius plan
  857. # [12:43] <Philip`> (It is pretty hard to have a feedback system that doesn't get overwhelmed by noise, when you have a billion users)
  858. # [12:43] * Quits: Steve^ (n=steve@92.40.71.190.sub.mbb.three.co.uk) ("Leaving")
  859. # [12:43] <Philip`> (so I'm not sure what they could do better)
  860. # [12:44] * jgraham_ is wondering whether the death of IE will come before or after the entropy death of the universe
  861. # [12:44] <jgraham_> Note: "entropy death of the universe" is a term I just made up
  862. # [12:44] <brucel> like i said, "conformant but horrible" for classid makes the whole Flash embed validation problem go away and doesn't require anyone to change their code, just WHATWG to change the spec. (The Flash they use isn't for video)
  863. # [12:44] <hsivonen> Philip`: generally speaking, people shouldn't use IRC to complain about Firefox bugs
  864. # [12:44] <mookid> spyware
  865. # [12:44] <mookid> no wait
  866. # [12:44] <mookid> it's not called that
  867. # [12:45] <hsivonen> brucel: Hixie had a demo that made Java embedding using <object> work cross-browser using only HTML5-valid stuff
  868. # [12:45] <karlcow> http://tech.groups.yahoo.com/group/rest-discuss/message/13346
  869. # [12:45] <karlcow> doesn't seem to be a joke finally… The REST-*
  870. # [12:45] <hsivonen> brucel: does the same thing not work for Flash?
  871. # [12:46] <mookid> package the webskit/mozilla engines so devs can use them like adobe-AIR
  872. # [12:46] <brucel> hsivonen got a link, Henri?
  873. # [12:46] <hsivonen> brucel: http://damowmow.com/playground/demos/java/001.html
  874. # [12:46] <annevk2> brucel, are you sure classid does not break other browsers?
  875. # [12:47] <hsivonen> IIRC, classid breaks Gecko
  876. # [12:47] <hsivonen> or at least used to, IIRC
  877. # [12:47] <hsivonen> maybe that was an artifact of XPCOM plug-ins
  878. # [12:47] <hsivonen> dunno what the story is now with NPRuntime
  879. # [12:49] <brucel> annevk2 Hixie's orginal demo seems to work everywhere, just not validate as html5: http://damowmow.com/playground/demos/flash/001.html
  880. # [12:49] <hsivonen> brucel: it would be very cool to have an HTML5 doctor article about how to do Flash and Java in a Hixie-approved way syntactically
  881. # [12:49] <zcorpan> filed https://bugzilla.mozilla.org/show_bug.cgi?id=517440
  882. # [12:49] <hsivonen> (even if Hixie doesn't approve of Flash and Java)
  883. # [12:50] <hsivonen> zcorpan: do you have an on-the-Web URL demo/test case to go with the bug report?
  884. # [12:51] <zcorpan> hsivonen: i did until Hixie changed his test to be Firefox-compatible
  885. # [12:51] <zcorpan> hsivonen: see brucel's message above for a flash file to use
  886. # [12:53] <brucel> I agree that I'm talking dirty, but reiterate this is a genuine use case. Just in on twitter, for example "Do share if you find a solution .. it's a prob I've been encountering a lot of the last few months... will need a change in spec to get around though I think?" http://twitter.com/allmarkedup/statuses/4076136010
  887. # [12:53] <adactio> brucel: you can take a look at how I'm doing cross-browser Flash on Huffduffer. I'm not using <embed> but the crucial thing is duplicating the swf path in the @data attribute of <object> *and* in a <param name="movie"> element. Fallback content goes before the closing </object>.
  888. # [12:53] <annevk2> brucel, did you see the hack it's using
  889. # [12:54] <annevk2> brucel, ouch
  890. # [12:54] <annevk2> adactio, that apparently prevents incremental loading
  891. # [12:54] <brucel> annevk2 yes, I'm covering my eyes and holding my nose.
  892. # [12:54] <adactio> annevk2: Yes. Basically I'm doing Flash Satay so it only really works well with small .swf files (the whole thing is downloaded before being displayed.
  893. # [12:55] <brucel> adactio that's why I discounted that method as a bullet-proof one to recommend
  894. # [12:55] <brucel> tho it's perfectly acceptable much of the time
  895. # [12:55] <adactio> brucel: well, it depends on the use case. It works well for video or audio flash containers that then point off to the actual movie or sound file.
  896. # [12:55] <zcorpan> brucel: use <!--[if IE]><object for ie><param><![endif]--><!--[if !IE]>--><object for others><!--<![endif]--><param quality etc>fallback</object>
  897. # [12:56] <zcorpan> i might have screwed up the cc syntax but the idea is the same
  898. # [12:56] <zcorpan> the first object can use classid and be hidden from the validator
  899. # [12:56] <adactio> Incidentally, I would totally use <audio> on Huffduffer in a heartbeat if it weren't for the bug in Safari that insists on prebuffering (even in the absence of @autobuffer).
  900. # [12:57] <adactio> Here's the bug: https://bugs.webkit.org/show_bug.cgi?id=25267
  901. # [12:57] <brucel> will try zcorpan, thx. (Actually, will ask some flash ppl to look as I know zilch about little swfs to call in big swfs etc)
  902. # [12:58] <zcorpan> brucel: if you write an article, i could help review it
  903. # [12:58] <zcorpan> it could go from simplest case to most complext case with most requirements
  904. # [12:59] <zcorpan> 1) no fallback? use <embed>! 2) want fallback and have a small flash file? ...
  905. # [12:59] <brucel> zcorpan thanks. Actually, am going on the razzle with some guys from Adobe tomorrow in London and will bat it back to them to have a look at.
  906. # [12:59] <brucel> not bat it back, but bat it to...
  907. # [13:00] <zcorpan> ok
  908. # [13:01] * zcorpan will now spend the rest of the day to try to find <source> bugs
  909. # [13:01] <brucel> I found a way to embed YouTube vids as valid html5, but not with any fallback http://www.brucelawson.co.uk/2009/html-5-flash-embedding-and-other-validation-erors/
  910. # [13:02] <zcorpan> brucel: the <embed> alone is enough
  911. # [13:02] <adactio> brucel: for YouTube videos you can just use Flash Satay because the actual .swf file is very small so the lack of buffering doesn't really matter.
  912. # [13:03] <zcorpan> <embed src="http://www.youtube.com/v/8-pFwbHMuwA&amp;hl=en&amp;fs=1">
  913. # [13:03] <brucel> good to know, thanks chaps. I feel The Article Of Doom coming on
  914. # [13:05] <brucel> and now must get on and give annevk2 the list of developer worries about html5 that I've been collecting the last few weeks (which I promised him on Tuesday)
  915. # [13:05] <annevk2> adactio, that's not a bug in theory btw
  916. # [13:06] <adactio> annevk2: explain.
  917. # [13:06] <annevk2> adactio, UAs are free to buffer if they want
  918. # [13:06] <zcorpan> it's a bug in practice
  919. # [13:07] <adactio> annevk2: Not true. The spec says that UAs are *free to ignore the @autobuffer attribute*. That means they are free to ignore the request to autobuffer. It does not mean they are free to automatically autobuffer.
  920. # [13:07] <annevk2> adactio, that's not what it means
  921. # [13:07] <adactio> annevk2: that's how it reads.
  922. # [13:07] <annevk2> not to me
  923. # [13:07] <zcorpan> adactio: browsers are free to download whatever they want
  924. # [13:07] <zcorpan> adactio: autobuffer="" is a hint
  925. # [13:08] <zcorpan> adactio: browsers are required to download enough to show the first frame unless poster="" is present
  926. # [13:08] <zcorpan> but that's all
  927. # [13:08] <adactio> zcorpan: then the only way for an author to explicitly request no autobuffering is... by doing nothing. Because any use of the autobuffer attribute will trigger autobuffering (because it's Boolean).
  928. # [13:08] <annevk2> adactio, it's by not setting src
  929. # [13:09] <zcorpan> adactio: indeed
  930. # [13:09] <zcorpan> adactio: but authors should be able to rely on browsers doing whatever is the best experience for their users
  931. # [13:09] <zcorpan> adactio: even when faced with a page that has 30 <video src>es
  932. # [13:09] <adactio> zcorpan: my point entirely.
  933. # [13:09] <annevk2> no, your point is that the author should be in control
  934. # [13:10] <adactio> if the user agent misbehaves, the author should have some way of at least *requesting* no autobuffering.
  935. # [13:10] <zcorpan> the only way to do that is to not set the src
  936. # [13:11] <zcorpan> (if webkit had implemented suspending download, they would do it without author "requesting" suspending)
  937. # [13:11] <zcorpan> (it's just that they haven't implemented it yet)
  938. # [13:13] <adactio> The spec currently says "This attribute may be ignored altogether. " If you read what the attribute does, that means that user agents don't have to autobuffer ...not that user agents are free to autobuffer willy-nilly.
  939. # [13:13] <zcorpan> adactio: i'm pretty sure it says elsewhere that UAs are free to autobuffer willy-nilly
  940. # [13:14] <annevk2> the purpose of the attribute is to instruct UAs to buffer
  941. # [13:14] <annevk2> the purpose of the attribute is not to instruct UAs not to buffer
  942. # [13:14] <annevk2> so ignoring it cannot mean not buffering, because that was never the purpose
  943. # [13:15] * Quits: lazni (n=lazni@123.24.188.206) (Read error: 145 (Connection timed out))
  944. # [13:17] <zcorpan> "User agents may decide to not download more content at any time, e.g. after buffering five minutes of a one hour media resource, while waiting for the user to decide whether to play the resource or not, or while waiting for user input in an interactive resource."
  945. # [13:18] <zcorpan> the text on autobuffer is non-normative, and just says that it's a hint
  946. # [13:18] <zcorpan> or, the normative part is "This attribute may be ignored altogether. The attribute must be ignored if the autoplay attribute is present."
  947. # [13:19] <annevk2> reading it again it seems adactio read between the lines, which is somewhat dangerous with specs
  948. # [13:20] <zcorpan> nevertheless, it's a bug not because it violates html5 but because the user experience sucks
  949. # [13:21] <annevk2> a bug where?
  950. # [13:22] <annevk2> UAs could easily stop buffering if there's > 2 media resources
  951. # [13:22] <annevk2> for instance
  952. # [13:23] <zcorpan> a bug in webkit that it always buffers all media elements
  953. # [13:24] <zcorpan> as explained in the bug report; the bug report doesn't say that webkit violates html5, just that it's wasting bandwidth and causing unhappiness
  954. # [13:25] * jcranmer|away is now known as jcranmer
  955. # [13:32] * Joins: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  956. # [13:36] * Quits: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  957. # [13:37] * Joins: zdobersek (n=zan@cpe-92-37-74-251.dynamic.amis.net)
  958. # [13:41] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  959. # [13:48] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  960. # [13:50] * Joins: zcorpan (n=zcorpan@88.131.66.80)
  961. # [13:50] * Joins: cfq (n=cfq@client-82-3-44-202.sqy-bng-011.adsl.virginmedia.net)
  962. # [13:54] * Quits: MikeSmith (n=MikeSmit@EM114-48-113-101.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  963. # [14:03] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  964. # [14:10] * Joins: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  965. # [14:19] * Joins: pmuellr (n=pmuellr@nat/ibm/x-amcbokgkiackpxzj)
  966. # [14:24] * Joins: annodomini (n=lambda@c-75-69-96-104.hsd1.nh.comcast.net)
  967. # [14:28] * Quits: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  968. # [14:33] <mpilgrim> hsivonen: i am offended by http://lists.w3.org/Archives/Public/www-tag/2009Sep/0041.html
  969. # [14:33] <mpilgrim> i did *not* specify feed autodiscovery from my basement
  970. # [14:33] <jgraham_> mpilgrim: Someone elses's basement?
  971. # [14:33] <mpilgrim> i'm pretty sure i was on a couch
  972. # [14:34] <jgraham_> Whose basement was the couch in?
  973. # [14:34] <Lachy> Joseph responded about the about: URI scheme draft, and made most of the changes I suggested. We're just trying to figure out how to sort out the issues with section 5. Resolving "about" URIs and about:blank.
  974. # [14:34] <Lachy> http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt
  975. # [14:34] <mpilgrim> damn it, this is how rumors get started and etched in cement
  976. # [14:34] <hsivonen> mpilgrim: I'm sorry I've caused offense.
  977. # [14:35] <mpilgrim> it is, however, entirely possible that i was in my pajamas at the time
  978. # [14:35] <Lachy> I'm trying to say that unreserved URIs may be resolved in any way at all, but that some reserved URIs need to be resolved as defined. The question is, what to do about effectively reserved URIs that aren't defined to be resolvable, like about:legacy-compat
  979. # [14:36] <hsivonen> mpilgrim: I was more concerned about the "Joe" part than the "basement" part
  980. # [14:37] <mpilgrim> i understand the point
  981. # [14:37] <mpilgrim> also, for the record, i did try to create a real RFC for autodiscovery
  982. # [14:37] <hsivonen> mpilgrim: I'm aware. What happend to the I-D?
  983. # [14:38] <karlushi> there is a lot of cement in basements
  984. # [14:38] <mpilgrim> i dropped out of the scene
  985. # [14:38] <annevk2> Lachy, would it make sense to treat unrecognized URIs as about:blank and reserved URIs as defined unless defined to not resolve?
  986. # [14:38] <jgraham_> Lachy: Just make about:legacy-compat resolve to something. Preferably something funny :)
  987. # [14:38] <mpilgrim> others tried to pick it up
  988. # [14:38] * jgraham_ should not be taken seriously
  989. # [14:38] <mpilgrim> but never succeeded in taking it through the RFC process
  990. # [14:39] <hsivonen> jgraham_: that's a dangerous thing to joke about
  991. # [14:39] <annevk2> Lachy, where "reserved" is blank / legacy-compat and whatever the implementation wishes I suppose
  992. # [14:39] <hsivonen> jgraham_: or the next thing we know is that it gets defined to resolve to a DTD
  993. # [14:39] * Joins: icaaq (n=icaaaq@c-bfaae455.68-1076-74657210.cust.bredbandsbolaget.se)
  994. # [14:39] <karlushi> about:life-and-everything
  995. # [14:40] <Lachy> jgraham_, I'd prefer to let browser vendors resolve to whatever they like. e.g. Showing a page telling authors to use <!DOCTYPE html> and explaining that about:legacy-compat is to be avoided unless needed
  996. # [14:40] <Lachy> annevk2, yeah, defining that unrecognised URIs are equivalent to about:blank would be nice
  997. # [14:44] * Quits: zdobersek (n=zan@cpe-92-37-74-251.dynamic.amis.net) ("Leaving.")
  998. # [14:46] * Parts: cfq (n=cfq@client-82-3-44-202.sqy-bng-011.adsl.virginmedia.net)
  999. # [14:47] <karlushi> about:[something] could be a nice way to get information about many things, local documentation on your computer. about:weather, about:cinema, etc. doable already I guess with some browsers.
  1000. # [14:47] <karlushi> I wonder if it would work gecko.handlerService.schemes.about.1.uriTemplate
  1001. # [14:49] <Lachy> karlushi, implementations are free to implement such URIs however they like.
  1002. # [14:50] <Lachy> In fact, Netscape 4 had quite a few such URIs that were implemented to redirect to specific websites (mostly the websites of some Netscape developers at the time)
  1003. # [14:50] <annevk2> about:jwz
  1004. # [14:51] <karlushi> Lachy, yes :) was not thinking about implementation interop, more people configuring it themselves to do magic things. about:weather gives me information about the rain this morning in Montreal and slaps my face for not taking my umbrella.
  1005. # [14:51] <annevk2> led to http://www.jwz.org/gruntle/blowme.html
  1006. # [14:51] <karlushi> yep
  1007. # [14:51] <annevk2> funny story
  1008. # [14:54] * Quits: cying (n=cying@adsl-75-18-225-53.dsl.pltn13.sbcglobal.net)
  1009. # [15:01] <mpilgrim> how easy is it for, say, a firefox extension to add a new about:foo page?
  1010. # [15:02] * Parts: zcorpan (n=zcorpan@88.131.66.80)
  1011. # [15:02] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  1012. # [15:03] <annevk2> mpilgrim, might get a faster answer on irc.mozilla.org
  1013. # [15:06] <mpilgrim> eh, just idle curiosity
  1014. # [15:06] <mpilgrim> i don't actually want to go make one
  1015. # [15:06] * Quits: annodomini (n=lambda@wikipedia/lambda)
  1016. # [15:06] * mpilgrim catches up on www-tag
  1017. # [15:07] <Lachy> I think I've sorted it out. I've defined what reserved, unreserved, and unrecognised about URIs are, and then defined how each should be resolved, and the requirement for unrecognised about URIs is that they SHOULD be treated like about:blank.
  1018. # [15:08] <Lachy> I'll mail Joseph and get him to integrate it into the draft
  1019. # [15:08] * Joins: workmad3 (n=davidwor@cspool126.cs.man.ac.uk)
  1020. # [15:12] <mpilgrim> can someone give me a high-level overview of why about:blank needs to be standardized?
  1021. # [15:13] <hsivonen> mpilgrim: you do <iframe src='about:blank'> and then you want to assume thing about the sub-DOM you got
  1022. # [15:13] <hsivonen> mpilgrim: as it happens, I got hit by that one recently, because Gecko puts a doctype node in there
  1023. # [15:13] <hsivonen> s/thing/things/
  1024. # [15:14] * Joins: pmuellr_ (n=pmuellr@nat/ibm/x-kiczutagyzqtbukp)
  1025. # [15:14] <hsivonen> mpilgrim: and the reason why you want to do <iframe src='about:blank'> is that you want to obtain an HTML-mode Document object
  1026. # [15:14] <hsivonen> mpilgrim: because the factory method gives you an XML-mode object
  1027. # [15:14] <mpilgrim> interesting
  1028. # [15:15] <hsivonen> however, if you want to get an HTML-mode Document in the no-quirks mode, you lose
  1029. # [15:15] <mpilgrim> can't we just make up a new API for that?
  1030. # [15:16] <hsivonen> mpilgrim: it would be within reason to have an API for that
  1031. # [15:18] <mpilgrim> i mean, i love about:blank as much as the next webgeek
  1032. # [15:18] <mpilgrim> it's my home page, after all
  1033. # [15:18] <annevk2> mpilgrim, content uses it too
  1034. # [15:19] <annevk2> mpilgrim, and UAs have to support it in the manner described by hsivonen
  1035. # [15:19] <mpilgrim> that makes sense
  1036. # [15:19] <mpilgrim> thanks
  1037. # [15:19] <annevk2> so since HTML5 mentions it in the page loading model (or something) people like to see it registered
  1038. # [15:19] <Lachy> mpilgrim, the basic reason is that the about: URI scheme needed to be registerred to keep some people happy about about:legacy-compat being used in HTML5
  1039. # [15:20] <annevk2> and we use it for the XSLT-compat doctype now, though that's called about:legacy-compat
  1040. # [15:20] <hsivonen> which is odd, because per HTML5, the legacy-compat thingy is just a string
  1041. # [15:20] <hsivonen> the URIness kicks in when someone tries to be polyglottal with it
  1042. # [15:21] * mpilgrim is lost again
  1043. # [15:21] <hsivonen> which doesn't matter in practice, because the two people who actually do polyglot publishing don't use that doctype
  1044. # [15:22] <Lachy> mpilgrim, if someone uses <!DOCTYPE html SYSTEM "about:legacy-compat"> in an XHTML document, and some XML processor attempts to resolve it to get the DTD, then it gets treated as a URI. Whereas, in the HTML syntax, it's just an opaque identifier
  1045. # [15:22] <annevk2> hsivonen, the reason it is a URI is so that tools do not barf
  1046. # [15:23] <mpilgrim> so html5 needed to invent a bogus pseudo-URI about:legacy-compat to accomodate XSLT tools
  1047. # [15:24] <Lachy> yes
  1048. # [15:25] <Lachy> and it needed to be a URI that is intentionally unresolvable, rather than just some random string, to avoid it being treated as a relative URL by some XML processors
  1049. # [15:25] <mpilgrim> then we have to register the about: URI scheme because some tools that no one uses might interpret it as a URI
  1050. # [15:25] <mpilgrim> got it
  1051. # [15:26] <AryehGregor> hsivonen, MediaWiki could definitely use more URL normalization, but NFKC is too strict AFAIK. It would mean <http://en.wikipedia.org/wiki/²> couldn't be distinct from <http://en.wikipedia.org/wiki/2> and so on.
  1052. # [15:28] <AryehGregor> At least AFAICT.
  1053. # [15:28] * Quits: miketaylr (n=mtaylor@38.117.156.163) (Excess Flood)
  1054. # [15:28] <AryehGregor> I have no idea how the current setup works in practice for languages like Lao.
  1055. # [15:28] <hsivonen> mpilgrim: registering about:legacy-compat is a theoretical purity thing
  1056. # [15:29] <mpilgrim> indeed
  1057. # [15:29] <mpilgrim> but it doesn't actually hurt anything
  1058. # [15:29] <mpilgrim> does it?
  1059. # [15:30] * Joins: miketaylr (n=mtaylor@38.117.156.163)
  1060. # [15:30] * Quits: pmuellr (n=pmuellr@nat/ibm/x-amcbokgkiackpxzj) (Read error: 110 (Connection timed out))
  1061. # [15:30] * pmuellr_ is now known as pmuellr
  1062. # [15:32] <annevk2> mpilgrim, nope
  1063. # [15:32] <zcorpan> opportunity cost
  1064. # [15:32] * Joins: erlehmann (n=erlehman@80.187.100.40)
  1065. # [15:33] * Joins: aroben (n=aroben@unaffiliated/aroben)
  1066. # [15:33] * Joins: annodomini (n=lambda@64.30.3.122)
  1067. # [15:34] <mpilgrim> grr
  1068. # [15:34] <mpilgrim> looks like the blog.whatwg.org redesign dropped the google analytics script
  1069. # [15:35] <annevk2> oh my bad
  1070. # [15:35] <mpilgrim> adding it back...
  1071. # [15:35] <annevk2> guess we're missing stats on all the news article attention now
  1072. # [15:36] <annevk2> i was quite amused how they all failed to detect sarcasm and praised Google for being so nice
  1073. # [15:37] * Quits: wes88_ (n=chatzill@77.61.253.97) ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]")
  1074. # [15:38] <mpilgrim> ?
  1075. # [15:39] <erlehmann> annevk2, its not too late to slip it into slashdots idle queue ;)
  1076. # [15:40] <annevk2> mpilgrim, well, they didn't actually praise Google, I made that up
  1077. # [15:41] <hsivonen> AryehGregor: it's quite possible that the right fix is to keep MediaWiki as is and configure the Jena IRI lib differently for V.nu
  1078. # [15:42] <hsivonen> AryehGregor: however, if that's the right answer, it's a bit annoying that the RFC gives advice that isn't practical for Wikipedia
  1079. # [15:42] <AryehGregor> hsivonen, well, changing MediaWiki to normalize more strictly would be a headache due to the millions of existing pages. We're not going to do that anytime soon anyway, without some pressing reason.
  1080. # [15:42] <hsivonen> AryehGregor: seems reasonable
  1081. # [15:42] <AryehGregor> NFKC seems like it's only good for stuff like search indexes, I don't see how it's usable for actual display.
  1082. # [15:43] <AryehGregor> Well, maybe the specific ²/2 case would be handled in HTML output with the <sup> compat thing, but that doesn't help for URLs or <title>s.
  1083. # [15:43] <hsivonen> Wikipedia URLs are a kind of a search index, though
  1084. # [15:44] <annevk2> I would advice against using NFKC
  1085. # [15:44] <annevk2> you will actually lose things then
  1086. # [15:44] <annevk2> NFC is god enough for IRIs
  1087. # [15:45] <hsivonen> annevk2: ooh. you disagree with RFC-given advice! :-)
  1088. # [15:45] <AryehGregor> hsivonen, by "search indexes" I mean non-user-visible stuff. Like convert to NFKC for the index, and convert the query to NFKC before searching, then return the actual result in NFC.
  1089. # [15:45] <hsivonen> AryehGregor: ok
  1090. # [15:46] <annevk2> I don't want my fullwidth latin to be turned into ordinary latin :)
  1091. # [15:47] * Joins: rubys (n=rubys@65.190.139.141)
  1092. # [15:49] * Quits: annodomini (n=lambda@wikipedia/lambda)
  1093. # [16:00] * Joins: erlehmann_ (n=erlehman@tmo-104-92.customers.d1-online.com)
  1094. # [16:03] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  1095. # [16:06] * Joins: annodomini (n=lambda@130.189.179.215)
  1096. # [16:06] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  1097. # [16:07] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  1098. # [16:08] * Quits: erlehmann (n=erlehman@80.187.100.40) (Read error: 145 (Connection timed out))
  1099. # [16:11] * AryehGregor wants a joystick-controlled binary file editor projected onto a 3D hologram system.
  1100. # [16:14] * Joins: boblet (n=boblet@p1254-ipbf304osakakita.osaka.ocn.ne.jp)
  1101. # [16:16] * Joins: Midler (n=midler@212.37.124.233)
  1102. # [16:18] * Joins: Steve^ (n=steve@94.197.232.136.threembb.co.uk)
  1103. # [16:18] * Joins: TabAtkins (n=chatzill@adsl-76-195-204-109.dsl.hstntx.sbcglobal.net)
  1104. # [16:23] * Joins: starjive (i=beos@213-66-216-93-no30.tbcn.telia.com)
  1105. # [16:24] * Joins: cying (n=cying@adsl-75-18-225-53.dsl.pltn13.sbcglobal.net)
  1106. # [16:26] * Parts: annevk42 (n=annevk@5355732C.cable.casema.nl)
  1107. # [16:35] * Joins: dglazkov (n=dglazkov@67.188.0.62)
  1108. # [16:38] * Joins: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net)
  1109. # [16:41] * Quits: workmad3 (n=davidwor@cspool126.cs.man.ac.uk)
  1110. # [16:41] <Lachy> AryehGregor, how would joystick control work in an editor?
  1111. # [16:41] <AryehGregor> Lachy, I don't know, ask Hixie.
  1112. # [16:42] <Lachy> did Hixie say something about it that I missed?
  1113. # [16:42] <AryehGregor> Lachy, http://lists.w3.org/Archives/Public/www-style/2009Sep/0176.html
  1114. # [16:43] <Lachy> haha
  1115. # [16:44] * Joins: onar_ (n=onar@67.180.87.66)
  1116. # [16:45] <Lachy> maybe 1's and 0's would be projected onto a curved, 3D workspace, and the joystick could be moved left and right to move the cursor, and up and down to change a bit to 0 or 1. :-)
  1117. # [16:45] <Lachy> and the fire button for deleting
  1118. # [16:45] <TabAtkins> I think it would be best to have it like a racing game, where you keep being faced with a choice of 1 or 0 and dodge left and right to build up the code.
  1119. # [16:46] <TabAtkins> But then I think I'm just influenced by that super-awesome mouse-based typing thing I saw once that worked like that, but with predictive display that made more likely next-letters larger.
  1120. # [16:47] * Parts: Midler (n=midler@212.37.124.233) ("Leaving.")
  1121. # [16:47] <TabAtkins> Lachy: your mail program is messing with formatting. I had spaces before all the elements in my last email, but when you quoted me they disappeared (and now join with the previous word).
  1122. # [16:48] <AryehGregor> gsnedders, yesterday I was just diagnosed as probably having chronic fatigue syndrome too.
  1123. # [16:48] * AryehGregor commiserates
  1124. # [16:49] <Lachy> TabAtkins, what? Your mail is here http://lists.w3.org/Archives/Public/public-html/2009Sep/0759.html and the quote looks the same here http://lists.w3.org/Archives/Public/public-html/2009Sep/0762.html
  1125. # [16:50] <Lachy> btw, this reminds of a MacBook parody I saw once that replaced they keyboard with a giant touch pad, and required complicated gestures to type stuff
  1126. # [16:50] <TabAtkins> Look closer, Lachy. For example, in my original email I typed "second <h1>", and in your quote of my email it shows up as "second<h1>".
  1127. # [16:50] <Lachy> oh, it was the MacBook Wheel http://www.theonion.com/content/video/apple_introduces_revolutionary :-)
  1128. # [16:51] * Quits: dglazkov (n=dglazkov@67.188.0.62)
  1129. # [16:51] <Lachy> oh, weird.
  1130. # [16:52] * Quits: onar_ (n=onar@67.180.87.66)
  1131. # [16:53] <TabAtkins> Anyway, I guess I agree with you that using <h1>, at least in the manner I described, is unworkable.
  1132. # [16:53] <Lachy> I'm not too surprised though. I'm using Postbox, and they've messed up a few issues with their support for format=flowed
  1133. # [16:54] <TabAtkins> Who was it yesterday that suggested <p caption>?
  1134. # [16:55] <TabAtkins> I'm writing up a response email, and I want to promote that now. I like it more as time goes on.
  1135. # [16:55] <Lachy> me
  1136. # [16:55] * Joins: sicking (n=chatzill@c-69-181-197-163.hsd1.ca.comcast.net)
  1137. # [16:55] <Lachy> I'm not a huge fan of the idea myself though
  1138. # [16:55] <TabAtkins> I'm suggesting it anyway.
  1139. # [16:55] <TabAtkins> I like it better than minting a new element.
  1140. # [16:55] <Lachy> ok
  1141. # [16:55] * Quits: derferman (n=kjconroy@136.152.170.253)
  1142. # [16:57] <Steve^> <p caption> sounds weird, nothing else is done like that?
  1143. # [17:01] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  1144. # [17:03] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  1145. # [17:04] <TabAtkins> <time pubdate> is done like that now.
  1146. # [17:06] * Joins: ttepasse (n=ttepas--@dslb-084-060-012-022.pools.arcor-ip.net)
  1147. # [17:06] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  1148. # [17:07] * Quits: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  1149. # [17:09] <annevk2> TabAtkins, that's different
  1150. # [17:09] <annevk2> <p> is nothing like a caption
  1151. # [17:09] <TabAtkins> If you're using it as a caption, it is. But then <div> could be too, or <ul>.
  1152. # [17:09] <annevk2> -_-
  1153. # [17:10] <Steve^> can I <h1 caption>?
  1154. # [17:10] <TabAtkins> Yup.
  1155. # [17:10] <Steve^> pubdate is a specific type of time
  1156. # [17:10] <Steve^> whereas caption can attach to lots of things
  1157. # [17:10] <TabAtkins> Hmm, I don't understand the distinction, Steve^.
  1158. # [17:11] * Joins: lazni (n=lazni@118.71.115.2)
  1159. # [17:11] <TabAtkins> As long as there's no behavioral differences in DOM terms, just a semantic difference, then both are just saying that a particular element has special significance to its parent.
  1160. # [17:12] * Joins: dglazkov (n=dglazkov@nat/google/x-zeutyehahaqauthr)
  1161. # [17:12] <annevk2> Steve^ said what I meant
  1162. # [17:12] <annevk2> anyway, bikeshed discussions are a wot
  1163. # [17:12] <Steve^> with time pubdate, the important bit is time, pubdate is a specific bit. You parse time, then pubdate. In this case, the parser needs to search within its children for a caption
  1164. # [17:13] <Steve^> I suppose it doesn't need to.. hmm
  1165. # [17:13] <Steve^> it feels wrong
  1166. # [17:14] * Quits: erlehmann_ (n=erlehman@tmo-104-92.customers.d1-online.com) (Read error: 110 (Connection timed out))
  1167. # [17:16] <TabAtkins> As far as I know, the caption of a figure is not treated specially in any way. It's just a semantic distinction, useful for UAs that care, but it doesn't have any behavioral difference.
  1168. # [17:18] <TabAtkins> annevk2: Yeah, I agree, but whatcha gonna do. Some people threaten Formal Objections over these types of things. I just think <dt>/<dd> in <figure> looks really ugly, but I dont' object to it forcefully or anything.
  1169. # [17:18] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  1170. # [17:18] <Steve^> <p legend>
  1171. # [17:19] <TabAtkins> Steve^: pubdate isn't actually a quality of the <time> itself, though. It's a linkage between one particular <time> and its enclosing <article>, and could just as well be an attribute on the <article> that took an IDREF.
  1172. # [17:19] * Joins: derferman (n=kjconroy@76.126.163.164)
  1173. # [17:19] <TabAtkins> I have no attachment to the name of the attribute whatsoever; I just thought that people liked "caption".
  1174. # [17:19] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  1175. # [17:20] * Parts: derferman (n=kjconroy@76.126.163.164)
  1176. # [17:20] <Steve^> <ul nav>
  1177. # [17:20] <brucel> <div section>
  1178. # [17:20] <TabAtkins> At that point you get into problems, as those have behaviors associated with them wrt the outline algorithm.
  1179. # [17:21] <TabAtkins> This approach is *definitely* not appropriate past a certain point.
  1180. # [17:21] <brucel> <div role=section">, <p role="caption"> yay. (</sarcasm>
  1181. # [17:21] <Lachy> TabAtkins, the caption may be given special default rendering distinct from an elements normal styling, if Hixie accepts my previous suggestion
  1182. # [17:22] <TabAtkins> Lachy: I must have missed that suggestion.
  1183. # [17:22] * Joins: yutak_home (n=kee@M006079.ppp.dion.ne.jp)
  1184. # [17:22] <Lachy> that would basically make figure display: table; and the caption display: table-caption; and a default caption-side set to top or bottom, based on whether or not it's the first child
  1185. # [17:22] <Steve^> how about <section><h1 outline>foo</h1><h2>bar</h2> to avoid hgroup?
  1186. # [17:23] <TabAtkins> Steve^, I'm not sure how that's supposed to work.
  1187. # [17:23] <Lachy> Steve^, no, as that would require an outline attribute on all h1s intended to be in the outlien
  1188. # [17:23] <Lachy> *outline
  1189. # [17:23] * Joins: paul_irish (n=paul_iri@12.33.239.250)
  1190. # [17:23] <Steve^> Oh. I JUST understood what hgroup is for.
  1191. # [17:24] <Steve^> I thought I knew, but now I really know.
  1192. # [17:24] <Lachy> TabAtkins, that styling suggestion was sent about a year or so ago, but it was linked to recently
  1193. # [17:24] <Lachy> I will find it
  1194. # [17:24] <Steve^> ("hiding from the outline algorithm" was too vague for me)
  1195. # [17:24] <TabAtkins> Nah, I get it Lachy.
  1196. # [17:25] <TabAtkins> But I'm not sure that rendering differences are important enough to make an attribute a bad solution here.
  1197. # [17:26] <Lachy> http://lists.w3.org/Archives/Public/public-html/2007Sep/0375.html
  1198. # [17:26] * TabAtkins notes that your suggested rendering would give it a fairly attractive appearance by default, though.
  1199. # [17:26] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  1200. # [17:27] <TabAtkins> figure>[caption] { display: table-caption; caption-side:bottom;} figure>[caption]:first-child { caption-side:top; }?
  1201. # [17:27] <Steve^> label.. that's a good idea
  1202. # [17:27] <Lachy> it would make things complicated, since browser vendors would have to design appropriate default styles for all elements that could potentially have a caption attribute, and that could mean changing margins, padding, borders, font styles or whatever else
  1203. # [17:27] <Lachy> Steve^, no, it's a bad idea. It's unworkable for several reasons
  1204. # [17:27] <TabAtkins> Steve^: <label> prevents you from using any form elements inside of it.
  1205. # [17:28] <Steve^> why?
  1206. # [17:28] <TabAtkins> Lachy: But in your suggestions, the *only* change made to the styling is a display change.
  1207. # [17:28] <TabAtkins> Steve^, because it will auto-focus the first such element, preventing you from clicking on anything else.
  1208. # [17:29] <Lachy> that's because at the time, it was based on restyling label, which has acceptable defaults for everything else
  1209. # [17:29] <TabAtkins> I can see killing margins on [caption] in general, but off the top of my head that's the only change necessary.
  1210. # [17:30] <TabAtkins> And there's the obvious work-around (that actually has a visual effect, so it'll be used when necessary) of just wrapping an offending element in a <div caption> rather than making it [caption] itself.
  1211. # [17:30] * aroben is now known as aroben|phone
  1212. # [17:31] <TabAtkins> Which wouldn't be any worse than <new element><something here></newelement>
  1213. # [17:32] <TabAtkins> Frex, <button caption> would probably display pretty oddly.
  1214. # [17:32] * TabAtkins goes off to try it out.
  1215. # [17:37] * Quits: wakaba_ (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) ("Leaving...")
  1216. # [17:38] <TabAtkins> Okay, <button>s refuse to becom table captions at all in FF.
  1217. # [17:38] <TabAtkins> But otherwise this works well enough.
  1218. # [17:39] * Joins: erlehmann (n=erlehman@tmo-104-92.customers.d1-online.com)
  1219. # [17:40] <TabAtkins> Hmm, FF doesn't collapse margins through a display:table-caption element that's been visually moved.
  1220. # [17:46] * Quits: erlehmann (n=erlehman@tmo-104-92.customers.d1-online.com) (Read error: 113 (No route to host))
  1221. # [17:47] * Joins: erlehmann (n=erlehman@tmo-104-92.customers.d1-online.com)
  1222. # [17:48] * Quits: drunknbass (n=drunknba@cpe-76-173-187-247.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
  1223. # [17:49] * Quits: mat_t (n=mattomas@91.189.88.12) (Remote closed the connection)
  1224. # [17:50] * Joins: mat_t (n=mattomas@91.189.88.12)
  1225. # [17:51] * Joins: Craig` (i=586d7a8d@gateway/web/freenode/x-rtqthtiobfauuwyo)
  1226. # [17:51] * aroben|phone is now known as aroben
  1227. # [17:52] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  1228. # [17:52] <mitnavn> Does the canvas element only work with a pixel based grid?
  1229. # [17:52] * Parts: Craig` (i=586d7a8d@gateway/web/freenode/x-rtqthtiobfauuwyo)
  1230. # [17:55] <Dashiva> mitnavn: As opposed to?
  1231. # [17:55] <mitnavn> Percent
  1232. # [17:56] <Dashiva> Yes
  1233. # [17:56] <TabAtkins> If you're working in script, though, you can fake percentages trivially.
  1234. # [17:56] <Philip`> You could use scale() so that all the coordinates are from 0 to 100, if you want
  1235. # [17:57] <Philip`> ctx.scale(canvas.width/100, canvas.height/100) I think
  1236. # [17:57] <mitnavn> Ah, cool.
  1237. # [18:01] <brucel> Possible to use the <audio> element to embed midi audio in a page?
  1238. # [18:01] <TabAtkins> Is there any way to link to the effective root when you're using <base>?
  1239. # [18:01] <TabAtkins> brucel: Not unless anybody has a decoder for that.
  1240. # [18:01] <TabAtkins> Which I don't think anyone does.
  1241. # [18:02] <brucel> tragedy
  1242. # [18:02] <TabAtkins> I think stopping the promulgation of midi is far from a tragedy. ^_^
  1243. # [18:02] <brucel> the lack of decoder, not the tragedy.mid
  1244. # [18:03] * Quits: sicking (n=chatzill@c-69-181-197-163.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  1245. # [18:03] * Quits: rubys (n=rubys@65.190.139.141) (Read error: 148 (No route to host))
  1246. # [18:03] <brucel> it was for a fun retro demo page. ah well....
  1247. # [18:03] * Joins: virtuelv (n=virtuelv@125.175.251.212.customer.cdi.no)
  1248. # [18:03] <TabAtkins> Can you convert to .wav?
  1249. # [18:03] * brucel is now known as clownabuser
  1250. # [18:04] <Philip`> Does Windows not come with a MIDI synthesiser by default?
  1251. # [18:04] * Philip` kind of assumed it did, but he hasn't used MIDI since about ten years ago, and it was all done by Creative drivers back then
  1252. # [18:04] <TabAtkins> I think it probably does?
  1253. # [18:05] <TabAtkins> Yeah, I haven't used one in years either.
  1254. # [18:05] <clownabuser> like your style, TabAtkins - the mellifluous strains of MIDI, with the bandwidth-bashing lack of compression that WAV gives.
  1255. # [18:05] <TabAtkins> But I'll bet media player can do it.
  1256. # [18:05] <Lachy> clownabuser, if QuickTime supports midi, then Safari will support it in <audio>
  1257. # [18:05] <TabAtkins> ...I'm going to keep calling you brucel.
  1258. # [18:05] * Joins: dave_levin (n=dave_lev@74.125.59.65)
  1259. # [18:05] <TabAtkins> Does WAV get much benefit from ordinary gzipping?
  1260. # [18:05] <Philip`> Why do you use clown abs?
  1261. # [18:06] <TabAtkins> I suspect it would.
  1262. # [18:06] <Philip`> TabAtkins: No
  1263. # [18:06] <clownabuser> I deny all knowledge of brucel, in case people associate me with the midi question
  1264. # [18:06] <TabAtkins> Philip`, damn.
  1265. # [18:06] <Philip`> You might save 50% or so, which is rubbish
  1266. # [18:06] <clownabuser> clownabuser is an anagram of Bruce Lawson, that someone tweeted me with
  1267. # [18:06] <Lachy> haha
  1268. # [18:06] <clownabuser> have never liked clowns
  1269. # [18:07] * TabAtkins is now known as BaitTanks
  1270. # [18:07] * boblet is now known as dullsmoothie
  1271. # [18:07] <Lachy> ClownAbUser, why?
  1272. # [18:07] <clownabuser> sinister buggers, the lot of them
  1273. # [18:08] <BaitTanks> Clowns are scary.
  1274. # [18:08] <BaitTanks> To me, for the same reasons that zombies and wax museums are scary.
  1275. # [18:08] <BaitTanks> I suspect it's the Uncanny Valley.
  1276. # [18:08] <Lachy> I've never met a scary clown. I really don't get why some people think they are
  1277. # [18:08] * beowulf is now known as WebFoul
  1278. # [18:08] <BaitTanks> I always get creeped out by clowns.
  1279. # [18:08] <clownabuser> Scary clowns are banned from the Oslo metropolitan limits
  1280. # [18:08] <WebFoul> one letter out...
  1281. # [18:09] <clownabuser> which is why you've never met one Lachy
  1282. # [18:09] <Lachy> BaitTanks, wax museums, sure. But zombies?! What's scary about those cute, undead creatures?
  1283. # [18:09] * WebFoul is now known as beowulf
  1284. # [18:09] <BaitTanks> A zombie is just an animate wax museum.
  1285. # [18:09] <Lachy> clownabuser, I've never met a clown in Oslo. Hmm... I wonder why?
  1286. # [18:09] <Steve^> Lachy is fearless, apparently
  1287. # [18:09] <adactio> BaitTanks. "Explain it to me with Star Wars." http://kotaku.com/384789/the-uncanny-valley-explained-in-terms-of-porn-and-star-wars
  1288. # [18:09] * Quits: lazni (n=lazni@118.71.115.2) (Read error: 110 (Connection timed out))
  1289. # [18:10] <Steve^> I suppose if you can survive the Koala attacks, you're ready for anything
  1290. # [18:10] <clownabuser> it's the snow Lachy. Their oversize shoes get fillled with snow and they can't move, so hypothermia gets them
  1291. # [18:11] <Steve^> and then the reindeer eat them
  1292. # [18:12] <dullsmoothie> adactio: har!
  1293. # [18:13] <BaitTanks> Hehe, adactio. Thanks for that.
  1294. # [18:13] * Lachy is tying to find a cool anagram for my name, like clownabuser's, but all he can come up with is "tuna can" with 2 H's and 2 L's left over. :-(
  1295. # [18:13] <BaitTanks> Lachy: http://wordsmith.org/anagram/anagram.cgi?anagram=lachlanhunt&t=1000&a=n
  1296. # [18:13] <Steve^> The Lawson Practice is just round the corner from me. They denied the existence of Dr Bruce and refused to heal my HTML5itis :( (http://www.lawsonpractice.nhs.uk/)
  1297. # [18:13] <dullsmoothie> Lachy: sticking with the Star Wars theme: http://deanjackson.dj/nameanagram/index.php?n=lachy+hunt
  1298. # [18:13] * Joins: tantek (n=tantek@70.36.139.108)
  1299. # [18:13] <Lachy> clownabuser, I don't think the oversize shoes are a problem. You've seen mine! My size 17 (52 in European) whoppers aren't a problem
  1300. # [18:14] <Dashiva> dullsmoothie: Too bad he isn't called Huntt
  1301. # [18:14] <BaitTanks> God damn, Lachy. I'm just a 14. You have ridiculous feet.
  1302. # [18:14] <clownabuser> hmm. Are you perchance an incognito clown, hence leaping to their defence?
  1303. # [18:14] * Lachy is now known as Launch
  1304. # [18:14] * Launch is now known as LaunchNHalt
  1305. # [18:15] <BaitTanks> Like a StopNGo in space?
  1306. # [18:17] <LaunchNHalt> BaitTanks, people thought I had ridiculously large feet when mine were size 14
  1307. # [18:17] <Steve^> the surface area of your feet is proportional to your weight. Ish.
  1308. # [18:17] <LaunchNHalt> of course, that's back when I was 14 years old, so perhaps it was at the time
  1309. # [18:17] <gsnedders> AryehGregor: How bad is it for you?
  1310. # [18:18] <LaunchNHalt> Steve^, in my case, ever since I was 13, my shoe size matched my age till I reached 17 :-)
  1311. # [18:19] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  1312. # [18:21] * gsnedders grumbles about the messiness of this desk
  1313. # [18:22] * Quits: Creap (n=Creap@vemod.brg.sgsnet.se) ("nu fkt")
  1314. # [18:22] * LaunchNHalt is now known as Lachy
  1315. # [18:23] * Quits: erlehmann (n=erlehman@tmo-104-92.customers.d1-online.com) (Read error: 104 (Connection reset by peer))
  1316. # [18:24] <gsnedders> Steve^: Really? I'm UK 10/Euro 44 and 56kg… :\
  1317. # [18:25] <Steve^> big feet for your weight then
  1318. # [18:25] * da3d is now known as ArsonSlanders
  1319. # [18:25] <gsnedders> I'm also around 180cm
  1320. # [18:25] <Steve^> what colour is your hair?
  1321. # [18:26] * Steve^ builds a criminal profile
  1322. # [18:26] <gsnedders> Steve^: Brown
  1323. # [18:28] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 54 (Connection reset by peer))
  1324. # [18:31] * eric_carlson is now known as ericc|away
  1325. # [18:33] * Joins: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  1326. # [18:37] * Joins: ap (n=ap@17.246.19.174)
  1327. # [18:38] * ArsonSlanders is now known as da3d
  1328. # [18:48] * Joins: Binarytales (n=Binaryta@host81-157-255-224.range81-157.btcentralplus.com)
  1329. # [18:50] * Parts: Binarytales (n=Binaryta@host81-157-255-224.range81-157.btcentralplus.com)
  1330. # [18:50] * Joins: Binarytales (n=Binaryta@host81-157-255-224.range81-157.btcentralplus.com)
  1331. # [18:55] * Joins: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi)
  1332. # [18:56] * Quits: webben (n=benh@nat/yahoo/x-vbpxufxpvgvolesh) (Client Quit)
  1333. # [19:00] * Parts: adactio (n=adactio@host86-138-101-27.range86-138.btcentralplus.com)
  1334. # [19:00] <Steve^> Mac users, how do I maximise the itunes window to full the screen? Tried double click and the green + made it smaller
  1335. # [19:00] * Joins: zdobersek (n=zan@cpe-92-37-78-54.dynamic.amis.net)
  1336. # [19:00] * Parts: clownabuser (n=brucel@92-236-144-120.cable.ubr10.smal.blueyonder.co.uk)
  1337. # [19:01] <gsnedders> Steve^: OS X has no concept of maximize, ever.
  1338. # [19:01] <gsnedders> Steve^: Only fit-to-content/minify depending on application
  1339. # [19:01] <dullsmoothie> Steve^: drag window resize handle + reposition
  1340. # [19:02] * Joins: cying_ (n=cying@70.90.171.153)
  1341. # [19:02] <Steve^> how.. primitive
  1342. # [19:02] <dullsmoothie> although in visualiser mode there’s probably a fill screen option
  1343. # [19:02] <dullsmoothie> no, definitely
  1344. # [19:02] <Steve^> I liked a song in Genius and tried to show a list of songs by that artist
  1345. # [19:02] <Steve^> nope
  1346. # [19:03] <Steve^> must search manually
  1347. # [19:03] <Steve^> I'm happy my girlfriend doesn't use Windows, but I don't understand Macs at all
  1348. # [19:04] <gsnedders> Most other OSes make the effort for the fit-to-content option, which sucks also
  1349. # [19:06] * Parts: dullsmoothie (n=boblet@p1254-ipbf304osakakita.osaka.ocn.ne.jp)
  1350. # [19:07] * Joins: workmad3 (n=davidwor@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  1351. # [19:11] * Joins: sicking (n=chatzill@nat/mozilla/x-spequpbjvsvbzwgq)
  1352. # [19:13] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  1353. # [19:13] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  1354. # [19:16] * Joins: drunknbass_wor (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
  1355. # [19:19] * Quits: Binarytales (n=Binaryta@host81-157-255-224.range81-157.btcentralplus.com)
  1356. # [19:19] * BaitTanks is now known as TabAtkins
  1357. # [19:21] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
  1358. # [19:22] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Read error: 60 (Operation timed out))
  1359. # [19:26] * Joins: mat_t (n=mattomas@91.189.88.12)
  1360. # [19:36] * Joins: slightlyoff (n=slightly@nat/google/x-gptiourzmqhubddt)
  1361. # [19:37] * Quits: slightlyoff (n=slightly@nat/google/x-gptiourzmqhubddt) (Client Quit)
  1362. # [19:41] <mpilgrim> http://arstechnica.com/microsoft/news/2009/09/ie-program-manager-endorses-html-5-multimedia-tags.ars
  1363. # [19:41] * Quits: tantek (n=tantek@70.36.139.108)
  1364. # [19:42] <mpilgrim> which leads people to think things like http://www.programmica.info/2009/09/google-praises-microsoft.html
  1365. # [19:43] <mpilgrim> it's like a game of "whisper down the lane"
  1366. # [19:44] <mpilgrim> by the time it hits slashdot, the headline will be "Google and Microsoft announce revolutionary new web video standard!!!"
  1367. # [19:45] <mpilgrim> TechChrunch will publish an unsubstantiated rumor that Youtube is switching to Windows Media
  1368. # [19:45] <TabAtkins> Hehe
  1369. # [19:46] <mpilgrim> Mac forums will go ballistic and try to start a boycott of all Google products
  1370. # [19:47] * Joins: jamesr (n=jamesr@nat/google/x-qvrrzmwvdclfqwet)
  1371. # [19:47] <mpilgrim> dave winer will start a mailing list to discuss the creation of a brand new video standard, built from scratch and based on OPML
  1372. # [19:47] * Joins: ttepass- (n=ttepas--@dslb-084-060-030-247.pools.arcor-ip.net)
  1373. # [19:48] <Steve^> sounds like some zany apocalyse prediction
  1374. # [19:48] <Steve^> apocalypse
  1375. # [19:51] <mpilgrim> and zeldman will post a fancy "to whom it may concern" open letter in franklin gothic medium condensed oblique, undersigned by a list of prominent mac-using designers who oppose the video element on the grounds that the letter "v" is awkward and ungainly
  1376. # [19:51] * Quits: icaaq (n=icaaaq@c-bfaae455.68-1076-74657210.cust.bredbandsbolaget.se)
  1377. # [19:52] * Quits: sicking (n=chatzill@nat/mozilla/x-spequpbjvsvbzwgq) (Remote closed the connection)
  1378. # [19:57] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  1379. # [19:58] * Quits: ttepasse (n=ttepas--@dslb-084-060-012-022.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
  1380. # [19:59] * Quits: mat_t (n=mattomas@91.189.88.12) (Remote closed the connection)
  1381. # [20:01] <AryehGregor> gsnedders, seriously aggravating but not debilitating.
  1382. # [20:01] <AryehGregor> mpilgrim, hey, at least he apparently read the actual mailing list posts you linked to. Could be worse.
  1383. # [20:01] <AryehGregor> Well, Ars Technica did, I mean.
  1384. # [20:01] * Joins: hobertoAtWork (n=hobertoa@gw1.mcgraw-hill.com)
  1385. # [20:02] <AryehGregor> . . . the second one is awful starting from the subject line.
  1386. # [20:02] <AryehGregor> Is "HTML5 evangelist" actually your job or anything?
  1387. # [20:03] <AryehGregor> Okay, the second one is retarded, I agree.
  1388. # [20:03] <AryehGregor> On the other hand, at least it's a better tone than some of the +5 comments on the Slashdot post on the original mailing list post, which tended to be along the lines of "Look at evil Microsoft criticizing HTML5!!!!"
  1389. # [20:06] * Joins: benward (n=benward@nat/yahoo/x-kchocvmellvtwxml)
  1390. # [20:08] * Joins: weinig (n=weinig@17.246.16.129)
  1391. # [20:08] * Quits: weinig (n=weinig@17.246.16.129) (Client Quit)
  1392. # [20:08] * Joins: weinig (n=weinig@17.246.16.129)
  1393. # [20:28] * Joins: erlehmann (n=erlehman@p5DDBA72B.dip.t-dialin.net)
  1394. # [20:31] * aroben is now known as aroben|meeting
  1395. # [20:32] * erlehmann is now known as erl[oberholz]
  1396. # [20:38] * Joins: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  1397. # [20:38] * Joins: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  1398. # [20:39] * Quits: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net) (Client Quit)
  1399. # [20:39] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  1400. # [20:40] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  1401. # [20:44] * ericc|away is now known as eric_carlson
  1402. # [20:47] <erl[oberholz]> That thing you burned up isn't really important to me. It's the <dialog> unit. It made shoes for orphans. Nice job breaking it, hickson.
  1403. # [20:55] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  1404. # [20:55] <Philip`> erl[oberholz]: Don't worry, you're still alive
  1405. # [20:59] <Steve^> I'm not quite sure what that means "It made shoes for orphans"
  1406. # [21:00] <Philip`> It's just a reference to some dialogue somewhere
  1407. # [21:01] <TabAtkins> Can anyone else load http://software.hixie.ch/utilities/js/live-dom-viewer/saved/235 in ie8?
  1408. # [21:01] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  1409. # [21:01] <TabAtkins> I'm getting a yellow-bar saying that it decided to break the page to prevent XSS.
  1410. # [21:02] <erl[oberholz]> Steve^, read <http://en.wikiquote.org/wiki/Portal_(game)> ,but replace "Aperture Science Enrichment Center" with "WHATWG" ;)
  1411. # [21:03] <Steve^> ohhh
  1412. # [21:03] <Steve^> ok :)
  1413. # [21:03] <erl[oberholz]> TabAtkins, interesting. can you spot what exactly triggers the XSS?
  1414. # [21:04] <AryehGregor> I didn't recognize the quote on first glance. Clearly I need to replay Portal.
  1415. # [21:04] <erl[oberholz]> err, the XSS detection.
  1416. # [21:04] <TabAtkins> erl[oberholz]: The code that is trying to load includes a <script> tag to get IE to recognize <figure>, which I'm guessing IE recognizes in the url and kills
  1417. # [21:05] <AryehGregor> Blast! The guy with nick "aryeh" logged on a week ago. Foiled!
  1418. # [21:05] * AryehGregor will have to wait another 67 days or so for his next chance
  1419. # [21:05] <TabAtkins> AryehGregor: Heh, does registration last 75 days or something?
  1420. # [21:06] <erl[oberholz]> TabAtkins, so essentially any javascript input for hixies DOM viewer will trigger IE8 XSS detection?
  1421. # [21:06] <TabAtkins> erl[oberholz]: Dunno how general it is. I'd have to do some testing.
  1422. # [21:06] <AryehGregor> You can ask to usurp a nick after 60 days of inactivity. I asked on his 60th day of inactivity, and was told that since his nick had been registered for two years, I had to wait another two weeks.
  1423. # [21:06] <AryehGregor> Which he used to log on. >:(
  1424. # [21:06] <TabAtkins> Sucks. I'll bet it sends an email.
  1425. # [21:07] <AryehGregor> "it" being freenode staff?
  1426. # [21:07] * AryehGregor tries to think of another good nick
  1427. # [21:07] <AryehGregor> aryehg?
  1428. # [21:07] <TabAtkins> AryehGregor: I assumed NickServ was largely autonomous. Guess I was wrong.
  1429. # [21:08] <AryehGregor> It is, but usurping isn't.
  1430. # [21:08] <TabAtkins> erl[oberholz]: http://software.hixie.ch/utilities/js/live-dom-viewer/?<!doctype%20html><script></script>
  1431. # [21:08] <TabAtkins> Looks like it
  1432. # [21:08] <AryehGregor> You need to ask staff.
  1433. # [21:08] <AryehGregor> erl[oberholz], it's rather the point of the XSS detection thing that it raises alarms if it detects scripts being injected from the URL.
  1434. # [21:08] <AryehGregor> That's practically the definition of XSS, after all.
  1435. # [21:09] <AryehGregor> It just so happens that most of us don't have any useful cookies or such set on software.hixie.ch, so nobody's going to bother luring us there with malicious JS in the URL.
  1436. # [21:09] <erl[oberholz]> hehe
  1437. # [21:09] <erl[oberholz]> purrfect :D
  1438. # [21:11] * Joins: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  1439. # [21:12] <annodomini> NoScript seems to block input to the DOM viewer, too.
  1440. # [21:12] <AryehGregor> . . . maybe because it's script-based?
  1441. # [21:13] <annodomini> NoScript is actually very aggressive about it; it strips out everything that looks like an HTML tag.
  1442. # [21:13] <annodomini> (as part of its XSS blocking tools)
  1443. # [21:16] * Quits: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  1444. # [21:18] * Joins: dpranke (n=Adium@nat/google/x-fbvcbpuzjayivkbm)
  1445. # [21:18] <annodomini> So, is there any particular reason that <title> is the only required element in HTML? Is there a good reason that it's required?
  1446. # [21:19] <AryehGregor> It would make test cases smaller if it weren't.
  1447. # [21:19] <AryehGregor> (I mean, that's not a reason it's required, I'm agreeing with your question)
  1448. # [21:19] <annodomini> Right.
  1449. # [21:19] <AryehGregor> It's usually going to be an error if it's omitted, though.
  1450. # [21:19] * aroben|meeting is now known as aroben|lunch
  1451. # [21:20] <annodomini> Well, there are lots of cases in which you can have a document but don't need a title.
  1452. # [21:20] <TabAtkins> Thus all the <title>Untitled Document</title> pages on the web.
  1453. # [21:20] <annodomini> For instance, HTML email, pages which are always intended to be framed (like gadgets), etc.
  1454. # [21:20] <annodomini> Yeah. That seems to me to be about the equivalent of alt="img001" or whatever.
  1455. # [21:21] <annodomini> It would be more useful not to have it, so if you really need a title, the browser could use the URL or a component of it, or maybe extract the top level heading, or something.
  1456. # [21:22] <erl[oberholz]> interesting issue.
  1457. # [21:22] <erl[oberholz]> i second annodomini.
  1458. # [21:22] <AryehGregor> It's been discussed before a bunch of times.
  1459. # [21:22] <AryehGregor> But I hadn't thought of iframes and such.
  1460. # [21:22] <AryehGregor> You're right, it's really fairly pointless in those cases.
  1461. # [21:22] <erl[oberholz]> AryehGregor, so what was the reason of keeping it?
  1462. # [21:22] <AryehGregor> I dunno.
  1463. # [21:22] * annodomini starts searching through archives
  1464. # [21:27] <Steve^> everything should have a title, tabs need them
  1465. # [21:27] <Steve^> sure, the browser can make them up, but a developer created one is always better
  1466. # [21:27] <Steve^> except maybe for gadgets
  1467. # [21:27] * Joins: annevk42 (n=annevk@535739CA.cable.casema.nl)
  1468. # [21:28] * Joins: jacobolus (n=jacobolu@dhcp-0059510974-71-a8.client.student.harvard.edu)
  1469. # [21:28] <AryehGregor> Steve^, what about iframes?
  1470. # [21:28] <hsivonen> :-( Shane thought my bug comment asking for an assertion to be substantiated was a troll
  1471. # [21:28] <AryehGregor> What about test cases where nobody cares about the title?
  1472. # [21:28] <annodomini> Existing thread on the issue: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020147.html
  1473. # [21:28] <Steve^> AryehGregor, accessibility?
  1474. # [21:28] <AryehGregor> Steve^, what about accessibility?
  1475. # [21:28] <annodomini> Right. The reason I thought of it is that everyone uses test cases that lack titles.
  1476. # [21:29] <Steve^> screen reader can use the title of the iframe content as a reference
  1477. # [21:29] <AryehGregor> annodomini, I don't, but it's silly.
  1478. # [21:29] <AryehGregor> hsivonen, you need to kill him for a failed assertion, obviously.
  1479. # [21:29] <AryehGregor> Steve^, do they actually do that?
  1480. # [21:29] <AryehGregor> This sounds like hidden metadata to me.
  1481. # [21:29] <annodomini> Wouldn't it be better to just read the content of the iframe, and thus get the same content as sighted users?
  1482. # [21:30] <Steve^> I don't know what they do, I just think about what they could do :)
  1483. # [21:30] <AryehGregor> Steve^, bad approach, generally.
  1484. # [21:30] <hsivonen> AryehGregor: I think failed assertions aren't even logged
  1485. # [21:30] <Steve^> umm
  1486. # [21:30] <Steve^> no?
  1487. # [21:30] <TabAtkins> Hrm, Leif's point about IE6/7's treatment of <dt>/<dd> outside of <dl> is valid. This seems like a big problem.
  1488. # [21:30] <AryehGregor> Because then you end up building your standard based on things that just don't happen.
  1489. # [21:30] <AryehGregor> A fantasy world, essentially. Rather than actually making it useful. That's what XHTML 2 did.
  1490. # [21:30] <TabAtkins> Though I can see how it was missed in testing - IE shows it with some properties, but not with background.
  1491. # [21:30] <AryehGregor> hsivonen, you need to turn on debug mode, then.
  1492. # [21:31] <Steve^> AryehGregor, I design for the future. I make sure that when screen readers and other user agents get better, my site has the information for it. What they do now is unimportant
  1493. # [21:31] <Steve^> That would lead to zero development
  1494. # [21:31] <AryehGregor> Steve^, great, so then they develop in a totally different direction and your effort is wasted.
  1495. # [21:32] <AryehGregor> If you design for tomorrow, then your site will work tomorrow.
  1496. # [21:32] <AryehGregor> It might not work ideally five years from now, but it probably wouldn't work ideally five years from now anyway, because who knows what five years from now will be like?
  1497. # [21:32] <Steve^> Do any screen readers understand HTML sectioning/heading content yet?
  1498. # [21:32] <AryehGregor> No idea, I know diddly-squat about screen readers.
  1499. # [21:33] <Steve^> if not, I might as well strip out those silly <section> and <article> that I wasted my time on
  1500. # [21:33] <AryehGregor> Those are specified in a current standard that multiple vendors have expressed interest in implementing. But if you aren't actually using them, sure, feel free to strip them out, probably won't change much.
  1501. # [21:33] <annodomini> The question is, would reading the <title> of a page in an iframe help accessibility?
  1502. # [21:34] <AryehGregor> Not the same as deciding on your own that screen readers might use <title> in <iframe> for something.
  1503. # [21:34] <Steve^> annodomini, its much faster to read a title than the entire iframe
  1504. # [21:34] <hsivonen> speaking of future proofing, Re: easlier discussion on vendor prefixes: vendor prefixes fail if one does -moz-border-radius: ...; -webkit-border-radius: ...; and then in anticipation boder-radius: ...;, too
  1505. # [21:34] <AryehGregor> HTML5 was developed very broadly over a period of a few years.
  1506. # [21:34] <hsivonen> *border-radius
  1507. # [21:34] <Steve^> I expect the screenreader reads the title of the main page first, too
  1508. # [21:34] <annodomini> If the author put the page into an iframe, they were intending people to see the content of the iframe, not the title.
  1509. # [21:34] <Steve^> and the user can abort viewing at any time
  1510. # [21:34] <AryehGregor> hsivonen, Mozilla apparently encourages that. At least there was one bug I read where they removed support for -moz-foo at the same time as adding support for foo.
  1511. # [21:34] <AryehGregor> Or at least someone said they would.
  1512. # [21:35] <Steve^> Can anyone give an example of a good iframe? I don't come across them much
  1513. # [21:35] <annodomini> iframes are different than main frames, though. They are frequently used to transparently include content, that shouldn't appear to be any different than content from the main frame.
  1514. # [21:35] <annodomini> They are frequently used for sandboxing untrusted code.
  1515. # [21:35] <Philip`> Steve^: Adverts?
  1516. # [21:36] <Steve^> perfect
  1517. # [21:36] <AryehGregor> AFAIK, most screen readers try to scrape content from the screen to reconstruct what it would look like for sighted users. They ignore things that are set to display: none, for instance, because they wouldn't display visually.
  1518. # [21:36] <annodomini> If you want to embed a random untrusted piece of flash or javascript in your blog, you can stick it in an iframe on a different domain, so it doesn't have access to your cookies.
  1519. # [21:36] <Steve^> A sighted user can choose what on the screen they look at, avoiding adverts
  1520. # [21:36] <AryehGregor> So I doubt they intentionally display content like an iframe's title that would be hidden in a normal browser.
  1521. # [21:36] <gsnedders> annodomini: An iframe doesn't work as a sandbox
  1522. # [21:37] <Steve^> titles would allow the user to see what the iframes hold and browse around, without parsing each document in its entirety
  1523. # [21:37] * Joins: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  1524. # [21:37] <gsnedders> annodomini: You can just do parent.document.body.style.display = "none";
  1525. # [21:37] <AryehGregor> Yes, but the fact is practically nobody actually tests in or cares about screen readers, so if they do provide things meant to help screen readers, they usually get them totally wrong.
  1526. # [21:37] <annodomini> If you stick it on a different domain?
  1527. # [21:37] <AryehGregor> So screen readers ignore most of that stuff anyway AFAIK.
  1528. # [21:37] <gsnedders> annodomini: Still works
  1529. # [21:39] <hsivonen> hmm. it seems that Shane also missed the part were Othar from Google stated their intent to deviate from the spec
  1530. # [21:40] <annevk42> he thinks it's just like HTML4 and therefore fine
  1531. # [21:40] <annevk42> guess he didn't get the memo that implementors perceive HTML4 as not that great -- if not disaster
  1532. # [21:43] * aroben|lunch is now known as aroben
  1533. # [21:43] <annevk42> it's funny how on the one hand the XHTML2/RDFa guys think everything should be pure and good but when it comes to the DOM it can all be a quick hack as long as it works
  1534. # [21:44] <annevk42> it makes no sense whatsoever to me
  1535. # [21:44] <Philip`> annevk42: Sounds like making the language nice and clean for users, even if implementers have to something a little hacky
  1536. # [21:44] <Philip`> which is just a sensible priority of constituencies
  1537. # [21:45] <AryehGregor> s/^.*(the XHTML2/RDFa guys).*$/$1/ and the next line still makes sense. :)
  1538. # [21:45] <erl[oberholz]> AryehGregor, interesting. I used display:none on my accessability hooks. does that mean i should use the move it 1000em to the left hack ?
  1539. # [21:45] <AryehGregor> erl[oberholz], that's what people usually do.
  1540. # [21:46] <TabAtkins> erl[oberholz]: Yeah, that's what you should do.
  1541. # [21:46] <AryehGregor> erl[oberholz], in general, I've found that trying to develop things for platform X without actually testing on platform X is a sure recipe for disaster.
  1542. # [21:46] <AryehGregor> If you want to make your site work in screen readers, then get a screen reader and test it.
  1543. # [21:46] <AryehGregor> Try to be clever and you'll probably make things worse.
  1544. # [21:46] <AryehGregor> Because the screen readers are designed to gracefully handle pages that ignore the existence of screen readers.
  1545. # [21:46] <TabAtkins> erl[oberholz]: I use that for my "Skip to content" link, for example.
  1546. # [21:46] <AryehGregor> (this doesn't necessarily apply to following well-established advice, though)
  1547. # [21:47] <erl[oberholz]> TabAtkins, i mean exactly that. (though HTML5 should make this non-necessary)
  1548. # [21:47] <TabAtkins> erl[oberholz]: Because I can't organize my page to have all content at the top, unfortunately. CSS isn't mature enough quite yet for me.
  1549. # [21:47] <AryehGregor> Personally, my vote is that we develop a general cure for blindness so we can forget about screen readers. All in favor, say aye.
  1550. # [21:47] <erl[oberholz]> arrrr
  1551. # [21:47] <Steve^> I'm busy, sorry AryehGregor good luck though
  1552. # [21:48] <TabAtkins> Well, crap, this whole <figure><dt/></figure> issue seems to be just as bad as <figure><legend/></figure.
  1553. # [21:48] <AryehGregor> TabAtkins, MediaWiki has all content at the top of the HTML source, but it doesn't help screen readers, since they execute the CSS. I once had a guy come in asking for help getting his site for blind people to work better, and he said "just tell me where all the CSS is so I can delete it".
  1554. # [21:48] <Steve^> I have a feeling that screenreaders do read display: none sections
  1555. # [21:48] <TabAtkins> I suppose the damage is somewhat less widespread, but it's still going to be useless for many years.
  1556. # [21:48] <annodomini> Steve^: no, they don't
  1557. # [21:49] <AryehGregor> Steve^, not what I've been told by blind people or multiple web design essays.
  1558. # [21:49] <annodomini> That's why if you want to hide text from sighted users but have it accessible to blind users, you generally give it something like a -9999px margin
  1559. # [21:49] <TabAtkins> Or abspos it and set left:-9000px
  1560. # [21:49] * Quits: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 60 (Operation timed out))
  1561. # [21:50] <AryehGregor> I wonder if screen readers will start figuring that out and not reading it at some point.
  1562. # [21:50] <annodomini> gsnedders: Firefox, Safari, and Opera all agree that an iframe doesn't get to mess with its parent: http://ephemera.continuation.org/cross-domain-iframe.html
  1563. # [21:50] <TabAtkins> God, I hope not, AryehGregor.
  1564. # [21:50] <Steve^> why would they not render it? It is information they want to show?
  1565. # [21:51] <gsnedders> annodomini: Oh, and the sandbox attribute only changed same-origin stuff
  1566. # [21:51] <Steve^> why is this not in the HTML5 spec?
  1567. # [21:51] <Steve^> display: non-visual;
  1568. # [21:51] <AryehGregor> Why is what not in the HTML5 spec?
  1569. # [21:51] <AryehGregor> . . .
  1570. # [21:51] <Steve^> or something clever
  1571. # [21:51] <AryehGregor> It's CSS, not HTML.
  1572. # [21:51] <annodomini> That would go into CSS, not HTML
  1573. # [21:52] <AryehGregor> And there are audio stylesheets for this.
  1574. # [21:52] <AryehGregor> Which screen readers ignore.
  1575. # [21:52] <AryehGregor> (most screen readers)
  1576. # [21:52] <AryehGregor> Because they know what they want to display a lot better than the average web author.
  1577. # [21:52] <annodomini> But yeah, I think that would be a good idea, to stop the -9000 px margin hacks.
  1578. # [21:53] <AryehGregor> annodomini, http://www.w3.org/TR/CSS2/aural.html
  1579. # [21:53] <AryehGregor> display: none; speak: normal;
  1580. # [21:53] <Steve^> Is there a reason everyone said -9000 and not -10000?
  1581. # [21:53] <TabAtkins> My hope is that since display:none is so easy, we devs will keep doing it for things we want hidden from everyone, and the margin-left:-9000px and position:absolute;left:-9000px hacks will always continue working.
  1582. # [21:54] <TabAtkins> Steve^, I dunno. I picked it up when I first learned the technique from whatever blog I read.
  1583. # [21:54] <annodomini> Steve^: No real good reason I know of.
  1584. # [21:54] <Steve^> How about the HTML5 outline algorithm. Does that care about display: hidden? Are screenreaders likely to when they implement it?
  1585. # [21:55] <AryehGregor> Steve^, HTML is not affected by CSS, ever.
  1586. # [21:55] <AryehGregor> I mean, the semantics of HTML.
  1587. # [21:55] <AryehGregor> Like section outline.
  1588. # [21:55] <Steve^> I use hidden headings on my navigation elements, so that the outline makes more sense, but the user shouldn't see them for style reasons
  1589. # [21:55] <AryehGregor> Do we have reason to believe that screen readers will actually implement the section outline algorithm?
  1590. # [21:56] <AryehGregor> Steve^, MediaWiki does that for some of the navigation stuff.
  1591. # [21:56] <TabAtkins> I'll be happy when CSS implements the section outline algorithm and gives us :heading() (and maybe ::section())
  1592. # [21:56] <annodomini> The outline algorithm picks out a set of nodes. Once you get those, you have to decide what to do with them. You might decide to present al of them, or you might decide not to present ones that have display: none
  1593. # [21:56] <Steve^> hmm true
  1594. # [21:57] <Steve^> screenreaders should implement it, its a handy way to navigate a document. But you don't want them navigating to areas that are hidden
  1595. # [21:57] <Steve^> so my hidden headings will need to be -10000px too
  1596. # [21:58] * drunknbass_wor is now known as drunknbass_work|
  1597. # [21:58] <annodomini> But because web app authors frequently use display: none to hide stuff that doesn't make sense to display, it usually doesn't make sense to read them either. So yeah, if you want things to be accessible to the screenreader, you need to use the negative margin hack.
  1598. # [21:58] <annevk42> Philip`, users deal with the DOM, surely
  1599. # [21:59] <Steve^> annodomini, why do they frequently do that?
  1600. # [21:59] <TabAtkins> display:none is the poor man's way to remove elements from the DOM, basically.
  1601. # [22:00] <Steve^> You could use javascript for a tabbed effect, that would toggle the display
  1602. # [22:00] * Joins: [1]mpilgrim (n=mark@nat/google/x-jqzmpqfaseloesir)
  1603. # [22:00] <TabAtkins> So. Yes. <dt> in <figure> is at the same level of brokenness as <legend> in <figure>. We didn't gain anything by switching.
  1604. # [22:00] <TabAtkins> Steve^: That is in fact the common way to do things.
  1605. # [22:01] <Steve^> if this is purely a CSS problem, then ok
  1606. # [22:01] <Steve^> but if HTML can help, then its worth considering now
  1607. # [22:02] <Steve^> just like alt is purely for accessibility
  1608. # [22:02] <annevk42> <dt> doesn't work?
  1609. # [22:02] <TabAtkins> annevk42: Not in ie6 or ie7, for a lot of CSS properties.
  1610. # [22:02] <TabAtkins> It forms a good DOM, but display is totally broken.
  1611. # [22:02] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 60 (Operation timed out))
  1612. # [22:02] * [1]mpilgrim is now known as mpilgrim
  1613. # [22:03] <annevk42> and a different element does work?
  1614. # [22:03] <TabAtkins> Yup.
  1615. # [22:03] <annevk42> why is that?
  1616. # [22:03] <TabAtkins> It's something special about encounting a <dt>/<dd> outside of a <dl>.
  1617. # [22:03] <annevk42> aah, wow
  1618. # [22:03] <TabAtkins> I just put a message on the html-wg list with a testcase.
  1619. # [22:03] * Joins: murr4y (n=murray@85.84-49-67.nextgentel.com)
  1620. # [22:04] * Quits: Kuruma (n=Kuruman@p4149-ipbf2803hodogaya.kanagawa.ocn.ne.jp) (Read error: 110 (Connection timed out))
  1621. # [22:04] <othermaciej> yikes
  1622. # [22:04] <othermaciej> I guess we should have tested <dt> / <dd>
  1623. # [22:04] <Steve^> lol
  1624. # [22:04] <TabAtkins> Really Leif's discovery, but I trimmed down his case to something minimal.
  1625. # [22:05] <Steve^> is the fieldset legend being changed?
  1626. # [22:05] * Joins: Kuruma (n=Kuruman@p3160-ipbf2309hodogaya.kanagawa.ocn.ne.jp)
  1627. # [22:05] <TabAtkins> Hm? We don't do anything new with <fieldset><legend> now.
  1628. # [22:05] * Quits: murr4y (n=murray@85.84-49-67.nextgentel.com) (Read error: 104 (Connection reset by peer))
  1629. # [22:07] <annevk42> but it works in ie8?
  1630. # [22:07] <TabAtkins> Yup.
  1631. # [22:07] <annevk42> might be good enough
  1632. # [22:08] <TabAtkins> It's forward compatible, it seems, but it's still broken enough in legacy stuff that it won't be usable for years yet.
  1633. # [22:08] <TabAtkins> Unless you decide that you just plain don't want to set borders or font properties on your captions / <details> togglers.
  1634. # [22:08] * Joins: murr4y (n=murray@85.84-49-67.nextgentel.com)
  1635. # [22:09] <AryehGregor> TabAtkins, I don't see your post . . .
  1636. # [22:09] * Quits: murr4y` (n=murray@84.49.67.85) (Read error: 145 (Connection timed out))
  1637. # [22:09] <AryehGregor> Oh, I muted that conversation.
  1638. # [22:09] <TabAtkins> AryehGregor: It threaded itself weirdly, it seems.
  1639. # [22:09] <TabAtkins> Heh, k.
  1640. # [22:09] <TabAtkins> Should I make it a top-level post?
  1641. # [22:10] * Joins: jwalden (n=waldo@nat/mozilla/x-avgyskwsrwzgiauj)
  1642. # [22:11] <TabAtkins> Steve^: (returning to the hiding/screenreaders thing) Ideally we'd be able to use nothing but @hidden to indicate content that we're leaving in the DOM, but that shouldn't be looked at by anyone, and return to display:none being read by screen-readers. of course that's never going to happen.
  1643. # [22:12] * Quits: jacobolus (n=jacobolu@dhcp-0059510974-71-a8.client.student.harvard.edu) (Remote closed the connection)
  1644. # [22:12] <othermaciej> TabAtkins: so you can't change the font of a <dt> outside a <dl>? But you can if it is inside a <dl>? that is way weird
  1645. # [22:12] <TabAtkins> othermaciej: Nah, you can change it, but those properties then apply *to the entire rest of the document*, as if everything was a child of the <dt>.
  1646. # [22:12] <TabAtkins> It's really obvious when you set a border, as well, as it wraps the rest of the document in the border.
  1647. # [22:13] <Steve^> a new element is way better than stuffing compatibility that much
  1648. # [22:13] <TabAtkins> I suspect IE's creating something that's not a tree for CSS purposes.
  1649. # [22:13] <othermaciej> TabAtkins: whoah.
  1650. # [22:15] <TabAtkins> So, yeah. I definitely expect to set font and borders on my <details> toggler, so this'll render it unusable for me for a long time. I'm not sure what the full list of crazy-inheritance properties are, too, so there may be more ridiculosity.
  1651. # [22:17] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  1652. # [22:18] <othermaciej> reading <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7670> is entertaining
  1653. # [22:18] <annevk42> is the hixie vs pro-prefix guys?
  1654. # [22:18] <annevk42> s/the/that/
  1655. # [22:18] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  1656. # [22:18] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  1657. # [22:20] <TabAtkins> annevk42: yeah
  1658. # [22:21] <hober> I really need to finish up my ranty blog post about prefix-indirection mechanisms
  1659. # [22:21] <Steve^> RDFa is too complicated from my brief view of it
  1660. # [22:21] * annevk42 was amused too
  1661. # [22:22] <annevk42> good start of the weekend
  1662. # [22:22] <Philip`> RDFa is too complicated from my relatively extensive view of it
  1663. # [22:22] <hober> it'll be the essay form of http://edward.oconnor.cx/2009/BarCamp-San-Diego-5/ (sorry, no 'previous slide' functionality in that deck)
  1664. # [22:22] * Quits: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote closed the connection)
  1665. # [22:27] <Steve^> microdata doesn't even have a wikipedia page
  1666. # [22:29] <Hixie> nor do most HTML5 features :-)
  1667. # [22:29] * Quits: pmuellr (n=pmuellr@nat/ibm/x-kiczutagyzqtbukp)
  1668. # [22:32] <TabAtkins> k, I've sent the <dt> issue as a top-level thread, so people who've already muted the bikeshed conversations will be able to see it. ^_^
  1669. # [22:33] <hsivonen> Hixie: Wikipedia interprets your mozilla.org involvement as employment by Mozilla Foundation. that's incorrect, right?
  1670. # [22:33] <Hixie> yeah i was employed by netscape for a year but other than that was just a mozilla contributor
  1671. # [22:33] <Hixie> still am, occasionally :-)
  1672. # [22:36] * gsnedders sighs, biting his lip, wondering what to do
  1673. # [22:36] <TabAtkins> gsnedders: Bite harder.
  1674. # [22:37] <gsnedders> TabAtkins: I don't like the taste of blood, so no.
  1675. # [22:37] <Hixie> hmm
  1676. # [22:37] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  1677. # [22:38] <hsivonen> Hixie: fixed
  1678. # [22:38] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  1679. # [22:38] * Hixie ponders how to make the relextensions, metaextensions, and so on work
  1680. # [22:38] <Hixie> hsivonen: thanks
  1681. # [22:39] <Hixie> not that i'm particularly worried about what it says :-)
  1682. # [22:40] * gsnedders wishes he didn't have to make any decisions that had consequences for a prolonged period, ever
  1683. # [22:41] <Hixie> you likely couldn't be especially useful to the human race or the universe as a whole if you didn't have to make decisions of consequence :-)
  1684. # [22:41] <TabAtkins> gsnedders: In all seriousness, just go with whichever feels the best. If you have the ability to research the decision, do so, but don't stress overly much about it. You'll miss opportunities whichever way you decide, so just pick whichever feels best and don't look back.
  1685. # [22:41] <othermaciej> gsnedders: what's your tough decision?
  1686. # [22:41] <gsnedders> TabAtkins: I don't think you realize what sort of decision this is :)
  1687. # [22:41] <Hixie> MetaExtensions, RelExtensions, and PragmaExtensions
  1688. # [22:41] <Hixie> how should they work?
  1689. # [22:42] <othermaciej> if I knew, I would have told you already
  1690. # [22:43] <and> In case anyone is interested, the reasoning behind EOF inside tags causing the tag to be dropped are in <http://lists.w3.org/Archives/Public/public-html/2009Mar/0260.html>.
  1691. # [22:43] <and> I forgot (at least) two issues yesterday:
  1692. # [22:43] <gsnedders> othermaciej: Whether to tell one of my friends some things about his gf or not, which will almost certainly end any relationship between them. I know if I don't and if he ends up hurt (which I expect will happen) I'll blame myself for not doing anything, and if I do anything I'll be construed purely as jealous, and be disliked by some of my friends for splitting them up.
  1693. # [22:44] <and> 5) Are the different tokens emitted by the tokeniser defined anywhere?
  1694. # [22:44] <and> 6) At which point do attributes in end tags cause a parse error?
  1695. # [22:44] <gsnedders> 6) Any
  1696. # [22:44] <gsnedders> Actually, I think when they are emitted.
  1697. # [22:45] <TabAtkins> gsnedders: imxp, telling is usually better if it's something that the other person would actually like to know, had they the ability to (like someone cheating). It can still cause a lot of hurt feelings, but shrug. Gotta choose one way or the other.
  1698. # [22:45] <othermaciej> gsnedders: sounds like something I shouldn't ask about further in a logged IRC channel
  1699. # [22:45] <hsivonen> gsnedders: when emitted
  1700. # [22:45] <gsnedders> othermaciej: Indeed :)
  1701. # [22:45] <gsnedders> othermaciej: I was wondering for a while how to phrase it vaguely enough :)
  1702. # [22:46] <gsnedders> TabAtkins: That'd be all right if it were as simple as what I made it seem, but I don't really want to be exact in a logged IRC channel.
  1703. # [22:46] <AryehGregor> gsnedders, you could tell him anonymously so you don't look jealous.
  1704. # [22:47] <TabAtkins> gsnedders: Wanna take it to private channel?
  1705. # [22:47] <gsnedders> Like #omggsnedders?
  1706. # [22:47] <AryehGregor> Obviously we need to start #gf-of-friend-of-gsnedders and reach consensus there before taking any action.
  1707. # [22:47] <AryehGregor> Votes may be involved.
  1708. # [22:47] <gsnedders> I was originally going to go for #omggsneddersisonaboutagirlagain
  1709. # [22:48] <gsnedders> But that's over the length limit
  1710. # [22:48] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn) ("Leaving...")
  1711. # [22:48] <and> Thanks.
  1712. # [22:48] <gsnedders> and: 5) AFAIK No
  1713. # [22:48] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Read error: 110 (Connection timed out))
  1714. # [22:51] * aroben is now known as aroben|phone
  1715. # [22:52] * gsnedders heads off to #omggsnedders
  1716. # [22:53] <and> They are defined, actually. (Wonder how I missed that.) End tag tokens even have attributes.
  1717. # [22:55] * and was surprised to find that &nbsb accounts for 88% of all unterminated character references in the dotnetdotcom dataset.
  1718. # [22:55] <and> *nbsp
  1719. # [22:57] * Quits: Steve^ (n=steve@94.197.232.136.threembb.co.uk) (Read error: 110 (Connection timed out))
  1720. # [22:58] <jcranmer> that low?
  1721. # [22:58] <Philip`> and: Presumably based on combined number of occurrences, not number of pages?
  1722. # [22:58] <and> Yes, but even so.
  1723. # [22:58] <Philip`> Actually, I suppose that's an unjustified presumption
  1724. # [22:58] <Philip`> because the most common error is <a href=foo?x=1&y=2> but that's going to be spread over a wide range of strings
  1725. # [23:00] <and> Only those that are interpreted as characters (according to HTML5 and IE) are counted.
  1726. # [23:00] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  1727. # [23:00] <Philip`> Ah
  1728. # [23:00] <and> Next step will be to look at the ones which could have been.
  1729. # [23:00] <Philip`> (Hmm, the only similar data I seem to have is http://philip.html5.org/data/entities-without-semicolon-followed-by-equals.txt which isn't very relevant)
  1730. # [23:01] * Joins: [1]mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  1731. # [23:06] * Quits: zdobersek (n=zan@cpe-92-37-78-54.dynamic.amis.net) ("Leaving.")
  1732. # [23:11] * Quits: karlushi (n=karlushi@fw.vdl2.ca) (Read error: 110 (Connection timed out))
  1733. # [23:12] * Quits: hobertoAtWork (n=hobertoa@gw1.mcgraw-hill.com) ("Nettalk6 - www.ntalk.de")
  1734. # [23:17] * Joins: dglazkov_ (n=dglazkov@nat/google/x-muqmigskabfkrjkg)
  1735. # [23:18] * Quits: mpilgrim (n=mark@nat/google/x-jqzmpqfaseloesir) (Read error: 110 (Connection timed out))
  1736. # [23:18] * [1]mpilgrim is now known as mpilgrim
  1737. # [23:20] * Joins: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  1738. # [23:25] <TabAtkins> Is there reason to believe that <a ping> won't work?
  1739. # [23:25] <TabAtkins> Is it fear that browser vendors won't implement it?
  1740. # [23:26] * Quits: dglazkov_ (n=dglazkov@nat/google/x-muqmigskabfkrjkg) (Read error: 104 (Connection reset by peer))
  1741. # [23:28] * Joins: dglazkov_ (n=dglazkov@nat/google/x-jffzeomhxaquzzxx)
  1742. # [23:29] <othermaciej> "won't work" in what sense?
  1743. # [23:30] <othermaciej> there are two ISSUEs outlining specific objections
  1744. # [23:30] * TabAtkins goes to look them up.
  1745. # [23:30] <othermaciej> http://www.w3.org/html/wg/tracker/issues/1
  1746. # [23:30] <othermaciej> http://www.w3.org/html/wg/tracker/issues/2
  1747. # [23:30] <TabAtkins> I'm just going on Julian's objection in the latest comment to that bug.
  1748. # [23:31] * Quits: miketaylr (n=mtaylor@38.117.156.163) ("adios.")
  1749. # [23:32] <TabAtkins> Ooh, didn't realize that FF had implemented ping.
  1750. # [23:33] * Quits: dglazkov (n=dglazkov@nat/google/x-zeutyehahaqauthr) (Read error: 110 (Connection timed out))
  1751. # [23:33] * dglazkov_ is now known as dglazkov
  1752. # [23:34] <othermaciej> they did, but their implementation is disabled currently
  1753. # [23:34] <othermaciej> it's also been proposed for WebKit (and thus for Chrome and Safari)
  1754. # [23:34] <othermaciej> so far we have no public expression of interest from content authors
  1755. # [23:34] <TabAtkins> You can have one now: I'd like it.
  1756. # [23:35] <othermaciej> which means browsers that implement it may be accused of privacy badness, but without delivering an actual user experience benefit
  1757. # [23:35] <othermaciej> you should post to that effect on public-html, though it would carry more weight if it was from a major web site...
  1758. # [23:35] <TabAtkins> Specifically for the purpose of tracking how often particular resources are requested, so we can tell which instructional PDFs are most popular and do more along that vein.
  1759. # [23:36] <TabAtkins> Well, I can say it as my company's webmaster. ^_^
  1760. # [23:37] * Quits: zalan (n=zalan@catv-89-135-144-193.catv.broadband.hu) (Read error: 110 (Connection timed out))
  1761. # [23:37] <Hixie> i just redefined how the registries work
  1762. # [23:38] <Hixie> if anyone wants to go ahead and act as gardener for the wiki pages, please go ahead
  1763. # [23:38] <Hixie> the new process is a lot simpler
  1764. # [23:38] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  1765. # [23:41] * Joins: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  1766. # [23:48] * Quits: erl[oberholz] (n=erlehman@p5DDBA72B.dip.t-dialin.net) ("Ex-Chat")
  1767. # [23:53] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  1768. # [23:55] * Quits: starjive (i=beos@213-66-216-93-no30.tbcn.telia.com)
  1769. # [23:58] * Quits: paul_irish (n=paul_iri@12.33.239.250)
  1770. # Session Close: Sat Sep 19 00:00:00 2009

The end :)