/irc-logs / freenode / #whatwg / 2009-07-15 / end

Options:

  1. # Session Start: Wed Jul 15 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:00] <sicking> Hixie, i'm talking with Arun fairly often about the draft, i think a new one is on the way
  4. # [00:00] * Joins: weinig (n=weinig@nat/apple/x-73b9cf982e984a93)
  5. # [00:00] <sicking> Hixie, i don't think it'll change substantially though from previous one. Possibly introducing the local-uri thing
  6. # [00:01] <sicking> Hixie, though the lifetime still seems like a big problem to me
  7. # [00:01] * Quits: mat_t (n=mattomas@62-64-155-40.dynamic.dial.as9105.com) ("This computer has gone to sleep")
  8. # [00:02] <sicking> Hixie, and I think we might drop the FileDialog for now. Because ya'll are wossies ;)
  9. # [00:02] * aroben is now known as aroben|meeting
  10. # [00:04] <sicking> Hixie, so in general for drag-n-drop, pages won't know at all even what type of data is in the datatransfer until the drop event?
  11. # [00:05] <sicking> Hixie, seems useful for the page to know if it will be able to handle the datatype before accepting the drop
  12. # [00:05] <sicking> Hixie, this would be orthogonal to the .files issue
  13. # [00:07] * Joins: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
  14. # [00:10] * Joins: gsnedders (n=gsnedder@c83-252-195-113.bredband.comhem.se)
  15. # [00:10] * Joins: jorlow (n=jorlow@nat/google/x-c9682c2f12f03fb9)
  16. # [00:11] * Quits: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com) (Read error: 104 (Connection reset by peer))
  17. # [00:11] * Joins: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
  18. # [00:21] * Quits: cying (n=cying@70.90.171.153) (Success)
  19. # [00:32] <Hixie> sicking: what's the problem with the lifetime? and i hope he'll split File into File and some base interface, too
  20. # [00:32] <Hixie> sicking: the problem with not knowing the types is an open issue with the dnd model iirc
  21. # [00:33] <Dashiva> The @parsing thing doesn't seem like a good fit for markup
  22. # [00:33] <sicking> Hixie, the problem with the life time is that I suspect Document lifetime is slightly too short
  23. # [00:33] <Dashiva> Browser error reporting, symlinks, mod_rewrite with type override...
  24. # [00:33] <Hixie> sicking: for the types, i expect we'll expose .types in all events in the future
  25. # [00:33] <sicking> Hixie, for example sticking the uri into a sessionStorage in a wizard-type page
  26. # [00:33] <sicking> Hixie, sounds good re .types
  27. # [00:33] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
  28. # [00:34] <sicking> Hixie, we'd just need to define a type for files
  29. # [00:34] <Hixie> sicking: well we can always increase the lifetime later if we think we need to... but i think it'd be better to define a way to track the actual File or FileData objects rather than passing the URI around
  30. # [00:35] <sicking> Hixie, yeah, that's an alternative
  31. # [00:35] <sicking> Hixie, i'd still like for Storage to be able to hold File/FileData objects
  32. # [00:36] <othermaciej> I think the temporary URI design is probably not workable
  33. # [00:36] <othermaciej> I need to catch up on the discussion though
  34. # [00:36] <Hixie> othermaciej: i don't see another solution for reusing file data unless we basically add a parallel set of features across the entire platform to support File objects everywhere, and that seems painful
  35. # [00:36] <othermaciej> the problem is, you have to make sure that temporary URIs for files are unguessable, and also that they are never reused
  36. # [00:37] <Hixie> why and why?
  37. # [00:37] <othermaciej> they have to be unguessable or you have a security hole
  38. # [00:37] <othermaciej> an attacker in a different window could read the URI
  39. # [00:37] <Hixie> no, they are origin-blocked
  40. # [00:37] <othermaciej> assuming you want the URIs to be passable via postMessage for instance
  41. # [00:38] <Hixie> you'd pass the File object
  42. # [00:38] <Hixie> not the URI
  43. # [00:38] <othermaciej> in that case, they are inferior to the ability to pass a File since you can't transfer the capability
  44. # [00:38] <Hixie> correct
  45. # [00:38] <Hixie> they're not meant for passing around
  46. # [00:38] <Hixie> they're meant for plugging a File object into an <img> or <video> or some such
  47. # [00:38] <othermaciej> so it seems like adding srcFile attributes to the few HTML element interfaces that need them would be simpler
  48. # [00:38] <Hixie> or <iframe>, or CSS, or any number of things
  49. # [00:38] <Hixie> that seems unworkable to me
  50. # [00:39] <Hixie> we'd have to go through the entire platform duplicating everything, defining how one overrides the other, etc
  51. # [00:39] <Hixie> it'd be an epic disaster in terms of getting interop
  52. # [00:39] <othermaciej> (I don't think <iframe> or CSS really need them, but maybe I'm wrong)
  53. # [00:39] <sicking> Hixie, why make them origin blocked rather than unguessable?
  54. # [00:39] <othermaciej> the use case is for a preview
  55. # [00:39] * Joins: arun__ (n=arun@nat/mozilla/x-7165bef6f0b00147)
  56. # [00:40] * arun__ is now known as otherarun
  57. # [00:40] <sicking> I think CSS and <iframe> is useful for things like building a HTML editor
  58. # [00:40] <othermaciej> I think giving <img>, <audio> and <video> a way to take their source from a file instead of a URI would mostly satisfy the use case
  59. # [00:41] <othermaciej> building an HTML editor would admittedly need support everywhere you can embed something
  60. # [00:41] <othermaciej> if you wanted your HTML editor to work without having to upload the resources first
  61. # [00:41] <othermaciej> but I thought the main stated use case was for previews before uploading
  62. # [00:42] <othermaciej> (any text resource you can already preview by reading the file yourself)
  63. # [00:42] <othermaciej> temporary URIs are certainly more general, but more complicated both to use and to implement for the simple preview use case
  64. # [00:42] <Hixie> sicking: because they can leak easily (e.g. referer headers)
  65. # [00:43] <sicking> Hixie, hmm... good point
  66. # [00:43] <Hixie> i don't think that temporary URIs are actually any more complicated on the long term
  67. # [00:43] <Hixie> they would be a much more localised implementation
  68. # [00:43] <Hixie> rather than spreading support all over the place, redefining processing models, etc
  69. # [00:44] <othermaciej> a more localized implementation of something way more complicated, and with tricky security implications
  70. # [00:44] <sicking> if we make the uri origin blocked then I'm not sure there are any security issues I can think of off the top of my head
  71. # [00:45] <Hixie> othermaciej: i'm not convinced it's that complicated. Why would it be that complicated?
  72. # [00:45] <othermaciej> tracking the temp URIs and implementing lifetime and origin blocking is the piece of code that would be both complicated and security-sensitive
  73. # [00:45] <sicking> Hixie, btw, doesn't data: uri suffer the same problem of leaking through referrer then?
  74. # [00:45] <Hixie> sicking: data: URIs aren't particularly secure
  75. # [00:46] * aroben|meeting is now known as aroben
  76. # [00:46] <sicking> origin blocking doesn't seem that hard to implement security, granted it might be different in non-gecko browsers
  77. # [00:46] <sicking> securely
  78. # [00:47] <Hixie> othermaciej: it's just a table of ID,origin,file,document; when a document closes, you remove all the corresponding rows; whena url is dereferenced, it returns its origin and data
  79. # [00:47] <Hixie> othermaciej: unless your URI handling is especially weird, this seems relatively straightforward
  80. # [00:47] <othermaciej> Hixie: if lifetime is document but scope is origin, you have to be careful never to reuse an ID
  81. # [00:48] <othermaciej> that's one example of a potential subtle bug
  82. # [00:48] <otherarun> So the requirement is for both unguessability and origin-restriction.
  83. # [00:48] <otherarun> (the first, unguessability, may be easy -- UUID or something)
  84. # [00:48] <Hixie> othermaciej: not reusing an ID is trivial, just increase a number.
  85. # [00:48] <othermaciej> unguessability doesn't matter if they are origin restricted
  86. # [00:48] <sicking> at least not as important
  87. # [00:49] <sicking> though <img> is cross origin
  88. # [00:49] <Hixie> othermaciej: i don't really understand the not reusing an ID thing, though
  89. # [00:49] <othermaciej> Hixie: it's easier to avoid repeating if the URI doesn't have to be unguessable
  90. # [00:49] * sicking didn't follow the reuse ID thing either
  91. # [00:49] <Hixie> so long as you don't create a new URI that's equal to a still-active URI, why does it matter if the ID is reused?
  92. # [00:49] <othermaciej> if you reuse an ID then it could lead to another page from the same origin that has the wrong URI reference to load the wrong file, instead of getting an error
  93. # [00:50] <Hixie> that seems like a not especially worrisome case
  94. # [00:50] <Hixie> i mean, that page could just randomly come up with a string that happens to be one that happens to be registered to its own origin too
  95. # [00:50] <Hixie> even if the ID wasn't reused
  96. # [00:50] <othermaciej> note that File references wouldn't have this problem at all, since the engine can know the lifetime of a File object but it can't know the object of a URI string
  97. # [00:51] <othermaciej> Hixie: yes, that's another flaw with the magical URI scheme
  98. # [00:51] <othermaciej> it just has much more potential for bugginess to use a magic string instead of a capability-carrying object reference
  99. # [00:51] <Hixie> i think that considering this a flaw is like considering pointers to be flawed because if you come up with a random number that happens to point into your address space, you'll dereference something instead of getting an access violation
  100. # [00:51] <othermaciej> to identify a temporary and origin-restricted resource
  101. # [00:52] <othermaciej> pointers are flawed! that's why we don't have them in ECMAScript
  102. # [00:52] <Hixie> *shrug* i'm not convinced this is a problem
  103. # [00:52] <Hixie> i mean i'm happy to make the URIs be unlikely to be reused and unlikely to clash
  104. # [00:52] <Hixie> e.g. by using UUIDs
  105. # [00:53] <Hixie> (clash with random values, i mean)
  106. # [00:53] <Hixie> but i don't think it's a problem
  107. # [00:53] * Joins: weinig_ (n=weinig@17.244.1.204)
  108. # [00:54] <othermaciej> it's just a sloppy design, in my opinion
  109. # [00:54] <Hixie> but in any case, it's trivial to create a sequence of non-duplicate IDs that are statistically not going to clash with random numbers
  110. # [00:54] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  111. # [00:54] <othermaciej> not saying we can't make it work, but it will be much more bug-prone than the alternative
  112. # [00:54] <Hixie> it's far less sloppy than adding a parallel set of APIs everywhere :-)
  113. # [00:54] <Hixie> i strongly disagree with that
  114. # [00:54] <Hixie> having to add two entry points to every processing model is orders of magnitude more likely to be buggy
  115. # [00:54] <Hixie> and in weird ways that are hard to work aorund
  116. # [00:55] <sebmarkbage> Speaking of dnd... The current draft doesn't specify when pageX, clientX, screenX positions are available on the DragEvent. Gecko currently sets these to zero on the source node. It should be available on all IMHO. Is there any known security issues to this?
  117. # [00:55] <othermaciej> I doubt it. Just say srcFile always takes precedence over src, or the most recently set takes precedence, or whatever. Done.
  118. # [00:56] * Joins: tantek (n=tantek@208.80.69.102)
  119. # [00:56] <Hixie> othermaciej: hah
  120. # [00:56] <Hixie> othermaciej: if only it were that easy
  121. # [00:56] <othermaciej> It would be like an hour or two of implementation work to do HTMLImageElement.srcFile and I would be confident it is right
  122. # [00:56] <othermaciej> a temporary URI vending scheme, I would expect to be finding bugs months later
  123. # [00:56] <Hixie> othermaciej: and you'd get the origin checking right for when that <img> is used with createPattern() ?
  124. # [00:57] <sicking> the downside is that we can't make it work as widely as URIs work. For example for CSS backgrounds. But i'm not sure that that is that important
  125. # [00:57] <othermaciej> sicking: yeah, that's really the main downside
  126. # [00:58] <othermaciej> Hixie: an <img> loaded from a File shouldn't have cross-origin taint, since if you have the file reference you can get the bits of the image
  127. # [00:58] <othermaciej> or at least, cross-origin taint for createPattern() would serve no useful purpose
  128. # [00:58] <Hixie> othermaciej: i'm just saying that there are FAR more complications here than first meets the eye
  129. # [00:58] * Joins: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au)
  130. # [00:58] <Hixie> e.g. we'd have to change the conformance rules to make sure <img> without src="" would be valid
  131. # [00:59] <Hixie> the <video> resource selection algorithm would become even more complex
  132. # [00:59] <roc> I'd prefer the URI approach from an implementation point of view. If we do the .file approach we'll have to wrap the file in a URI-like-stream internally anyway
  133. # [00:59] <Hixie> anyone relying on selectors like img[src] would have to now know they couldn't always rely on it
  134. # [01:00] <othermaciej> I'm willing to believe there may be complications, I just can't think of any (at least, none that would make it tricky for implementations)
  135. # [01:00] <Hixie> there are so many small things that would have to be defined if we added a parallel API everywhere
  136. # [01:00] <othermaciej> roc: I think the challenges with the URI approach are not so much about using it internally, but in using that URI string as a handle to the resource
  137. # [01:00] <Hixie> you also couldn't use .innerHTML suddenly, you'd have to create the markup and then poke the file in afterwards
  138. # [01:01] <othermaciej> I guess I'm not really sure it's needed everywhere
  139. # [01:02] <Hixie> i don't think it's needed everywhere, e.g. i can't think of any time i'd want to put it in <blockquote cite="">
  140. # [01:02] <roc> Maintaining a file dictionary doesn't seem that hard, except for lifetime management. How does that work?
  141. # [01:02] <othermaciej> the only use case I've heard mentioned for that is a full-featured HTML editor that either works offline or is unwilling to upload resources before using them in editing
  142. # [01:02] <roc> Hixie: I can!
  143. # [01:02] <Hixie> roc: my proposal is to make the URIs stop resolving once their Document has been closed
  144. # [01:03] * sicking has to take off
  145. # [01:03] <roc> ok
  146. # [01:03] <sicking> so far I don't feel strongly either way
  147. # [01:03] <roc> sounds good to me
  148. # [01:04] * Quits: weinig (n=weinig@nat/apple/x-73b9cf982e984a93) (Read error: 110 (Connection timed out))
  149. # [01:06] <sebmarkbage> othermaciej: It could really be all kinds of offline app scenarios such as spreadsheets or whatever.
  150. # [01:07] <othermaciej> sebmarkbage: I don't think spreadsheets need the ability to reference a temporary file from CSS to work offline
  151. # [01:07] <othermaciej> being able to read the file text, plus maybe ability to display loaded images, should be enough
  152. # [01:08] * jmb^ is now known as jmb
  153. # [01:08] * Quits: gsnedders (n=gsnedder@c83-252-195-113.bredband.comhem.se)
  154. # [01:09] * aroben is now known as aroben|meeting
  155. # [01:11] * Quits: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au) ("This computer has gone to sleep")
  156. # [01:12] * Quits: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
  157. # [01:14] * Joins: olliej (n=oliver@17.203.15.241)
  158. # [01:14] * Quits: starjive (i=beos@213-66-216-93-no30.tbcn.telia.com)
  159. # [01:15] <sebmarkbage> Anything needing to embed image or video. I should be able to use them in img, video, css or canvas. I like the URI approach since it's ubiquitous.
  160. # [01:16] * Quits: Spark^ (n=x@94-194-199-197.zone8.bethere.co.uk) (Read error: 110 (Connection timed out))
  161. # [01:16] * Quits: olliej (n=oliver@17.203.15.241) (Client Quit)
  162. # [01:18] * Joins: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
  163. # [01:19] * Joins: olliej (n=oliver@17.203.15.241)
  164. # [01:24] * Quits: heycam (n=cam@124-168-9-27.dyn.iinet.net.au) ("bye")
  165. # [01:31] * Quits: weinig_ (n=weinig@17.244.1.204)
  166. # [01:35] * Joins: weinig (n=weinig@17.244.1.204)
  167. # [01:38] * aroben|meeting is now known as aroben
  168. # [01:39] <Hixie> good lord
  169. # [01:39] <Hixie> what a lot of new feedback
  170. # [01:43] <hober> yeah, that teal line has been trending upward for quite a bit there
  171. # [01:43] * Quits: dglazkov (n=dglazkov@nat/google/x-47ba9a7b611cdc4f)
  172. # [01:47] <sebmarkbage> Hixie: Where is the most appropriate place to leave new feedback? Forums? Mailing list?
  173. # [01:51] <Hixie> mailing list is most ideal
  174. # [01:51] <Hixie> see the top of the spec for details
  175. # [01:52] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  176. # [01:52] * Joins: cying (n=cying@70.90.171.153)
  177. # [02:01] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  178. # [02:02] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  179. # [02:03] * Quits: poe (n=poe@unaffiliated/xerox)
  180. # [02:07] * Joins: archtech (n=stanv@83.228.56.37)
  181. # [02:07] * Quits: archtech (n=stanv@83.228.56.37) (Remote closed the connection)
  182. # [02:07] * Joins: archtech (n=stanv@83.228.56.37)
  183. # [02:08] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  184. # [02:15] * Joins: nessy (n=nessy@203.110.150.154)
  185. # [02:15] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
  186. # [02:18] * Joins: slightlyoff (n=slightly@72.14.229.81)
  187. # [02:18] * Quits: slightlyoff (n=slightly@72.14.229.81) (Remote closed the connection)
  188. # [02:19] * Quits: dbaron_ (n=dbaron@nat/mozilla/x-1b695fbdbd24da88) ("8403864 bytes have been tenured, next gc will be global.")
  189. # [02:21] * Quits: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com) ("Leaving.")
  190. # [02:23] <sebmarkbage> Has there been any talk about explicitly specifying various mouse gestures? Like iPhone pinch could trigger onzoomin/onzoomout. I also think it'd be good to have something like draggable="gesture" that'd only trigger events on the source node.
  191. # [02:23] * Joins: slightlyoff (n=slightly@72.14.229.81)
  192. # [02:29] * Quits: tantek (n=tantek@208.80.69.102)
  193. # [02:46] <Hixie> sebmarkbage: that's more of a suggestion for the events work -- www-dom@w3.org
  194. # [02:48] <heycam> sebmarkbage, and i think olli pettay sent a mail to public-webapps or www-dom recently asking if there was any interest in speccing gesture/touch events
  195. # [02:50] <sebmarkbage> thx. I will look through the archives.
  196. # [02:50] * Joins: webben (n=benh@82.152.35.195)
  197. # [02:54] * Quits: bzed (n=bzed@devel.recluse.de) (Remote closed the connection)
  198. # [02:54] * Joins: bzed (n=bzed@devel.recluse.de)
  199. # [02:55] * Quits: otherarun (n=arun@nat/mozilla/x-7165bef6f0b00147)
  200. # [03:01] * Joins: hdh (n=hdh@2001:470:18:88:0:0:0:2)
  201. # [03:02] * Quits: weinig (n=weinig@17.244.1.204) (Remote closed the connection)
  202. # [03:02] * Joins: weinig (n=weinig@nat/apple/x-6f3610f0a3d678da)
  203. # [03:11] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) (Read error: 104 (Connection reset by peer))
  204. # [03:12] * Quits: ap (n=ap@nat/apple/x-3dd7abbeec533813)
  205. # [03:16] * Quits: MikeSmith (n=MikeSmit@EM114-48-27-177.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  206. # [03:19] * Joins: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
  207. # [03:38] * Quits: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
  208. # [03:39] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  209. # [03:39] * Joins: billyjackass (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  210. # [03:40] * Quits: billyjackass (n=MikeSmit@tea12.w3.mag.keio.ac.jp) (Client Quit)
  211. # [03:40] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) (Client Quit)
  212. # [03:41] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  213. # [03:41] * Quits: webben (n=benh@82.152.35.195) (Read error: 110 (Connection timed out))
  214. # [03:48] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  215. # [03:49] * Quits: hdh (n=hdh@2001:470:18:88:0:0:0:2) (Remote closed the connection)
  216. # [03:52] * Quits: cying (n=cying@70.90.171.153)
  217. # [03:57] * Quits: ttepasse (n=ttepas--@p5B0136D0.dip.t-dialin.net) ("?Q")
  218. # [04:04] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  219. # [04:08] * Quits: archtech (n=stanv@83.228.56.37) (Read error: 60 (Operation timed out))
  220. # [04:11] * Joins: weinig_ (n=weinig@17.244.1.204)
  221. # [04:11] * Quits: weinig_ (n=weinig@17.244.1.204) (Client Quit)
  222. # [04:11] * Quits: karlcow (n=karl@nerval.la-grange.net) (Remote closed the connection)
  223. # [04:14] * Quits: slightlyoff (n=slightly@72.14.229.81) (Read error: 110 (Connection timed out))
  224. # [04:20] * Joins: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net)
  225. # [04:22] * Joins: karlcow (n=karl@nerval.la-grange.net)
  226. # [04:26] * Quits: weinig (n=weinig@nat/apple/x-6f3610f0a3d678da) (Read error: 110 (Connection timed out))
  227. # [04:30] * Quits: nessy (n=nessy@203.110.150.154) (Read error: 110 (Connection timed out))
  228. # [04:32] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  229. # [04:33] * Joins: archtech (n=stanv@83.228.56.37)
  230. # [04:38] * Joins: ap (n=ap@174-145-229-78.pools.spcsdns.net)
  231. # [04:41] * Quits: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net) (Remote closed the connection)
  232. # [04:43] * Quits: jwalden (n=waldo@nat/mozilla/x-e33cc56ff5fa732b) ("din-din")
  233. # [04:46] * Quits: jorlow (n=jorlow@nat/google/x-c9682c2f12f03fb9)
  234. # [04:51] * Joins: olliej_ (n=oliver@17.246.18.222)
  235. # [05:00] * Joins: jorlow (n=jorlow@67.218.104.133)
  236. # [05:01] * Joins: jorlow_ (n=jorlow@72.14.224.1)
  237. # [05:03] * Quits: jorlow (n=jorlow@67.218.104.133) (Read error: 104 (Connection reset by peer))
  238. # [05:04] * Joins: olliej__ (n=oliver@17.246.18.222)
  239. # [05:04] * Quits: olliej_ (n=oliver@17.246.18.222) (Read error: 54 (Connection reset by peer))
  240. # [05:06] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  241. # [05:07] * Quits: olliej (n=oliver@17.203.15.241) (Read error: 110 (Connection timed out))
  242. # [05:09] * Joins: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au)
  243. # [05:11] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  244. # [05:23] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  245. # [05:26] * Quits: jorlow_ (n=jorlow@72.14.224.1) (Read error: 110 (Connection timed out))
  246. # [05:52] * Quits: olliej__ (n=oliver@17.246.18.222) (Read error: 104 (Connection reset by peer))
  247. # [05:54] * Joins: olliej (n=oliver@17.246.18.222)
  248. # [05:59] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
  249. # [06:02] * Joins: MikeSmith (n=MikeSmit@dhcp-246-160.mag.keio.ac.jp)
  250. # [06:21] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  251. # [06:30] * Joins: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  252. # [06:32] * Joins: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  253. # [06:46] * Quits: ap (n=ap@174-145-229-78.pools.spcsdns.net)
  254. # [06:46] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) (Read error: 110 (Connection timed out))
  255. # [06:54] * Joins: tantekc (n=tantek@70.36.139.128)
  256. # [07:13] * Quits: dolske (n=dolske@nat/mozilla/x-89c0308f172339be)
  257. # [07:33] * Quits: olliej (n=oliver@17.246.18.222)
  258. # [07:37] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  259. # [07:42] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  260. # [07:50] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  261. # [07:51] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  262. # [08:04] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  263. # [08:24] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  264. # [08:27] * Joins: heycam (n=cam@dyn-130-194-69-200.infotech.monash.edu.au)
  265. # [08:28] * Quits: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  266. # [08:28] <MikeSmith> hsivonen: I'm getting build errors after syncing up to latest v.nu sources
  267. # [08:28] <MikeSmith> ./syntax/relaxng/datatype/java/src/org/whattf/datatype/MicrodataIdentifier.java:32: package com.sun.org.apache.xerces.internal.dom3.as does not exist
  268. # [08:29] <hsivonen> MikeSmith: sorry. Eclipse has beeing doing random autocomplete again
  269. # [08:29] <hsivonen> MikeSmith: fixing
  270. # [08:30] <MikeSmith> thanks
  271. # [08:30] <MikeSmith> dispense with the IDE, man. that's stuff for sissies :)
  272. # [08:31] <hsivonen> MikeSmith: does it work now?
  273. # [08:32] <hsivonen> I read comments on Zeldman's blog and now I'm having a "someone's wrong on the Internet" moment again
  274. # [08:33] <hsivonen> appeals to the TAG even: http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44699
  275. # [08:36] * Quits: Sirisian (n=Sirisian@ppp-69-221-227-63.dsl.klmzmi.ameritech.net) (Read error: 110 (Connection timed out))
  276. # [08:38] <MikeSmith> hsivonen: works now -- thanks
  277. # [08:40] * Quits: tantekc (n=tantek@70.36.139.128)
  278. # [08:41] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  279. # [08:43] <MikeSmith> hsivonen: which part of the v.nu is emitting the new warnings?
  280. # [08:43] <MikeSmith> nm
  281. # [08:43] * MikeSmith finds syntax/non-schema/java/src/org/whattf/checker/ConformingButObsoleteWarner.java
  282. # [08:46] * Joins: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  283. # [08:48] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  284. # [09:07] * Joins: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  285. # [09:07] * Joins: tantek (n=tantek@70.36.139.128)
  286. # [09:15] * Joins: Khazou (n=Khazou@AReims-152-1-133-45.w86-215.abo.wanadoo.fr)
  287. # [09:15] * Quits: darbour (n=Rachel@c-98-216-48-49.hsd1.ma.comcast.net) (Read error: 104 (Connection reset by peer))
  288. # [09:27] * Joins: harig (n=harig@59.90.71.35)
  289. # [09:27] * Quits: shikiesos (n=shiki@220.109.219.244) ("Leaving.")
  290. # [09:31] * Quits: harig (n=harig@59.90.71.35) (Client Quit)
  291. # [09:31] * Joins: harig (n=harig@59.90.71.35)
  292. # [09:40] * Joins: shikiesos (n=shiki@220.109.219.244)
  293. # [09:44] * Quits: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  294. # [10:13] * Joins: roc (n=roc@121.74.180.224)
  295. # [10:15] * Quits: heycam (n=cam@dyn-130-194-69-200.infotech.monash.edu.au) ("bye")
  296. # [10:17] * Quits: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  297. # [10:17] * Joins: gunderwonder (n=gunderwo@garage.upstruct.com)
  298. # [10:21] * Quits: MikeSmith (n=MikeSmit@dhcp-246-160.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
  299. # [10:23] * nessy giggles at the whattf directory :)
  300. # [10:24] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
  301. # [10:25] <takkaria> the zeldman comments are pretty amazing
  302. # [10:26] <MikeSmith> takkaria: in what way?
  303. # [10:26] * Joins: abii (n=macbook@cm27.delta30.maxonline.com.sg)
  304. # [10:26] <takkaria> there's somsone there claiming they're going to have to relearn most of the stuff they know to the code a website with the advent of HTML5
  305. # [10:27] <MikeSmith> ah
  306. # [10:27] <hsivonen> I guess my comment is still in a moderation queue.
  307. # [10:28] * hsivonen wishes blog comment systems said "Your comment is awaiting moderation" when it is
  308. # [10:28] <hsivonen> the commenter using the handle "Luke" is onto something
  309. # [10:29] <hsivonen> too bad (s)he feels the need to post anonymously
  310. # [10:30] <hsivonen> http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44679
  311. # [10:31] * Quits: roc (n=roc@121.74.180.224)
  312. # [10:31] <Hixie> who used the "it will help screen readers" line?
  313. # [10:32] <Hixie> of the new sectioning elements, only <nav> has been put forward as being able to help screen reader users, as far as i'm aware
  314. # [10:32] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  315. # [10:33] <hsivonen> Hixie: hasn't footer been, too? and every one of them by the logic that if ARIA landmarks help, the HTML5 structural elements should, too
  316. # [10:33] <takkaria> apparently adding role="" is a much more incremental step than <header>/<nav>/ et all
  317. # [10:33] <Philip`> People have talked about using the sectioning elements to do an automatic "skip to content", which mainly helps screen reader users
  318. # [10:34] <jgraham> Better outlining seems like it wwould help screenreader users, as does "skip to next article" even without good use of headings
  319. # [10:34] <hsivonen> Philip`: Opera Mobile has a heuristic "skip to content" feature
  320. # [10:34] <Philip`> hsivonen: Does it work better than e.g. Opera's "next page" heuristic?
  321. # [10:34] <hsivonen> Philip`: presumably this stuff could tie into that feature, too
  322. # [10:35] <hsivonen> Philip`: it works amazingly well. I wish Mini had it, too.
  323. # [10:36] <Hixie> man i can't wait til blogs are all federated across wave
  324. # [10:36] <Hixie> it would make tracking these comments and responding properly so much easier
  325. # [10:36] <hsivonen> maybe that happens when all Java jar dependencies are federated over Maven
  326. # [10:37] * jgraham onders if wave uses the term "federated" because it sounds vaugely like something from Star Trek so subconciously suggesting 23rd Century technology
  327. # [10:37] <Philip`> Hixie: Can't you just follow the RSS comment feeds?
  328. # [10:37] <Hixie> i can't respond to RSS comment feeds and have them appear in the other person's RSS feed
  329. # [10:38] <hober> jgraham: we just need a wave app on our communicators, err, iphones.
  330. # [10:38] <Hixie> jgraham: it uses it because that's what jabber uses, iirc
  331. # [10:38] <jgraham> OK, well s/wave/jabber/ in the above then :)
  332. # [10:38] <Hixie> no idea
  333. # [10:39] <hsivonen> I tend to get an enterprisey vibe from "federated"
  334. # [10:39] <hsivonen> probably from associations with WS-* stuff
  335. # [10:40] <hsivonen> I do think that federated SSO, chat, etc. are good
  336. # [10:40] <Hixie> "enterprise" also has the startrek feel :-P
  337. # [10:40] <hsivonen> heh
  338. # [10:40] <hsivonen> WS-* has a StarWars feel, though :-)
  339. # [10:41] <jgraham> Yeah. Talking about things being "federated to your enterprise" seems like a winning strategy because it allows CEOs to like out their Picard fantasy
  340. # [10:41] <jgraham> s/like/live/
  341. # [10:45] * Joins: webben (n=benh@nat/yahoo/x-a1d5bf4bd71165da)
  342. # [10:47] * hsivonen gestures angrily in the general direction of whoever invented the syntactic sugar for declaring multiple variables in one declarator
  343. # [10:51] * Joins: heycam (n=cam@124-168-9-27.dyn.iinet.net.au)
  344. # [11:07] * Joins: mat_t (n=mattomas@nat/canonical/x-eb63950733a08e81)
  345. # [11:10] * Joins: ROBOd (n=robod@89.122.216.38)
  346. # [11:11] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  347. # [11:12] * Joins: Phae (n=phaeness@gatea.mh.bbc.co.uk)
  348. # [11:13] <zcorpan> Hixie: Scripts that modify the page as it is being parsed - is not error handling
  349. # [11:13] <Hixie> yeah but there's no doctype!
  350. # [11:14] <zcorpan> the section doesn't discuss the doctype :)
  351. # [11:18] <Lachy> Hixie, John Allsop may have a valid point about the <footer> content model that he mentioned here http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44699 - Sites like YouTube and Flickr group the links in their footers by category. Although they currently use table layouts to achieve it, it seems reasonable to do that with sections
  352. # [11:18] <Hixie> zcorpan: details! :-P
  353. # [11:18] <Hixie> zcorpan: (i'm happy to change that section title if you can find a better one -- drop me a mail)
  354. # [11:19] <Hixie> Lachy: those are <section>s. They're at best paragraphs.
  355. # [11:19] <Hixie> maybe <dl>s
  356. # [11:19] <Lachy> ok
  357. # [11:20] <Lachy> well, I'm not sure if they're the type of sites he's referring to though. That's just the closest I could find that matches his description
  358. # [11:20] <Hixie> well when he sends his feedback like he told me he would we'll see :-)
  359. # [11:23] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  360. # [11:24] * Quits: danbri (n=danbri@unaffiliated/danbri) (Read error: 104 (Connection reset by peer))
  361. # [11:24] <zcorpan> Hixie: i think it is now undefined what document.bgcolor does when document.body *is* a frameset
  362. # [11:24] * Joins: danbri (n=danbri@85.144.208.21)
  363. # [11:24] <Hixie> zcorpan: send mail, i'm in the middle of a massive edit
  364. # [11:25] * Joins: RyanRoberts (n=ryanrobe@5ad6a77a.bb.sky.com)
  365. # [11:34] * Joins: gsnedders (n=gsnedder@pat.se.opera.com)
  366. # [11:34] * Joins: poe (n=poe@adsl-ull-160-123.48-151.net24.it)
  367. # [11:55] * Quits: tantek (n=tantek@70.36.139.128)
  368. # [12:20] <gsnedders> Hixie: http://www.whatwg.org/specs/web-apps/current-work/ is missing header-whatwg
  369. # [12:21] <Hixie> yeah
  370. # [12:21] <Hixie> i'm rewriting the script
  371. # [12:21] <Hixie> it still has bugs
  372. # [12:23] * gsnedders looks at the W3C version instead
  373. # [12:23] * Joins: rubys1 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
  374. # [12:24] <MikeSmith> Hixie: btw, I plan to write a cron job that will generate a multipage version of the W3C copy
  375. # [12:24] <MikeSmith> I meant to do it today, but didn't
  376. # [12:25] <MikeSmith> today being, it's 19:20 here and I need to get some food and alcohol of some form
  377. # [12:26] <MikeSmith> but to give a heads-up, I would like to also set up a .htaccess file so that the index file for the multipage version becomes the default
  378. # [12:26] <MikeSmith> with a link to the single-page one
  379. # [12:27] <Hixie> k
  380. # [12:27] <MikeSmith> which I realize might break some people's bookmarks and such
  381. # [12:28] <MikeSmith> I'm mentioning because when I do get it set up, I would need for you to add the link on the single-page version
  382. # [12:28] <MikeSmith> your source, I mean
  383. # [12:28] * gsnedders also set up http://gsnedders.html5.org/html5.txt semi-jokingly
  384. # [12:29] <MikeSmith> gsnedders: there's at least one SDO I know of for which that format looks optimized
  385. # [12:29] <MikeSmith> good job
  386. # [12:30] <hsivonen> gsnedders: how are you generating it? Lynx?
  387. # [12:30] <gsnedders> MikeSmith: But we don't have all the proper form feed characters and such like in the right place
  388. # [12:30] <gsnedders> hsivonen: yeah
  389. # [12:30] <hsivonen> gsnedders: it has a very IETF-like flavor
  390. # [12:32] <MikeSmith> gsnedders: I think I like link #19944 best
  391. # [12:32] <gsnedders> MikeSmith: I quite like #772
  392. # [12:33] * Quits: poe (n=poe@unaffiliated/xerox)
  393. # [12:33] <MikeSmith> ah yes, good old #772
  394. # [12:33] <MikeSmith> solid gold
  395. # [12:34] <MikeSmith> zen-like
  396. # [12:36] <MikeSmith> but outside of that instance, the combination of plain text with ridiculously long fragment IDs has its own kind of aesthetic quality
  397. # [12:36] <Philip`> MikeSmith: The WHATWG multipage one has a script that ensure bookmarks to /#foo will get redirected to /bar.html#foo etc
  398. # [12:36] <MikeSmith> (scare quotes implied in my statement above)
  399. # [12:36] <MikeSmith> Philip`: OK, maybe I can make use of that
  400. # [12:36] <MikeSmith> after I actually get around to doing it
  401. # [12:37] <MikeSmith> instead of just talking about, repeatedly
  402. # [12:37] <Philip`> If you talk about doing the work enough times, someone else will do the work to shut you up
  403. # [12:38] <MikeSmith> great strategy
  404. # [12:38] <MikeSmith> I will try that
  405. # [12:38] <MikeSmith> will try it later
  406. # [12:38] <MikeSmith> in the mean time, I noticed that the beer clock rang 90 minutes ago
  407. # [12:39] <MikeSmith> so I must depart
  408. # [12:39] <gsnedders> MikeSmith: Good bye, fair well, and best wishes for your future life!
  409. # [12:40] * MikeSmith fires up his chopper and heads to the rock shop
  410. # [12:40] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
  411. # [12:44] <Hixie> gsnedders: ok, it should be ok again
  412. # [12:50] * Joins: heycam` (n=cam@203-217-77-251.dyn.iinet.net.au)
  413. # [12:57] <gsnedders> getComputedStyle returns interesting values for iframes
  414. # [12:58] <Hixie> self.numberOfSpecs += 1
  415. # [12:59] * Quits: heycam (n=cam@124-168-9-27.dyn.iinet.net.au) (Read error: 101 (Network is unreachable))
  416. # [13:01] <hsivonen> http://www.w3.org/mid/A7420EAA6B164D40A3D94E082C4D2773@JukanPC
  417. # [13:01] <hsivonen> last paragraph
  418. # [13:02] <Hixie> o_O
  419. # [13:02] <hsivonen> I could well imagine Jukka blasting us for making it valid had we done that
  420. # [13:02] <Hixie> he wants the character references that refer to numbers that aren't the specified numbers to be conforming?
  421. # [13:03] <Hixie> i don't understand that e-mail
  422. # [13:03] <Hixie> he says it's undefined but it should be allowed?
  423. # [13:03] <Hixie> how does that even make sense
  424. # [13:04] <hsivonen> Hixie: maybe you could ask him what he wants
  425. # [13:04] <Hixie> since he thinks html5 is pointless, i don't see much point asking him
  426. # [13:05] <hsivonen> fair enough
  427. # [13:05] <hsivonen> when did Jukka flip the bozo bit on us?
  428. # [13:07] <hsivonen> I need some kind of Mail.app trick for dealing with duplicate email on 3 mailing lists plus self
  429. # [13:08] <Hixie> route your mail through gmail
  430. # [13:08] <Hixie> it filters dupes
  431. # [13:09] <Hixie> dunno when jukka flipped the bit, but it was a while back
  432. # [13:09] <Hixie> ok i now have less e-mail on the pile than this morning. Only by 3 e-mails, but still.
  433. # [13:09] <Hixie> bed time
  434. # [13:09] <Hixie> nn
  435. # [13:14] * Joins: pesla (n=retep@procurios.xs4all.nl)
  436. # [13:22] * Quits: webben (n=benh@nat/yahoo/x-a1d5bf4bd71165da) (Read error: 110 (Connection timed out))
  437. # [13:25] * Quits: rubys1 (n=Adium@cpe-098-027-052-152.nc.res.rr.com) ("Leaving.")
  438. # [13:29] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 113 (No route to host))
  439. # [13:32] * Quits: ray (i=ray@ipv6.the.ug) (Read error: 60 (Operation timed out))
  440. # [13:32] * Joins: ray (i=ray@ipv6.the.ug)
  441. # [13:32] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  442. # [13:40] * Joins: zdobersek (n=zan@cpe-92-37-66-98.dynamic.amis.net)
  443. # [13:40] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  444. # [13:42] * Joins: Lachy (n=Lachlan@85.196.122.246)
  445. # [13:44] * Joins: tndH (n=Rob@129.11.105.100)
  446. # [13:53] <takkaria> hm, I just discvered the CSS property table-layout
  447. # [13:54] <takkaria> I wonder how I've gone so long without knowing it exists
  448. # [13:55] <takkaria> I think I'd actually have preferred not to know about it...
  449. # [13:55] <RyanRoberts> FF2 supports it so probably a while ;)
  450. # [13:57] <jgraham> hmm I'm not sure I remember that one either
  451. # [13:57] <jgraham> Well I have a vauge memory of having encountered it before
  452. # [13:58] <RyanRoberts> actually I maybe mistaken
  453. # [13:59] * Quits: tndH (n=Rob@129.11.105.100) (Read error: 104 (Connection reset by peer))
  454. # [13:59] <takkaria> table-layout: fixed is an abomination, it lets you tell tables to not pay attention to the size of the content of its cells when calculating layout
  455. # [14:00] <RyanRoberts> it's CSS2 isn't it? I rarely use tables so not used it often but I'm sure I've come across it.
  456. # [14:00] <takkaria> yeah, css2
  457. # [14:00] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
  458. # [14:03] <jgraham> I guess someone decided that the default algorithm was slow/complex/hard to specify and thought "I know why don't we add an option"
  459. # [14:03] <jgraham> But the mailing list archives don't turn anything up
  460. # [14:10] <Lachy> takkaria, table-layout: fixed; actually has some benefits. You just have to be careful about how you use it.
  461. # [14:10] * hsivonen wonders if Google has criteria for phasing out support for old browser versions
  462. # [14:11] <Philip`> Revenue from ads for old browsers users < cost of supporting old browser versions, perhaps
  463. # [14:12] <Lachy> takkaria, one benefit is that it makes table columns equal width by default, which is otherwise difficult to achieve when the number of columns can vary but you always want the table to be a set width regardless
  464. # [14:12] * Joins: tndH (n=Rob@129.11.60.45)
  465. # [14:13] <Philip`> http://philip.html5.org/tests/canvas/suite/tests/results.html uses table-layout:fixed
  466. # [14:14] <hsivonen> I wonder how much RAM I'd need not to beach ball all the time
  467. # [14:15] * Quits: pesla (n=retep@procurios.xs4all.nl) (hubbard.freenode.net irc.freenode.net)
  468. # [14:15] * Quits: gsnedders (n=gsnedder@pat.se.opera.com) (hubbard.freenode.net irc.freenode.net)
  469. # [14:15] * Quits: syp_ (n=syp@lasigpc9.epfl.ch) (hubbard.freenode.net irc.freenode.net)
  470. # [14:15] * Joins: syp_ (n=syp@lasigpc9.epfl.ch)
  471. # [14:15] * Joins: pesla (n=retep@procurios.xs4all.nl)
  472. # [14:15] * Joins: gsnedders (n=gsnedder@88.131.66.80)
  473. # [14:15] <Lachy> hsivonen, how much RAM do you have?
  474. # [14:16] <hsivonen> 4 GB
  475. # [14:16] <Lachy> which apps are causing the beach ball so frequently?
  476. # [14:17] <hsivonen> I guess the combination of multiple browsers, IDEs and operating systems
  477. # [14:17] <jgraham> virtual machines that reserve large chunks of RAM are a killer
  478. # [14:17] <Lachy> oh. yeah, if you keep multiple OSs running in VMs all the time, there's not much you can do about it
  479. # [14:17] <Philip`> You could get faster swap space
  480. # [14:18] <Lachy> although, it wouldn't hurt upgrading to a new machine with 8GB or RAM
  481. # [14:18] <jgraham> Can you use SSDs as swap yet? and does that work well?
  482. # [14:18] <Philip`> jgraham: Why would you have ever been unable to?
  483. # [14:18] <hsivonen> Lachy: Macs that can host more than 4 GB of RAM are expensive and large
  484. # [14:19] <jgraham> Philip`: Because they didn't exist. ALso because they had very poor rewrite characteristics
  485. # [14:19] <Lachy> hsivonen, the new MacBook Pro's support 8GB. Just buy your RAM from a 3rd party supplier, instead of through Apple
  486. # [14:19] <jgraham> (like they would die after an alarmingly small number of rewrites)
  487. # [14:19] <hsivonen> oh. I was unaware of MacBook Pro accepting 8 GB
  488. # [14:20] <hsivonen> perhaps I should pay up and get one of those
  489. # [14:20] <Lachy> yeah, as of the most recent update, they do
  490. # [14:20] <jgraham> hsivonen: Would it actually be a blocker for you to use a Mac Pro as your main development machine and just use a laprop when travelling?
  491. # [14:20] <jgraham> THat seems like a more sensible solution
  492. # [14:21] * Joins: zdobersek1 (n=zan@cpe-92-37-76-123.dynamic.amis.net)
  493. # [14:21] * Quits: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  494. # [14:21] <hsivonen> jgraham: Mac Pro seems like an overkill in every dimension except RAM
  495. # [14:22] * Joins: myakura (n=myakura@p5137-ipbf707marunouchi.tokyo.ocn.ne.jp)
  496. # [14:22] * Quits: tndH (n=Rob@129.11.60.45) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  497. # [14:22] <jgraham> hsivonen: Hmm. It just seems worryingly shortsighted to upgrade to a machine in order to use its maximum amount of RAM
  498. # [14:23] <jgraham> Since probably in 1 year you will want more again
  499. # [14:23] <Lachy> hsivonen, a dual Quad Core Mac Pro with 32 GB of RAM would be awesome!
  500. # [14:25] <hsivonen> I could also try running a manual garbage collection of my Firefox tabs once in a while
  501. # [14:25] * Joins: webben (n=benh@nat/yahoo/x-cbca5c264341e7a5)
  502. # [14:25] <hsivonen> the annoying part is that closing multiple tabs beach-balls Firefox
  503. # [14:26] * Joins: aboodman2 (n=aboodman@72.14.229.81)
  504. # [14:28] * Quits: webben (n=benh@nat/yahoo/x-cbca5c264341e7a5) (Read error: 104 (Connection reset by peer))
  505. # [14:30] <gsnedders> What's the W3C IRC server?
  506. # [14:30] <hsivonen> irc.w3.org with weird port
  507. # [14:30] <hsivonen> 6667 or 6665 but not the one that's normal
  508. # [14:31] <Lachy> either port 6665 or port 80 works
  509. # [14:31] <hsivonen> I wonder if port 80 complies with Architecture.
  510. # [14:32] <Lachy> I don't think they care too much if it does. They just need it to bypass overzealous port blocking
  511. # [14:33] * Quits: aboodman (n=aboodman@72.14.229.81) (Connection timed out)
  512. # [14:33] * Quits: zdobersek (n=zan@cpe-92-37-66-98.dynamic.amis.net) (Read error: 110 (Connection timed out))
  513. # [14:45] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  514. # [15:04] * Joins: webben (n=benh@nat/yahoo/x-4621a04377acbccd)
  515. # [15:07] * Quits: archtech (n=stanv@83.228.56.37)
  516. # [15:07] * Quits: abii (n=macbook@cm27.delta30.maxonline.com.sg)
  517. # [15:09] * Joins: pmuellr (n=pmuellr@nat/ibm/x-9a9eaae68b97bf6f)
  518. # [15:29] * Quits: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  519. # [15:33] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  520. # [15:35] * Quits: jgraham (n=jgraham@web22.webfaction.com) (Read error: 104 (Connection reset by peer))
  521. # [15:36] <zcorpan> Hixie: + attribute unsigned <span title="dom-img-vspace">vspace</span>;
  522. # [15:36] <zcorpan> Hixie: should say unsigned long
  523. # [15:39] * Joins: taf2_ (n=taf2@38.99.201.242)
  524. # [15:40] * Quits: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au) ("This computer has gone to sleep")
  525. # [15:53] * Joins: aroben (n=aroben@unaffiliated/aroben)
  526. # [16:01] * Joins: ap (n=ap@72-62-10-39.pools.spcsdns.net)
  527. # [16:16] * Joins: dave_levin_ (n=dave_lev@98.203.247.78)
  528. # [16:24] * Quits: ap (n=ap@72-62-10-39.pools.spcsdns.net)
  529. # [16:28] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.85 [Firefox 3.6a1pre/20090711143741]")
  530. # [16:31] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  531. # [16:32] * Joins: mookid (i=mookid@ROFL.name)
  532. # [16:33] * Joins: svl (n=me@86.87.68.167)
  533. # [16:36] <mookid> hello collection of hated people
  534. # [16:36] <mookid> how's it hanging?
  535. # [16:38] <takkaria> I'm feeling pretty hated today
  536. # [16:39] <mookid> and all you had to do was make the internet better
  537. # [16:39] <mookid> pfff
  538. # [16:41] <krijnh> Am I hated as well?
  539. # [16:41] <krijnh> For doing what, nothing?
  540. # [16:41] <Lachy> mookid, there are some people in here who aren't hated by anyone
  541. # [16:41] <krijnh> Pick me, pick me
  542. # [16:42] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  543. # [16:42] <mookid> well you're associated
  544. # [16:42] <Lachy> mookid, do you dislike such people enough to not feel like saying hi to them as well?
  545. # [16:42] <mookid> that's bad enough
  546. # [16:42] <mookid> I didn't say I hated you
  547. # [16:42] <mookid> I think you're hillarious
  548. # [16:42] <mookid> personally
  549. # [16:46] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  550. # [17:00] * Joins: ap (n=ap@nat/apple/x-d51eab098a917e7f)
  551. # [17:03] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  552. # [17:06] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  553. # [17:06] * Joins: dglazkov (n=dglazkov@nat/google/x-6a932a9011b44ea7)
  554. # [17:09] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  555. # [17:14] * Quits: ZombieL (n=e@78-72-50-94-no61.tbcn.telia.com) (Client Quit)
  556. # [17:19] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  557. # [17:24] * Joins: jgraham (n=jgraham@74.53.238.210)
  558. # [17:27] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
  559. # [17:27] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  560. # [17:31] * Quits: harig (n=harig@59.90.71.35)
  561. # [17:40] * Quits: gunderwonder (n=gunderwo@garage.upstruct.com)
  562. # [17:46] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-3cb6fef9ae9fc32c)
  563. # [17:51] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  564. # [17:51] * Quits: myakura (n=myakura@p5137-ipbf707marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  565. # [17:53] * Joins: dbaron (n=dbaron@nat/mozilla/x-de7f3e627e31161f)
  566. # [17:55] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) (Read error: 110 (Connection timed out))
  567. # [17:57] * Quits: dave_levin_ (n=dave_lev@98.203.247.78)
  568. # [17:58] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
  569. # [18:02] * Quits: Khazou (n=Khazou@AReims-152-1-133-45.w86-215.abo.wanadoo.fr)
  570. # [18:05] * Joins: remysharp (n=remyshar@remysharp.plus.com)
  571. # [18:06] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-6a7ef9ccf1ff5494)
  572. # [18:07] * Joins: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net)
  573. # [18:08] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  574. # [18:18] <ezyang> So, if something is ignored but "not conforming", does that result in a parse error?
  575. # [18:18] <ezyang> A "non-conforming error"?
  576. # [18:19] * Joins: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
  577. # [18:22] <Philip`> ezyang: If something is not said to be a parse error, then I would expect that it's not a parse error
  578. # [18:22] <Philip`> (though it could still be a conformance failure)
  579. # [18:22] <ezyang> Sure.
  580. # [18:23] <Philip`> So I'm not sure what your query is :-)
  581. # [18:23] <ezyang> The html5lib spec doesn't give me a lot to work on in terms of algorithms that convert nonconforming HTML to conforming HTML
  582. # [18:23] <ezyang> erm, s/html5lib/HTML 5/
  583. # [18:23] <Philip`> In general that's impossible
  584. # [18:23] <Philip`> since it's not even possible for a machine to determine whether a document is conforming or not
  585. # [18:24] <Philip`> so I suppose you'll have to choose what set of errors you want to restrict yourself to fixing
  586. # [18:25] <ezyang> Oh yeah, of course. The goal is "anything that is machine detectable"
  587. # [18:26] * aroben is now known as aroben|lunch
  588. # [18:27] <jgraham> ezyang: Still not possible (at least in some sensible way) e.g. if alt were mandatory there would be no way to take an image with no alt value (machine detectable) and insert the correct alt value
  589. # [18:28] <jgraham> Even in more simple cases my feeling is that "you don't want to do that" even though clearly some people do want to do that
  590. # [18:28] <ezyang> haha. My algorithm there is to insert the filename, or some configurable value.
  591. # [18:29] <jgraham> ezyang: Fail
  592. # [18:29] <Philip`> Will you handle stuff like <table><tr><td><td rowspan=2><tr><td colspan=2></table> too? :-)
  593. # [18:29] <ezyang> Philip`: I don't handle that yet, but it's presumably an algorithm I could write.
  594. # [18:29] <jgraham> ezyang: Seriously there is nothing good about inserting the filename automatically and a bunch of bad things. Please don't do it
  595. # [18:30] <ezyang> Can I... insert a Zen koan?
  596. # [18:30] <Philip`> jgraham: The good thing is that the validator will give you a tick, and that's what really matters
  597. # [18:31] <jgraham> Philip`: :(
  598. # [18:32] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  599. # [18:32] <ezyang> Unfortunately, that's the most user visible, and I have a commitment to not break that.
  600. # [18:32] <gsnedders> ezyang: From an a11y POV, you don't want to add an alt attribute to some useless value.
  601. # [18:33] <Philip`> (I presume the main point of a non-conforming-to-conforming converter is to let you get ticks, because in terms of e.g. preserving the author's intent it's going to be worse than HTML5's processing requirements for non-conforming content)
  602. # [18:33] <ezyang> I mean, ideally the form processor would be smart enough to recognize these unresolvable cases and ask the user what they actually meant.
  603. # [18:34] <ezyang> Philip`: The other point of nonconforming to conforming is because it means we can unambiguously determine intent.
  604. # [18:34] <jgraham> ?!?
  605. # [18:34] <ezyang> The space of conforming HTML is much smaller than nonconforming HTML, and browser behavior much better studied.
  606. # [18:34] <ezyang> sorry, bad word choice
  607. # [18:34] <ezyang> When I say intent, I mean, the way browsers will deal with it.
  608. # [18:35] <ezyang> i.e. it gives desirable security properties.
  609. # [18:35] <gsnedders> Once all browsers use HTML 5 parsers, that's no longer the case.
  610. # [18:35] * jgraham doesn't understand how original code -> magic black box -> conforming code really helps
  611. # [18:35] <jgraham> I certianly don't see how it is a security issue
  612. # [18:35] <gsnedders> jgraham: XSS
  613. # [18:35] <Philip`> ezyang: If the goal is to fix markup that will have browser behaviour differences, then that seems very different to translating all non-conforming markup
  614. # [18:36] <jgraham> gsnedders: Conforming code can have XSS holes
  615. # [18:36] <Philip`> e.g. you wouldn't have to worry about img with no alt even if it was non-conforming
  616. # [18:36] <gsnedders> jgraham: <a href=`javascript:alert("so sue me")`>asd</a> will run the JS in IE but is non-conforming
  617. # [18:36] <ezyang> Right, so there are multiple issues here.
  618. # [18:36] <gsnedders> Actually, I don't think that is non-conforming.
  619. # [18:36] <jgraham> gsnedders: Right so you should strip that in a sanitizer, conforming or not
  620. # [18:37] * Quits: Phae (n=phaeness@gatea.mh.bbc.co.uk)
  621. # [18:37] <Philip`> and you would have to worry about conforming code like <!--[if IE 6]><script>alert("oh no")</script><![endif]-->
  622. # [18:37] <ezyang> From the XSS standpoint, syntactic conformance is a huge plus. Not as much for tags, although by whitelisting to conformant tags and then further removing problem tags, you further restrict things.
  623. # [18:37] <gsnedders> It probably should be non-conforming, though, for the very reason that IE will execute that
  624. # [18:37] <ezyang> Philip`: I explicitly disallow comments because of the fact that they commonly carry out of band information that is exploitable
  625. # [18:38] <Philip`> ezyang: So you're making a sanitiser, rather than a tool to convert non-conforming markup to conforming markup?
  626. # [18:38] <jgraham> For XSS I would have thought that applying sanitization based on the HTML5 algorithm is enough. Whether the result is conforming or not is irrelevant
  627. # [18:38] <ezyang> But not just that
  628. # [18:38] <gsnedders> Philip`: It's both
  629. # [18:38] <Philip`> That sounds needlessly complex :-)
  630. # [18:38] <jgraham> Certianly whether it has alt attributes is irrelevant
  631. # [18:38] <gsnedders> http://htmlpurifier.org/demo.php
  632. # [18:39] <ezyang> From a marketing standpoint, it also makes sense to fix any conformance errors so that users can have the nice fuzzy feeling of a Green validator check.
  633. # [18:39] <ezyang> It is then that alt attributes are relevant.
  634. # [18:39] <gsnedders> ezyang: Even if that actually makes them less accessible?
  635. # [18:39] * Joins: Spark^ (n=x@94-194-199-197.zone8.bethere.co.uk)
  636. # [18:39] <jgraham> ezyang: It feels like we have got to the real reason for wanting conforming output
  637. # [18:39] <gsnedders> ezyang: And quite possibly makes them non-conforming in another way?
  638. # [18:39] * Joins: cying (n=cying@70.90.171.153)
  639. # [18:40] <jgraham> or rahter "valid"
  640. # [18:40] <jgraham> *rather
  641. # [18:40] <gsnedders> (As I'd hope giving useless @alt would be non-conforming, as I hope it requires an alternative to the image)
  642. # [18:40] <Philip`> We could add a <pretendthisisconforming> element to HTML5 so people can get validator ticks without having to make their code worse
  643. # [18:41] <gsnedders> ezyang: The problem with trying to make code valid is you can quite easily make it a lot worse from a conformance and accessibility point of view
  644. # [18:41] <ezyang> I think alt is the big offender.
  645. # [18:43] * Joins: dave_levin_ (n=dave_lev@72.14.227.1)
  646. # [18:44] <ezyang> So, to reiterate, conformance has various benefits: 1. you get validator ticks, 2. syntactic conformance makes XSS harder, 3. conforming HTML has more regular browser interpretation, letting us canonicalize the interpretation
  647. # [18:44] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) ("ChatZilla 0.9.85 [Firefox 3.5.1pre/20090712031210]")
  648. # [18:44] <ezyang> You roll over accessibility in the img alt case, but this can be fixed by smarter form processing, and is fairly isolated.
  649. # [18:47] <gsnedders> ezyang: 1 is not a benefit.
  650. # [18:47] <jgraham> 1 is not a benefit on its own. 2 seems extremely dubious to me. 3 is probably true but since you are basically just putting things through a magic black box you still won't get the results you expect in many cases
  651. # [18:47] <gsnedders> ezyang: 2 doesn't need validity
  652. # [18:48] <gsnedders> ezyang: 3 can't really be done programmatically.
  653. # [18:48] <gsnedders> (I say 2 doesn't need validity as it can be done just by doing stuff token-by-token)
  654. # [18:48] <gsnedders> (You can get a lot of the benefits of 2 just by parsing then serializing, and doing nothing more)
  655. # [18:49] <Philip`> http://htmlpurifier.org/demo.php?filter%5BAutoFormat.PurifierLinkify.DocURL%5D=%ef%bf%bf
  656. # [18:50] <jgraham> Actually if you have any attacks that htmlpurifier prevents but the html5lib sanitizer does not you should really file a bug on us
  657. # [18:50] * gsnedders notes that that was reported before and fixed, so is a regression
  658. # [18:50] <gsnedders> jgraham: We won't stop <script>alert("foo")</script> though
  659. # [18:51] <Philip`> gsnedders: No attacker would think we're stupid enough to try just writing a script tag, so they'll never know
  660. # [18:51] <gsnedders> Oh, wait, duh
  661. # [18:51] <jgraham> gsnedders: THe sanitizer will strip that
  662. # [18:51] <gsnedders> sanitizer, not serializer
  663. # [18:52] * Quits: remysharp (n=remyshar@remysharp.plus.com) ("Gotta shoot - "peeyaow"")
  664. # [18:54] <ezyang> Philip`: That... should have been fixed.
  665. # [18:54] <ezyang> Oh, that's a bug in the form code, not in the purifier
  666. # [18:55] <Philip`> (There's http://htmlpurifier.org/demo.php?filter%5BAutoFormat.AutoParagraph%5D=cheese too)
  667. # [18:55] * Parts: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
  668. # [18:56] <Philip`> I like how Sourceforge has adopted a colour scheme in which its forum messages are thin light grey text on a light blue background, and if I look at my laptop screen from an angle greater than twenty degrees then the text entirely disappears
  669. # [18:57] <ezyang> gsnedders: There is one main point that requires some sort of tree building algorithm, which is preventing user HTML elements from leaking to the parent tree.
  670. # [18:58] <gsnedders> ezyang: Sure, just parse and serialize to get there.
  671. # [18:58] <gsnedders> ezyang: Nothing more than that is needed for that,
  672. # [18:58] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-3cb6fef9ae9fc32c)
  673. # [18:58] <gsnedders> ezyang: Also, both myself and jgraham have doubts over two, as most of the issues will be fixed by parsing and serializing the tree, provided you quote attribute values and special case one or two things like < in tag name
  674. # [18:58] <ezyang> Whitelist philosophy means that I should very thoroughly inspect attributes and recursively parse data formats (i.e. CSS to URI)
  675. # [18:59] <gsnedders> ezyang: Sure, but that doesn't have anything to do with building a balanced tree
  676. # [18:59] <ezyang> It also means that I should know exactly what tags that I'm going to allow.
  677. # [18:59] <jgraham> Parsing CSS is a good idea. I would like to add that to html5lib
  678. # [18:59] <ezyang> Ok, so the core issues
  679. # [19:00] <ezyang> building a conforming tree, and generating required attributes
  680. # [19:00] <ezyang> Which y'all would like to convince me to not do.
  681. # [19:01] <ezyang> Everything else that HTML Purifier is useful, no?
  682. # [19:01] <ezyang> *is doing
  683. # [19:01] <gsnedders> ezyang: You cannot create a conforming tree programmatically. You can, however, produce a valid tree.
  684. # [19:02] * Quits: jianli (n=jianli@72.14.227.1)
  685. # [19:02] <ezyang> oh yes, that's what I meant
  686. # [19:02] * Joins: jianli (n=jianli@72.14.227.1)
  687. # [19:02] <jgraham> ezyang: I expect so althogh I don't know what all the other things it is doing are
  688. # [19:02] <gsnedders> ezyang: Everything else meaning what?
  689. # [19:02] <ezyang> With regards to fulfilling HTML 5 conformance requirements
  690. # [19:03] * Quits: pmuellr (n=pmuellr@nat/ibm/x-9a9eaae68b97bf6f)
  691. # [19:03] <ezyang> We want to fulfill syntactic conformance, which you get from tokenizing the stream
  692. # [19:03] * Joins: yshin (n=yshin@72.14.227.1)
  693. # [19:03] <ezyang> We want to build a tree, which has its own conformance things associated with it (i.e. <b><i>f</b></i>), which you get from tree-building
  694. # [19:03] <jgraham> The point about trying to create valid markup is that the main benefit seems to be a happy feeling conformance tick but there are substantial costs in terms of complexity, possibilites of harming end users, possibility of automagically misinterpreting the markup
  695. # [19:04] <ezyang> We want to recursively validate attributes, which increases conformance
  696. # [19:04] <gsnedders> What does HTML Purifier aim to do? Does it aim to produce secure markup, does it aim to produce valid markup?
  697. # [19:04] <ezyang> It aims to do both.
  698. # [19:04] * Joins: pmuellr (n=pmuellr@nat/ibm/x-5fcaa3aa698b5250)
  699. # [19:04] <ezyang> You could remove maybe 15% if you got rid of the valid markup requirement, specifically valid trees and attribute generation.
  700. # [19:05] <gsnedders> Fundamentally the latter is not a useful goal.
  701. # [19:05] <ezyang> The primary complexity comes from whitelisting and attribute validation
  702. # [19:05] <ezyang> Possibly.
  703. # [19:05] <gsnedders> You will get a lot of it from just parsing and serializing the tree, certainly
  704. # [19:05] <gsnedders> But that is a side-effect, more than anything else.
  705. # [19:05] <ezyang> Which is why I'm planning on swapping out most of my code for html5lib when the PHP impl gets stable enough
  706. # [19:07] * Quits: aroben|lunch (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  707. # [19:07] * Joins: aroben|lunch (n=aroben@unaffiliated/aroben)
  708. # [19:07] <gsnedders> Basically, I think what you need to do is parsing the input stream, remove elements/attributes on whitelist, remove some more attributes based upon their value, then serialize, quoting attribute values.
  709. # [19:07] <gsnedders> I think that should get you security.
  710. # [19:08] <Philip`> (and remove comments)
  711. # [19:09] <ezyang> gsnedders: I argue that removing attributes based on value is the wrong paradigm (it should be machine-semantic deconstruction of each attribute), but yes, essentially.
  712. # [19:09] <ezyang> And remove comments, yep.
  713. # [19:09] <gsnedders> ezyang: What's the difference?
  714. # [19:09] <gsnedders> ezyang: That is, ultimately, just inspecting the value. No?
  715. # [19:10] * Joins: drostie (n=hopkins@5ED17066.cable.ziggo.nl)
  716. # [19:10] <ezyang> Semantic deconstruction means that attribute values might change.
  717. # [19:10] <Philip`> The html5lib sanitiser has e.g. a regexp for detecting 'safe' style attribute values, and throws out any attribute that doesn't match, I think
  718. # [19:10] <ezyang> Canonicalization of a URL or CSS string is more important
  719. # [19:10] <gsnedders> Ah, OK
  720. # [19:10] <gsnedders> Yeah, right.
  721. # [19:10] <ezyang> Right. That kind of regex doesn't make me feel safe
  722. # [19:10] <Philip`> Me neither
  723. # [19:10] <ezyang> Although theoretically it might be secure.
  724. # [19:11] <gsnedders> For most attributes though, it is just looking at the value and nothing more
  725. # [19:11] <gsnedders> And I'm throwing together stuff from the top of my head :)
  726. # [19:11] <Philip`> The person who discovered the regexp takes exponential time on certain inputs probably wasn't too happy
  727. # [19:11] * gsnedders was just discussing that with jgraham
  728. # [19:11] <Philip`> gsnedders: Your hair?
  729. # [19:12] <gsnedders> (the use of the regex that is)
  730. # [19:12] <gsnedders> (Both of us think having a proper CSS parser would be better)
  731. # [19:12] <Philip`> (The stuff from the top of your head, that is)
  732. # [19:12] <ezyang> There is one more thing that HTML Purifier does, and that's enhance HTML.
  733. # [19:12] <gsnedders> Philip`: No, my hair doesn't include interesting information.
  734. # [19:12] <gsnedders> ezyang: "enhance"?
  735. # [19:12] <ezyang> Take something that normally didn't have meaning and transform it accordingly
  736. # [19:12] <ezyang> For example, turning plaintext URLs into links
  737. # [19:12] <jgraham> ?
  738. # [19:12] <jgraham> Oh
  739. # [19:13] <jgraham> Well that sounds like an OK function is your users want it
  740. # [19:13] <ezyang> Or adding paragraphing
  741. # [19:13] <gsnedders> ezyang: Can you just stick with purifying? :P
  742. # [19:13] <ezyang> I mean, you kind of /need/ these features if you're going to be writing HTML raw.
  743. # [19:13] <ezyang> Anyway, performing this transforms when you have a tree is much better.
  744. # [19:14] <ezyang> *these
  745. # [19:14] <gsnedders> I'd rather have a tool that just made sure HTML was secure.
  746. # [19:14] <gsnedders> s/tool/library/
  747. # [19:14] <ezyang> So you want decoupling. Well, you easily turn it off :-P
  748. # [19:15] <jgraham> Philip`: Any idea how hard it is to write a CSS parser?
  749. # [19:15] * gsnedders thinks the issue of what HTML Purifier should do is simpler if we take one thing it aims to do at a time
  750. # [19:15] <takkaria> jgraham: talk to jmb, he's just written one...
  751. # [19:16] <ezyang> It's a lot of drudge work.
  752. # [19:16] <jmb> takkaria: heh
  753. # [19:16] <gsnedders> ezyang: how do you parse it/
  754. # [19:16] <gsnedders> *?
  755. # [19:16] <Philip`> jgraham: I haven't got a clue
  756. # [19:16] <gsnedders> Philip`: Get a clue.
  757. # [19:16] <ezyang> Oh, that's easy: I just split on semicolons :-P
  758. # [19:16] <ezyang> Which is wrong, and also needs to be fixed.
  759. # [19:17] <gsnedders> ezyang: I expect doing any nice parser will be rather horrible in PHP
  760. # [19:17] <ezyang> CSS Tidy does it.
  761. # [19:17] <gsnedders> Mainly because there is no nice lexer to just easily use :P
  762. # [19:17] <ezyang> I just need to subsume it into HTML Purifier.
  763. # [19:17] <jgraham> jmb: Any idea how hard it is to write a CSS parser?
  764. # [19:18] * Quits: dave_levin_ (n=dave_lev@72.14.227.1)
  765. # [19:18] <ezyang> You can cut some corners, since style="" is much simpler than <style></style>
  766. # [19:18] <Philip`> I tried using a Python CSS parser once, but it seemed to have something like quadratic time complexity and so it was unusable for typical large inputs
  767. # [19:18] <jmb> jgraham: if one existed in a useful form before I wrote mine, I wouldn't have bothered
  768. # [19:18] <jmb> jgraham: this one's taken me about a year of spare time fwiw
  769. # [19:19] <jgraham> :(
  770. # [19:19] <ezyang> I would also argue that you need to whitelist the values of CSS properties, since you don't want to enumerate against browser proprietary extensions
  771. # [19:19] <jmb> you may have more spare time than me, though :)
  772. # [19:20] * gsnedders wonders how there manages to be no decent parsing libraries for PHP
  773. # [19:20] <jgraham> jmb: Wouldn't count on it
  774. # [19:20] <jmb> jgraham: http://www.netsurf-browser.org/projects/libcss/
  775. # [19:20] <jmb> fwiw
  776. # [19:23] * aroben|lunch is now known as aroben
  777. # [19:24] <ezyang> I still wonder if, one day, a browser will add support for a specific combination of tags that results in JavaScript being executed.
  778. # [19:24] * Joins: arun__ (n=arun@adsl-75-36-190-133.dsl.pltn13.sbcglobal.net)
  779. # [19:24] <ezyang> and in separate contexts it's ok.
  780. # [19:25] * Joins: maikmerten (n=maikmert@BAE20da.bae.pppool.de)
  781. # [19:27] <ezyang> Seems very unlikely.
  782. # [19:28] <ezyang> Ok, so here's what's going to happen. HTML Purifier 5.0 will be able to operate as "make it valid omgwtf" and "make it secure"
  783. # [19:29] <ezyang> For interest of backwards compatibility, "make it valid omgwtf" will be the default. Conscientous developers who don't care about validity can turn that off.
  784. # [19:29] <gsnedders> And then have the fun of evangelism to dissuade people from using the former.
  785. # [19:29] <ezyang> I mean, validators really did a lot of harm to conformance.
  786. # [19:29] <gsnedders> ezyang: In the longer term <iframe sandbox seamless> should work
  787. # [19:30] <ezyang> So long as there are legacy browsers, that will not be sufficient.
  788. # [19:30] * ezyang afk for lunch
  789. # [19:30] <ezyang> This was a good discussion, and definitely changed my mind about where HTML Purifier 5.0 is going.
  790. # [19:34] * Joins: jwalden (n=waldo@nat/mozilla/x-2ddbc2430f1eb0e4)
  791. # [19:34] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) ("Wünsche weiterhin guten Flug")
  792. # [19:39] <gsnedders> ezyang: I'll probably send an email later
  793. # [19:39] <gsnedders> (Like, when I get home from work)
  794. # [19:42] * Joins: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
  795. # [19:43] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  796. # [19:44] * Joins: sbublava (n=stephan@77.117.11.54.wireless.dyn.drei.com)
  797. # [19:48] * aboodman2 is now known as aboodman
  798. # [19:49] <ezyang> Email?
  799. # [19:56] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  800. # [20:04] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
  801. # [20:04] * Quits: pmuellr (n=pmuellr@nat/ibm/x-5fcaa3aa698b5250)
  802. # [20:06] * Joins: dglazkov_ (n=dglazkov@nat/google/x-29e6d2ed0997c27e)
  803. # [20:07] * Quits: dglazkov_ (n=dglazkov@nat/google/x-29e6d2ed0997c27e) (Client Quit)
  804. # [20:08] * Quits: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  805. # [20:10] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-6a7ef9ccf1ff5494) (Read error: 104 (Connection reset by peer))
  806. # [20:10] * Joins: pmuellr (n=pmuellr@nat/ibm/x-953a6346adf9cf65)
  807. # [20:12] * Quits: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  808. # [20:14] * Quits: jacobolus (n=jacobolu@adsl-75-36-158-29.dsl.pltn13.sbcglobal.net) (Remote closed the connection)
  809. # [20:17] * Quits: dbaron (n=dbaron@nat/mozilla/x-de7f3e627e31161f) ("8403864 bytes have been tenured, next gc will be global.")
  810. # [20:19] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-c6f32d714bfc6d1b)
  811. # [20:20] * Joins: ojan (n=ojan@72.14.229.81)
  812. # [20:20] * Quits: dglazkov (n=dglazkov@nat/google/x-6a932a9011b44ea7) (Read error: 110 (Connection timed out))
  813. # [20:22] * Joins: archtech (n=stanv@83.228.56.37)
  814. # [20:24] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  815. # [20:25] <JoePeck> Hello. Is there any way to access the current page's response headers via Javascript, like you can access an AJAX Requests response headers (with xhr.getAllResponseHeaders etc). And if not, why not or was it just not thought of?
  816. # [20:27] <JoePeck> Since you can just spawn an AJAX request for the current page, and get the headers that way, I think it should be allowable for Javascript to have access to the response headers of the current page. At least I can't think of a realistic security concern.
  817. # [20:34] * Quits: mat_t (n=mattomas@nat/canonical/x-eb63950733a08e81) ("This computer has gone to sleep")
  818. # [20:37] * Joins: dolske (n=dolske@nat/mozilla/x-5b54ad994211b6ff)
  819. # [20:37] * Joins: gsnedders_ (n=gsnedder@c83-252-199-225.bredband.comhem.se)
  820. # [20:38] * Joins: mat_t (n=mattomas@nat/canonical/x-76bd221a517d8385)
  821. # [20:43] <sebmarkbage> JoePeck: As far as I know you can't and I agree. It is an oversight.
  822. # [20:44] <JoePeck> Hmm, should I make a formal email to the mailing list?
  823. # [20:47] <mookid> no
  824. # [20:47] <mookid> the response is the response
  825. # [20:48] <sebmarkbage> Scripts should be able to resolve things such as relative URIs if the HTTP header "Content-Base" is used. We shouldn't have to use meta or base tags for that.
  826. # [20:48] <JoePeck> mookid: but the headers aren't available to Javascript?
  827. # [20:48] <mookid> the client side doesn't, and shouldn't, be able to modify the response - it just is what it is
  828. # [20:48] <gsnedders_> ezyang: Yes, email. You know these things?
  829. # [20:48] <JoePeck> mookid: not modify, access. What about custom headers?
  830. # [20:48] * Quits: mat_t (n=mattomas@nat/canonical/x-76bd221a517d8385) ("This computer has gone to sleep")
  831. # [20:49] <JoePeck> not that it would make any sense to modify the response headers... they are the response headers =)
  832. # [20:51] <sebmarkbage> Out of curiousity, what headers would you like to access? Custom only?
  833. # [20:52] <JoePeck> sebmarkbage: actually, someone in ##javascript wanted to access the "Date" header sent from his server
  834. # [20:52] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  835. # [20:52] <JoePeck> but I could think of accessing the Content-Type and custom headers
  836. # [20:52] <JoePeck> as possible use cases
  837. # [20:52] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.85 [Firefox 3.6a1pre/20090709035810]")
  838. # [20:52] <mookid> wait - what
  839. # [20:53] <JoePeck> mookid: it seems I have a difficult time explaining this because everyone seems to respond with a "what?" =(
  840. # [20:53] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
  841. # [20:53] <mookid> you can't read response headers?
  842. # [20:53] <JoePeck> Here was my example page: http://bogojoker.com/x/xhr/headers.html
  843. # [20:54] <JoePeck> you can read the response headers, but only for an AJAX Request
  844. # [20:54] <sebmarkbage> You can read response headers off of XHR but not for the current document.
  845. # [20:54] <JoePeck> exactly
  846. # [20:54] <sebmarkbage> I.e. you'd have to make another request to find that out.
  847. # [20:54] <JoePeck> sebmarkbage++ thanks =)
  848. # [20:55] <mookid> yeah well that's a good example of what a ridiculously poor HTTP client most browsers are
  849. # [20:55] <mookid> you'll get the "we need a use case" nonsense
  850. # [20:56] <takkaria> ...
  851. # [20:56] <mookid> the reality is that they didn't read the RFC properly
  852. # [20:56] <JoePeck> well, why get the response headers from an ajax request? If there was a use case for that then they all apply for this case as well
  853. # [20:56] <takkaria> you can be a perfectly good HTTP client without exposing request headers to JavaScript
  854. # [20:57] <mookid> browsers are crap HTTP clients
  855. # [20:57] <JoePeck> I agree with takkaria on that
  856. # [20:57] <JoePeck> mookid: and what would you suggest as a good HTTP client?
  857. # [20:57] <takkaria> that may or may not be true, but it's irrevelant to exposing things to JS
  858. # [20:57] <mookid> one that behaves as though the developers read the HTTP RFC
  859. # [20:58] <JoePeck> hmm the "and" makes that statement sound stuck up, I don't mean that, I'm just curious
  860. # [20:58] <mookid> take a look at the Accept header for most browsers
  861. # [20:58] <mookid> go read the RFC
  862. # [20:58] <mookid> and try and work out what these people were thinking
  863. # [20:58] <mookid> if anything at all
  864. # [20:58] <mookid> probably too busy doing crack and beating their wives
  865. # [20:59] <JoePeck> oookay
  866. # [20:59] <mookid> but hey
  867. # [20:59] <mookid> there's no use case for appropriate Accept headers
  868. # [21:00] <mookid> what about HTML5 providing a mechanism for protocol level content negotiation?
  869. # [21:00] <mookid> nope - no use case
  870. # [21:00] <mookid> we've got URIs!
  871. # [21:00] <mookid> idiotic.
  872. # [21:00] <mookid> completely and utterly idiotic.
  873. # [21:00] <mookid> #
  874. # [21:01] <mookid> it's a wonder why anyone actually bothers writing RFCs
  875. # [21:01] <takkaria> mookid: watch out, you'll start to rail against the evils of the capitalist press next
  876. # [21:01] <mookid> yeah be as aloof as you want
  877. # [21:02] <mookid> your technology is a joke.
  878. # [21:03] <mookid> but hey - at least we've got snazzy videos moving around the page that rotate and shit!
  879. # [21:03] <mookid> awwwwweeesssommmme
  880. # [21:03] <takkaria> my technology? I'm not sure I've produced any technology I could lay claim to. :)
  881. # [21:03] <sebmarkbage> I'm sorry, you lost me at crack. The use case of being able to read headers is that it allows for a cleaner model as opposed to for example meta tags. Meta data that belongs in HTTP could then stay there.
  882. # [21:04] <mookid> I'm all for self descriptive messages
  883. # [21:04] <mookid> that's probably why you lost me
  884. # [21:05] * cying is now known as cyingLunch
  885. # [21:05] <mookid> I'm in favour of keeping that stuff in the message headers
  886. # [21:05] <mookid> good luck convincing these guys that HTTP is relevant to their 'ground breaking' work
  887. # [21:05] <mookid> unless there's a use case for it
  888. # [21:07] <mookid> a use case for them to listen to you i mean
  889. # [21:07] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  890. # [21:08] * Joins: ZombieL (n=e@c80-217-237-176.bredband.comhem.se)
  891. # [21:08] <gsnedders_> mookid: What's inappropriate about the Accept headers browsers send? (And I'm totally serious about asking that, I know what the spec says, and it seems perfectly sane to me.)
  892. # [21:09] <mookid> well
  893. # [21:09] <mookid> someone wrote a post about this recently
  894. # [21:09] <mookid> http://newmediacampaigns.com/page/browser-rest-http-accept-headers
  895. # [21:10] <mookid> what is so hard about changing it to Accept: text/html,*/*;q=0.9
  896. # [21:10] * Quits: ZombieL (n=e@c80-217-237-176.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
  897. # [21:10] <mookid> oh wait sorry I forgot
  898. # [21:10] <mookid> there's no use case
  899. # [21:11] <gsnedders_> mookid: Because then people will complain that they don't claim to support application/xhtml+xml just as well as it does text/html
  900. # [21:12] * Joins: ZombieL (n=e@c80-217-237-176.bredband.comhem.se)
  901. # [21:12] <mookid> why don't you read that post
  902. # [21:12] <gsnedders_> I am reading it.
  903. # [21:12] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe) (Success)
  904. # [21:12] * Quits: ZombieL (n=e@c80-217-237-176.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
  905. # [21:12] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  906. # [21:14] <gsnedders_> IE's seems sane insofar as it lists what it supports, but all equally, which is a bit odd. I would expect it to prefer text/html. WebKit's is odd seeming that image/png is there (I do also wonder why application/xml is equal to application/xhtml+xml and above text/html, but providing a generic XML MIME type along side application/xhtml+xml doesn't seem entirely crazy). Firefox seems the sanest, though.
  907. # [21:14] * gsnedders_ wonders what we send
  908. # [21:14] <mookid> we = firefox?
  909. # [21:14] <gsnedders_> we = Opera
  910. # [21:14] <mookid> oh right
  911. # [21:14] <mookid> oh you're probably sane =)
  912. # [21:14] <gsnedders_> (As we are only mentioned in passing as being sane)
  913. # [21:14] <gsnedders_> text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
  914. # [21:14] * ZombieLoffe is now known as ZombieL
  915. # [21:15] <mookid> eww
  916. # [21:15] <gsnedders_> That doens't seem quite so sane.
  917. # [21:15] <gsnedders_> *doesn't
  918. # [21:15] <gsnedders_> If anything, that's the least sane.
  919. # [21:15] <mookid> well this is academic anyway since there's no need for HTTP content negotiation because "you can put it in the URI"
  920. # [21:15] <mookid> apparently.
  921. # [21:15] <mookid> =/
  922. # [21:16] <ezyang> I think Accept headers make most sense for embedded resources
  923. # [21:17] <mookid> well they make no sense in practical web app terms
  924. # [21:17] <mookid> because you can't specify them in context to a browser in HTML
  925. # [21:17] <ezyang> Yes you can. <img />
  926. # [21:17] <JoePeck> mookid: so if a person asks for blah.html and their Accept header states they would want xml over html you should respect the Accept header and give them xml?
  927. # [21:17] <mookid> ok ok
  928. # [21:17] <mookid> let me just say something
  929. # [21:17] <Philip`> Ooh, this discussion again
  930. # [21:17] <ezyang> JoePeck: No, since you explicitly specified what content type you want with .html
  931. # [21:18] <krijnh> Is it known that IE throws almost the entire DOM inside the head in this case: http://krijnhoetmer.nl/zooi/html5/gone-in-ie.html ?
  932. # [21:18] <gsnedders_> ezyang: File names are meaningless.
  933. # [21:18] <mookid> say I have something called /resource - and I have 2 representations of that resource in json and xml; but they are the SAME resource
  934. # [21:18] <JoePeck> ezyang: thats what I thought, so most of this doesn't seem crazy to me. =)
  935. # [21:18] <gsnedders_> ezyang: If you have both representations of the resource, you should give them XML.
  936. # [21:18] <mookid> I don't want /resource.xml and /resource.json because those URIs are 2 separate resources
  937. # [21:18] <ezyang> gsnedders_: How so? If you want to turn on Multiviews, you better damn well be serving files w/o extensions
  938. # [21:18] <mookid> URIs are *opaque*
  939. # [21:18] <mookid> which is extremely important
  940. # [21:19] * Joins: ap_ (n=ap@17.246.19.81)
  941. # [21:19] <gsnedders_> ezyang: Well, I mean extensions are.
  942. # [21:19] <JoePeck> "those URIs are 2 separate resources" those 2 URIs don't need to exist, they just need to be parsed.
  943. # [21:19] <mookid> the fact that we've been forced into using the URI for this is irrelevant it's bad practice if the two document types are representations of the same resource
  944. # [21:19] <gsnedders_> mookid: When does it become important, though?
  945. # [21:19] <mookid> good god.
  946. # [21:19] <ezyang> mookid: I agree. But there still needs to be a mechanism for explicitly specifying the desired content type
  947. # [21:19] <mookid> caching./
  948. # [21:20] <mookid> caching caching caching
  949. # [21:20] <JoePeck> mookid: its much easier to work with something you can modify easily, like the URI, then the header which goes along
  950. # [21:20] <mookid> JoePeck: no it's not
  951. # [21:20] <gsnedders_> mookid: But you need to vary caching based upon the Accept header then, which means you gain nothing by having the same URI for both.
  952. # [21:20] <JoePeck> would you suggest changing browsers to have 2 textfields, one for the URI and one for the preferred accepted mimetype?
  953. # [21:20] <mookid> ezyang: the best way to do that is an accept attribute in hypermedia tags
  954. # [21:21] * inimino makes popcorn
  955. # [21:21] <JoePeck> lol =)
  956. # [21:21] <mookid> so <a accept="application/json" href="/resource">
  957. # [21:21] <gsnedders_> mookid: But why do you want to override the browser default?
  958. # [21:21] <ezyang> ==gsnedders_
  959. # [21:21] <mookid> because it depends on the context
  960. # [21:21] <ezyang> Then the resources are not identical.
  961. # [21:21] <gsnedders_> ezyang: That doesn't follow.
  962. # [21:21] <JoePeck> I like mookid's accept attribute
  963. # [21:21] <mookid> WHATWG don't
  964. # [21:22] <JoePeck> but still
  965. # [21:22] <mookid> there's not a good enough use case
  966. # [21:22] <JoePeck> if you want to get something by typing a URI into your big honking location bar
  967. # [21:22] <JoePeck> what would you suggest then?
  968. # [21:22] <gsnedders_> mookid: You need a more specific use case.
  969. # [21:22] <mookid> I'd suggest if you're putting a URI into a browser you want HTML
  970. # [21:22] <mookid> :)
  971. # [21:22] <JoePeck> if not embedding the mime type into the URI (like .xml or .json) you're going to need 2 peices
  972. # [21:22] <mookid> but say..
  973. # [21:22] <mookid> I fancy pdf
  974. # [21:23] <gsnedders_> mookid: Just, "it depends on context" isn't very specific.
  975. # [21:23] <JoePeck> ahh, I don't like that =(
  976. # [21:23] <mookid> you don't like that if the resources are differnet
  977. # [21:23] <mookid> if the resources are different they need different URIs
  978. # [21:23] <mookid> if they are the same they need the same URI
  979. # [21:23] <JoePeck> gsnedders_: seems decent enough. If your application wants to to force the browser to interpret things in a certain way then you should be allowed to?
  980. # [21:23] <gsnedders_> mookid: Something like, "I want to make available a PDF representation of the document", is a lot more precise
  981. # [21:24] <mookid> gsnedders_: I gave you an example
  982. # [21:24] <gsnedders_> mookid: Where?
  983. # [21:24] <mookid> I have an application that has /resource I want to link to
  984. # [21:24] <gsnedders_> mookid: But why do you want to override the Accept header?
  985. # [21:24] <mookid> and on another HTML5 page I want to link to both the json and xml
  986. # [21:24] <mookid> I CANT DO THAT
  987. # [21:24] <mookid> WITHOUT AN ACCEPT ATTRIBUTE
  988. # [21:24] <JoePeck> whoa. calm down
  989. # [21:24] <gsnedders_> Why do you want to link to both?
  990. # [21:24] <inimino> mookid: then you have two resources, get over it
  991. # [21:25] <gsnedders_> To give a use-case, you need to answer that.
  992. # [21:25] <mookid> because I want to give my clients a hyperlink to both states
  993. # [21:25] <gsnedders_> Why?
  994. # [21:25] <ezyang> This is what I was trying to say previously.
  995. # [21:25] <mookid> why? because I do
  996. # [21:25] <mookid> that's irrelevant
  997. # [21:25] <gsnedders_> That's not a reason.
  998. # [21:25] <gsnedders_> Yes it is.
  999. # [21:25] <mookid> oh for fucks sake
  1000. # [21:25] <JoePeck> I actually think it is a good reason =/
  1001. # [21:25] <gsnedders_> Should we add everything that anyone asks for, "because they do"?
  1002. # [21:25] <JoePeck> I just can't come up with a good example of using it
  1003. # [21:26] <jgraham> This discussion was quite boring the first time you know
  1004. # [21:26] * Joins: dbaron (n=dbaron@nat/mozilla/x-f7651b8e29af1e3c)
  1005. # [21:26] <mookid> yeah
  1006. # [21:26] <ezyang> So, let's suppose the HTML and PDF example
  1007. # [21:26] <mookid> ^
  1008. # [21:26] <jgraham> This is like the lame sequel
  1009. # [21:26] <JoePeck> hahaha
  1010. # [21:26] <ezyang> I publish an HTML document with the intent of this being shown to people who are just browsing on the web.
  1011. # [21:26] <takkaria> ah, I thought it might go this way
  1012. # [21:26] <mookid> yeah well there's a good reason for that
  1013. # [21:26] <takkaria> I was hoping that mookid would just have continued spewing vitriol for a while
  1014. # [21:26] <mookid> it's important
  1015. # [21:26] <ezyang> And then the PDF document because it has better typogrpahy or can be sent to people or something
  1016. # [21:27] <gsnedders_> ezyang: Why not just use link@rel=alternate that works in existing, already deployed, UAs?
  1017. # [21:27] <JoePeck> ezyang: that sounded good to me
  1018. # [21:27] <ezyang> That's one solution.
  1019. # [21:27] <mookid> did you just suggest putting it in the URI?
  1020. # [21:27] * JohnResi1 is now known as JohnResig
  1021. # [21:27] <ezyang> gsnedders_ did not suggest puttin git in the URI
  1022. # [21:28] <JoePeck> he suggested changing the element alltogether? instead of <a> use <link> ?
  1023. # [21:28] <takkaria> let me suggest it
  1024. # [21:28] * Joins: atwilson (n=atwilson@74.125.59.1)
  1025. # [21:28] <jgraham> In practice the one-uri-maps-to-many-representions thing doesn't match how people think about this stuff
  1026. # [21:28] <JoePeck> isn't that semantically unacceptable (pardon the pun)?
  1027. # [21:28] <gsnedders_> ezyang: It does have that implication, actually
  1028. # [21:28] <takkaria> you should just call it document.html and document.pdf
  1029. # [21:28] <mookid> takkaria: then you don't understand the HTTP or URI spec and don't belong in this discussion
  1030. # [21:28] <JoePeck> takkaria: "could" not should
  1031. # [21:28] <jgraham> No one tries opening a URI that works in their web browser in their PDF viewer and expects to get a PDF back
  1032. # [21:28] <takkaria> mostly because it just works, and in this world-wide web of indifference, something that just works is pretty good
  1033. # [21:29] <ezyang> Now, my interpretation of the matter is that PDF has a distinct identity from the HTML document.
  1034. # [21:29] <JoePeck> mookid: I don't understand the harshness...
  1035. # [21:29] <mookid> because of the shit I went through last time
  1036. # [21:29] <mookid> and blatant ignorance
  1037. # [21:29] <ezyang> So, a more appropriate URI for it would be foo?publishable
  1038. # [21:29] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-c6f32d714bfc6d1b) (Read error: 104 (Connection reset by peer))
  1039. # [21:29] <ezyang> To carry the semantic meaning of this other resource.
  1040. # [21:30] <ezyang> And like it or not, "pdf" very concisely expresses the semantics you expect.
  1041. # [21:30] * Quits: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
  1042. # [21:30] <jgraham> JoePeck: mookid is somewhat bitter because he spent something like two days ranting about this before and people refused to accept that they were ignorant heathens
  1043. # [21:30] <JoePeck> lol, okay thanks for the context
  1044. # [21:30] <JoePeck> I see what he wants
  1045. # [21:30] <ezyang> A more reasonable use-case for negotiation is .jpg and .png, where joe user sees no difference between them.
  1046. # [21:30] <jgraham> and he was the only one who understood the web architecture
  1047. # [21:30] * Quits: cyingLunch (n=cying@70.90.171.153)
  1048. # [21:30] <JoePeck> but ultimately, I just see putting it the URI as much easier
  1049. # [21:30] <mookid> the main gain for sticking to single URIs for multiple representations of the same resource is the cache invalidation you get across all representations of a resource when you modify the resource
  1050. # [21:30] <Dashiva> Who started the time machine in here?
  1051. # [21:30] * Quits: archtech (n=stanv@83.228.56.37)
  1052. # [21:31] <mookid> I'm not the only one
  1053. # [21:31] <mookid> Philip` got it
  1054. # [21:31] <JoePeck> mookid: is there no way in HTTP
  1055. # [21:31] <mookid> it's pointless anyway there's HTTP functionality you are denying developpers on the basis that "you don't think it's really necessary"
  1056. # [21:31] <JoePeck> to make two URIs equivalent?
  1057. # [21:32] <mookid> no
  1058. # [21:32] * JoePeck puts up shield
  1059. # [21:32] <mookid> URIs are opaque
  1060. # [21:32] <mookid> good question :)
  1061. # [21:32] <jgraham> mookid: I get the idea. I get the fact that some people think it would be nice if things worked that way. I think it is impractical in reality
  1062. # [21:32] <mookid> what?!
  1063. # [21:32] <gsnedders_> mookid: Should we allow every single HTTP header to be set by the page?
  1064. # [21:32] <mookid> actually I dont think that's a bad idea
  1065. # [21:32] <Philip`> I don't entirely remember whether I got it
  1066. # [21:32] <Philip`> or what it even was
  1067. # [21:32] <JoePeck> so this could be solved in HTTP by making two URIs have an equivalent HTTP cache uri?
  1068. # [21:32] <Philip`> and whatever it was, I guess I didn't keep it
  1069. # [21:33] <mookid> JoePeck: that means you have to couple your caching mechanisms to your application
  1070. # [21:33] <mookid> it's inefficient and brittle
  1071. # [21:33] <JoePeck> no the HTTP client
  1072. # [21:33] <mookid> yeah again
  1073. # [21:33] <Dashiva> Philip`: Did you get it now, or the last time mookid was here?
  1074. # [21:33] <mookid> you can do that but it's coupling to your application
  1075. # [21:34] * gsnedders_ gets the idea, gets why people want multiple representations of a single URI, but thinks some things (like changing content-type) are impractical in the real world
  1076. # [21:34] <mookid> that's not your choice.
  1077. # [21:34] <mookid> just support the protocol
  1078. # [21:34] <JoePeck> mookid: is it? if you have /resource.html and /resource.pdf can you return and say these are both "/resource" and thus invalidate the cache when one changes
  1079. # [21:34] <Philip`> Dashiva: The last time
  1080. # [21:34] <gsnedders_> mookid: What should @accept do on protocols apart from HTTP?
  1081. # [21:34] <Philip`> Dashiva: I haven't bothered reading the conversation this time, since it seems exactly the same as before
  1082. # [21:36] <mookid> erm
  1083. # [21:36] <gsnedders_> mookid: Also, what else in HTML is specific to HTTP?
  1084. # [21:36] <mookid> what?
  1085. # [21:36] <mookid> POST?
  1086. # [21:36] * jgraham has no idea where the http protocol mandates that HTML pages should be able to change the browser headers via the DOM
  1087. # [21:36] <gsnedders_> mookid: HTML isn't tied to HTTP, by and large. form@method I guess is, but otherwise not
  1088. # [21:36] <mookid> jgraham: yeah bad luck it's not spelled out for you
  1089. # [21:36] <mookid> probably a bit much.
  1090. # [21:36] * Quits: ap (n=ap@nat/apple/x-d51eab098a917e7f) (Read error: 110 (Connection timed out))
  1091. # [21:36] <mookid> wouldn't worry about it too much
  1092. # [21:36] <Philip`> Dashiva: Also I'm distracted by watching pretty graphs and hoping Slashdot doesn't hurt my server
  1093. # [21:36] * takkaria puts up a Don't Feed The Troll sign (scare quotes implied) and goes to make risotto
  1094. # [21:36] <JoePeck> mookid: what about what I said before
  1095. # [21:36] * gsnedders_ goes to get washing
  1096. # [21:36] <jgraham> takkaria: What type of risotto?
  1097. # [21:36] <takkaria> jgraham: just a mushroom and pepper one, nothing fancy
  1098. # [21:36] <mookid> JoePeck: there's nothing stopping you introducing that kind of logic into your client or caches
  1099. # [21:36] <JoePeck> as it exists right now is that possible? Or does that mean the browser can only cache 1 representation of /resource at a time?
  1100. # [21:36] <mookid> but that's the opposite philosophy underlying HTTP
  1101. # [21:36] * jgraham is just enjoying a break from packing
  1102. # [21:37] <mookid> URIs are meant to be *opaque* which means that if they aren't the same - they aren't the same
  1103. # [21:37] <Dashiva> Have you covered the "multiple representations of the same URL confuses users" angle yet?
  1104. # [21:37] <mookid> nothing more complicated
  1105. # [21:37] <JoePeck> mookid: okay, I don't see what you mean this time. I've gotten all the REST (hahaha, my puns...)
  1106. # [21:37] <mookid> Dashiva: that is utterly irrelevant but thanks a bunch
  1107. # [21:37] <jgraham> Dashiva: Did that one
  1108. # [21:37] <JoePeck> hmm okay
  1109. # [21:37] <Dashiva> jgraham: Was it dismissed out of hand like last time?
  1110. # [21:37] <mookid> it's irrelevant
  1111. # [21:38] <mookid> it's not your descision
  1112. # [21:38] <JoePeck> I would say developers are not users =)
  1113. # [21:38] <JoePeck> we have to deal with this crap because we made it that way =)
  1114. # [21:38] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-b76fa1328c806a7f)
  1115. # [21:38] <JoePeck> if we can't make it usable to our users it was our own fault
  1116. # [21:38] <jgraham> Philip`: You are on slashdot?
  1117. # [21:38] * Joins: billmason (n=billmaso@ip94.unival.com)
  1118. # [21:39] <Dashiva> JoePeck: Regular users deal with URLs, though. They should be able to do so without having to learn about http black magic
  1119. # [21:39] <mookid> Dashiva: you don't know what you're tlaking about and even if you did it's not your place to decide for the world how that's dgoing to work
  1120. # [21:39] <JoePeck> well, lets say you put a URL into your browsers address bar
  1121. # [21:39] <JoePeck> and get back a popup saying
  1122. # [21:39] <Philip`> jgraham: Yes
  1123. # [21:39] <JoePeck> "Would you like this in HTML, PDF, or XML"
  1124. # [21:39] <mookid> haha
  1125. # [21:39] <jgraham> Philip`: Where?
  1126. # [21:40] <Philip`> jgraham: hence the worrying about it
  1127. # [21:40] <Philip`> jgraham: http://slashdot.org/
  1128. # [21:40] <jgraham> Philip`: I was hoping for something more specific
  1129. # [21:40] <Philip`> jgraham: http://games.slashdot.org/article.pl?sid=09/07/15/170217
  1130. # [21:41] <mookid> JoePeck: so yep there you go - we don't need an accept attribute because we can "just put it in the URI"
  1131. # [21:41] <JoePeck> mookid: well, I understand what you're going for. And actually I do agree with you. But I think too few people care about getting it right when you can just take the easy way out
  1132. # [21:41] <mookid> yup pretty much it
  1133. # [21:41] <mookid> just ignorance basically
  1134. # [21:41] <JoePeck> who cares if your cache has a .html and .pdf representation out of date
  1135. # [21:41] <JoePeck> is what it boils down to, for me
  1136. # [21:42] <JoePeck> mookid: cheers on sticking up for yourself though =)
  1137. # [21:42] <jgraham> Philip`: The game looks nice
  1138. # [21:42] <Dashiva> Between a few developers and all the users, the users get priority. That's just how it is.
  1139. # [21:43] <mookid> it's got nothing to do with that
  1140. # [21:43] <mookid> you're not a fucking gatekeeper
  1141. # [21:44] <mookid> excuse my language
  1142. # [21:44] <mookid> but that is the *most* pathetic response
  1143. # [21:44] <mookid> out of the lot
  1144. # [21:44] <JoePeck> Dashiva: how many users use FTP even though they don't know how its done under the hood. How many people know DNS is complicated yet it just works. Speaking of "it just works" Apple does magic with DNS to get Bonjour working and the User never knows. I think usability always has a solution (my 2¢)
  1145. # [21:44] <Dashiva> JoePeck: Usability is why we use URLs instead of contenet negotiation
  1146. # [21:44] <mookid> jesus
  1147. # [21:44] <Philip`> jgraham: It's quite a long way from being a decently playable game, though :-(
  1148. # [21:45] <JoePeck> Well, I'm going to stop here
  1149. # [21:45] <mookid> :)
  1150. # [21:45] <JoePeck> I could argue though =)
  1151. # [21:45] <mookid> now you might understand why I approach it the way I do
  1152. # [21:45] <Dashiva> Yeah, trolling always works. Keep it up.
  1153. # [21:45] <JoePeck> well, sorry, but I don't think yelling would ever open up someone elses mind like this debate would
  1154. # [21:46] <mookid> Dashiva: you're form of trolling is far more irritating
  1155. # [21:46] <JoePeck> need to have happen in order for the other side to get the "aha" moment
  1156. # [21:46] <Dashiva> mookid: Maybe one day you will sit down and consider the possibility that you might just be wrong. Just maybe.
  1157. # [21:46] <mookid> well I'm not
  1158. # [21:47] <JoePeck> ultimately I think you're right. They haven't given you a good reason that you aren't (cause you aren't)
  1159. # [21:47] <mookid> and I'm betting I've given this more though than you.
  1160. # [21:47] * Quits: ap_ (n=ap@17.246.19.81) (Remote closed the connection)
  1161. # [21:47] <mookid> since it's my proposal and everything
  1162. # [21:47] * Joins: ap (n=ap@nat/apple/x-bf676c7c165a7b6e)
  1163. # [21:47] <mookid> + you're primary reason for resistance (i.e. protecting *your* poor users) is pretty silly
  1164. # [21:48] <mookid> the crazy thing about this is that it doesnt stop you carrying on using the URI
  1165. # [21:48] <JoePeck> I said I was going to stop, and I will now =)
  1166. # [21:48] <JoePeck> cheers
  1167. # [21:48] <mookid> cheers Joe
  1168. # [21:48] <mookid> :)
  1169. # [21:49] * Quits: Spark^ (n=x@94-194-199-197.zone8.bethere.co.uk)
  1170. # [21:49] <mookid> only case I can see you getting pissy about is page refresh
  1171. # [21:50] <mookid> but if each page request is a state
  1172. # [21:50] <mookid> that includes all the headers
  1173. # [21:50] <mookid> then refresh should work fine
  1174. # [21:52] <mookid> but that is really my own problem - if you don't like it and want to use browser defaults and URI conneg then you can continue to and ignore the accept attribute all together
  1175. # [21:52] <mookid> there's no reason we can't do both together
  1176. # [21:54] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-b76fa1328c806a7f) (Read error: 104 (Connection reset by peer))
  1177. # [21:54] * Joins: cying (n=cying@70.90.171.153)
  1178. # [21:55] * Quits: maikmerten (n=maikmert@BAE20da.bae.pppool.de) (Remote closed the connection)
  1179. # [21:58] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) (Remote closed the connection)
  1180. # [21:58] <jgraham> mookid: As a piece of general advice, if you want to convince people of something, particularly something that they are sceptical of, being pissy doesn't help.
  1181. # [21:59] <jgraham> In fact quite the opposite
  1182. # [21:59] <mookid> yeah need a ciggy :)
  1183. # [21:59] * jgraham is aware he isn't saintly
  1184. # [22:00] <mookid> well sorry for being a nob head
  1185. # [22:00] <mookid> force of habit
  1186. # [22:01] <jgraham> Philip`: You may want to updat your bio
  1187. # [22:02] <mookid> the popular HTTP-centric API for java called JAX-RS only supports HTTP conneg
  1188. # [22:02] <mookid> so it's not just me :P
  1189. # [22:02] <Philip`> jgraham: It's only about five years out of date
  1190. # [22:03] <jgraham> Philip`: It misses out > 20% of your life
  1191. # [22:03] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  1192. # [22:03] * Quits: atwilson (n=atwilson@74.125.59.1)
  1193. # [22:04] * aroben is now known as aroben|afk
  1194. # [22:06] * Joins: othermaciej (n=mjs@17.246.17.223)
  1195. # [22:07] * Quits: othermaciej (n=mjs@17.246.17.223) (Client Quit)
  1196. # [22:08] * Joins: othermaciej (n=mjs@17.246.17.223)
  1197. # [22:12] * Joins: taf2__ (n=taf2@38.99.201.242)
  1198. # [22:15] * Philip` 's SVN server is currently doing about 30Mbit/s, which probably isn't a lot in absolute terms but it seems like quite a bit when you've scaled up from an average ~50kbit/s a few days ago
  1199. # [22:16] * Joins: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  1200. # [22:21] <mookid> you got pr0n on a svn server?
  1201. # [22:22] <Philip`> No
  1202. # [22:22] * aroben|afk is now known as aroben
  1203. # [22:25] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-7cf530064c557c69)
  1204. # [22:28] * Joins: roc (n=roc@121.74.180.224)
  1205. # [22:29] * Quits: pmuellr (n=pmuellr@nat/ibm/x-953a6346adf9cf65)
  1206. # [22:30] * Quits: taf2_ (n=taf2@38.99.201.242) (Read error: 113 (No route to host))
  1207. # [22:31] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  1208. # [22:37] * Quits: zdobersek1 (n=zan@cpe-92-37-76-123.dynamic.amis.net) ("Leaving.")
  1209. # [22:37] * Quits: webben (n=benh@nat/yahoo/x-4621a04377acbccd) (Read error: 60 (Operation timed out))
  1210. # [22:38] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-f7faac445a124e3c)
  1211. # [22:41] * Quits: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  1212. # [22:42] * Joins: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  1213. # [22:43] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
  1214. # [22:44] * Quits: sbublava (n=stephan@77.117.11.54.wireless.dyn.drei.com)
  1215. # [22:45] * Joins: weinig (n=weinig@nat/apple/x-e2b69ff700f3572b)
  1216. # [22:55] * Quits: sicking (n=chatzill@nat/mozilla/x-17a34457adae1c7a) (Remote closed the connection)
  1217. # [22:55] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  1218. # [23:06] * Joins: olliej_ (n=oliver@17.246.19.66)
  1219. # [23:07] * Joins: arun___ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net)
  1220. # [23:08] * Quits: arun__ (n=arun@adsl-75-36-190-133.dsl.pltn13.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  1221. # [23:14] * Joins: dglazkov (n=dglazkov@nat/google/x-e28711ff08354048)
  1222. # [23:14] * Quits: dglazkov (n=dglazkov@nat/google/x-e28711ff08354048) (Remote closed the connection)
  1223. # [23:17] * Joins: jorlow (n=jorlow@nat/google/x-75fce16f31f74eb7)
  1224. # [23:21] * Joins: dglazkov (n=dglazkov@nat/google/x-137b6a9d68f1fd02)
  1225. # [23:21] * Quits: dglazkov (n=dglazkov@nat/google/x-137b6a9d68f1fd02) (Remote closed the connection)
  1226. # [23:21] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  1227. # [23:23] * aroben is now known as aroben|meeting
  1228. # [23:29] <Hixie> what is the Window Modes spec?
  1229. # [23:30] * Joins: Sirisian (n=Sirisian@ppp-69-214-10-107.dsl.klmzmi.ameritech.net)
  1230. # [23:30] <Hixie> oh, a widgets spec
  1231. # [23:30] <Hixie> ok
  1232. # [23:30] <Hixie> (http://dev.w3.org/2006/waf/widgets-wm/Overview.src.html)
  1233. # [23:36] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  1234. # [23:38] * Quits: taf2__ (n=taf2@38.99.201.242)
  1235. # [23:40] * Quits: jorlow (n=jorlow@nat/google/x-75fce16f31f74eb7)
  1236. # [23:41] * Joins: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au)
  1237. # [23:42] * Joins: tantek (n=tantek@c-98-248-34-230.hsd1.ca.comcast.net)
  1238. # [23:43] * Joins: jorlow (n=jorlow@nat/google/x-8ee6a3a24378e011)
  1239. # [23:44] * Quits: Creap (n=Creap@vemod.brg.sgsnet.se) ("nu fkt")
  1240. # [23:45] * Quits: weinig (n=weinig@nat/apple/x-e2b69ff700f3572b)
  1241. # [23:46] * Joins: poe (n=poe@unaffiliated/xerox)
  1242. # [23:49] * Quits: othermaciej (n=mjs@17.246.17.223)
  1243. # [23:53] * Joins: othermaciej (n=mjs@17.203.15.242)
  1244. # [23:55] * Quits: jorlow (n=jorlow@nat/google/x-8ee6a3a24378e011) (Remote closed the connection)
  1245. # [23:55] * Joins: jorlow (n=jorlow@nat/google/x-378e51d576ed46b1)
  1246. # [23:56] * Joins: weinig (n=weinig@nat/apple/x-942b7011fa11b8da)
  1247. # [23:59] * Quits: olliej_ (n=oliver@17.246.19.66)
  1248. # [23:59] * Quits: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  1249. # Session Close: Thu Jul 16 00:00:00 2009

The end :)