/irc-logs / freenode / #whatwg / 2008-11-18 / end

Options:

  1. # Session Start: Tue Nov 18 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:10] * Quits: dave_levin (n=levin@72.14.227.1)
  4. # [00:10] * Joins: dave_levin (n=levin@72.14.227.1)
  5. # [00:20] * Quits: jwalden (n=waldo@guest-225.mountainview.mozilla.com) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  6. # [00:25] * Joins: aboodman7 (n=aboodman@nat/google/x-8cc765adff564f45)
  7. # [00:27] * Joins: jwalden_ (n=waldo@guest-225.mountainview.mozilla.com)
  8. # [00:27] * jwalden_ is now known as jwalden
  9. # [00:27] * Quits: aboodman6 (n=aboodman@nat/google/x-4f9de84abf826c07) (Read error: 110 (Connection timed out))
  10. # [00:40] * Joins: aboodman8 (n=aboodman@nat/google/x-6aafc06df2222347)
  11. # [00:40] * Quits: csarven (n=csarven@modemcable106.33-81-70.mc.videotron.ca) (Read error: 110 (Connection timed out))
  12. # [00:42] <Hixie> man i need to eat before i can reply to the crazy stuff on the w3c html lists
  13. # [00:42] * Quits: dglazkov (n=dglazkov@nat/google/x-d0e55309b5b8c1af)
  14. # [00:43] <Hixie> roy fielding in particular appears to live on a different planet
  15. # [00:45] <roc> the one email I read of his suggested that testing your HTML in a browser is bad because you might be tempted to make it less pure
  16. # [00:48] <jcranmer> bwahuh?
  17. # [00:48] <gavin> But now that Firefox is getting just as buggy and complex as
  18. # [00:48] <gavin> the other major browsers, they have no reason to switch at all.
  19. # [00:48] <gavin> Firefox usage hasn't increased since it decided to be no better
  20. # [00:48] <gavin> than the others.
  21. # [00:49] <gavin> that's an interesting assertion!
  22. # [00:49] <jcranmer> numerous factual errors in ther
  23. # [00:49] <jcranmer> there
  24. # [00:49] <jcranmer> shall I pull out the mandatory xkcd reference?
  25. # [00:50] <Lachy> jcranmer, xkcd references are always funny
  26. # [00:53] <Philip`> jcranmer: XKCD references are getting a bit tired now :-p
  27. # [00:53] * Joins: dglazkov (n=dglazkov@nat/google/x-9c0722db3b9f89e8)
  28. # [00:54] <jcranmer> it's the one where the character responds to trolls with long, multi-paragraph replies detailing why the poster should just die
  29. # [00:55] * Quits: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  30. # [00:55] * weinig|afk is now known as weinig
  31. # [00:55] * Quits: aboodman7 (n=aboodman@nat/google/x-8cc765adff564f45) (Read error: 110 (Connection timed out))
  32. # [00:57] <Lachy> http://xkcd.com/493/
  33. # [00:57] <Lachy> is that the one you meant?
  34. # [00:58] <jcranmer> no, not that one
  35. # [00:59] <Lachy> ok, then I can't find it
  36. # [01:00] <jcranmer> I'm not finding it either
  37. # [01:00] * Joins: nessy (n=nessy@124-171-61-96.dyn.iinet.net.au)
  38. # [01:00] <svl> This one: http://xkcd.com/406/ ?
  39. # [01:02] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  40. # [01:02] <jcranmer> yes!
  41. # [01:04] * Quits: dglazkov (n=dglazkov@nat/google/x-9c0722db3b9f89e8)
  42. # [01:06] * Quits: dave_levin (n=levin@72.14.227.1)
  43. # [01:09] * Joins: dave_levin (n=levin@72.14.227.1)
  44. # [01:11] * Quits: KevinMarks (n=KevinMar@207.47.11.2.static.nextweb.net) ("The computer fell asleep")
  45. # [01:18] * Joins: billyjackass (n=MikeSmit@58.157.21.205)
  46. # [01:25] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) (Read error: 110 (Connection timed out))
  47. # [01:28] <sicking> Hixie, ping
  48. # [01:28] <Hixie> wassup?
  49. # [01:30] <sicking> nevermind, shift-reload fixed it :)
  50. # [01:30] <sicking> though found a bug in workers spec:
  51. # [01:31] <sicking> "If the close event that this algorithm just added hasn't yet been dispatched, then abort the script currently running in the worker."
  52. # [01:32] <sicking> somewhere in there it should say to dispatch the close event i would have thought
  53. # [01:39] * Joins: aboodman9 (n=aboodman@nat/google/x-70ab3e416ba00960)
  54. # [01:43] * Joins: KevinMarks (n=KevinMar@nat/google/x-6a095c97e3c22335)
  55. # [01:51] <Hixie> sicking: send mail? (just to me if you want, you can just paste your irc comments)
  56. # [01:51] <Hixie> i'm about to be afk
  57. # [01:51] * Hixie sends his reply to Roy
  58. # [01:51] <Hixie> hopefully we'll get some clarity
  59. # [01:51] * Quits: weinig (n=weinig@nat/apple/x-b610abb4e4d33036)
  60. # [01:52] * sicking is about to give up on discussion with roy
  61. # [01:52] <sicking> or rather, i already have
  62. # [01:52] <sicking> the question is if that should mean giving up on the whole discussion with TAG or not
  63. # [01:52] <sicking> i hope it doesn't mean that
  64. # [01:53] <Hixie> i wish the tag people would give clear explanations of wtf they want
  65. # [01:53] <Hixie> they all seem to want something different
  66. # [01:53] <Hixie> yet they use the same terms
  67. # [01:53] <Hixie> and in half the cases, we already do what they want
  68. # [01:53] <Hixie> anyway
  69. # [01:53] <Hixie> afk
  70. # [01:53] * Joins: weinig (n=weinig@nat/apple/x-1f6178a815a611f7)
  71. # [01:54] * Quits: aboodman8 (n=aboodman@nat/google/x-6aafc06df2222347) (Read error: 110 (Connection timed out))
  72. # [01:58] <roc> wait, is Roy Fielding in TAG?
  73. # [01:58] <Philip`> http://junkyard.damowmow.com/284 sort of backs up the idea that most static content was written before IE6, if you assume that all pages with last-modified dates are probably static content (because nobody bothers generating that header in dynamic pages) and that ~52% counts as "most" and if you ignore the obvious bogosity that leads to 13% of pages being last modified in the future
  74. # [01:59] <Philip`> roc: http://www.w3.org/2001/tag/ says no
  75. # [02:00] <roc> ew
  76. # [02:00] <roc> phew
  77. # [02:01] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  78. # [02:11] * Joins: hdh (n=hdh@118.71.123.123)
  79. # [02:12] <sicking> wait, he's not in the TAG?
  80. # [02:12] <sicking> well then
  81. # [02:15] <othermaciej_> Philip`: any mod dates before 1990 are also probably false
  82. # [02:16] <othermaciej_> in fact probably most of the 1992s are false, given how few pages were on the web then
  83. # [02:16] * othermaciej_ is now known as othermaciej
  84. # [02:17] * Joins: othermaciej_ (n=mjs@17.203.15.159)
  85. # [02:21] * Quits: othermaciej (n=mjs@17.244.18.199) (Read error: 60 (Operation timed out))
  86. # [02:22] * othermaciej_ is now known as othermaciej
  87. # [02:27] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  88. # [02:30] * Hixie considers renaming HTML5 to Web5 and seeing what people think of _that_
  89. # [02:31] <roc> I recommend just "5"
  90. # [02:31] <roc> then people won't be able to complain about scope creep
  91. # [02:32] <Hixie> speaking of which, if we expand the scope we could include all of the DOM specs, CSS, HTTP, and XML into the same spec
  92. # [02:32] <Hixie> and SVG, too, while we're at it
  93. # [02:32] <Hixie> and MathML
  94. # [02:32] <Philip`> roc: Why bother with the version information at all? Just call it ""
  95. # [02:33] <roc> that's even harder to Google for
  96. # [02:33] <Hixie> that would solve that problem of multiple specs fragmenting the platform into different silos of technology
  97. # [02:33] * Parts: billmason (n=bmason@ip41.unival.com)
  98. # [02:35] * Quits: pergj (n=pergj@65.219.59.50) (Read error: 145 (Connection timed out))
  99. # [02:42] <sicking> Hixie, well, so seems like this Roy guy is just a troll that we should ignore
  100. # [02:42] <Hixie> he's one the apache developers and vocal on the http wg
  101. # [02:43] <Hixie> i don't disagree that he's a troll, or at least, that he has opinions so far removed from what i see as reality that it has not been productive to communicate with him in general.
  102. # [02:43] <sicking> yep
  103. # [02:44] <othermaciej> he is considered an Important Web Architecture Person
  104. # [02:44] <Hixie> by whom?
  105. # [02:44] <othermaciej> see, that's why I used the passive voice
  106. # [02:45] * sicking should do that more too
  107. # [02:45] <othermaciej> as a result of the acronym "REST" becoming popular, and him having invented it, many think therefore that he is an expert on Web architecture
  108. # [02:46] <Hixie> oh the REST nonsense is _his_ fault?!
  109. # [02:46] <Hixie> good to know
  110. # [02:46] <othermaciej> it was his PhD thesis
  111. # [02:46] <othermaciej> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
  112. # [02:47] <Hixie> i wish phd students were more like abarth and cjackson
  113. # [02:47] <Hixie> than roy and rburns :-)
  114. # [02:54] <nessy> we're not talking roy fielding, are we?
  115. # [02:54] <gavin> we are
  116. # [02:54] <blooberry> roy fielding? He's one of the main authors of the HTTP spec
  117. # [02:55] <nessy> http://www.ietf.org/rfc/rfc2396.txt
  118. # [02:55] <nessy> and of the original uri rfc
  119. # [02:55] <nessy> http://www.ietf.org/rfc/rfc2068.txt
  120. # [03:00] <Hixie> he's also the author of http://lists.w3.org/Archives/Public/public-html/2008Nov/0216.html
  121. # [03:03] * Quits: aboodman9 (n=aboodman@nat/google/x-70ab3e416ba00960) (Read error: 110 (Connection timed out))
  122. # [03:03] <roc> ah
  123. # [03:03] <roc> gah
  124. # [03:03] <Hixie> that e-mail is fractally wrong, as far as i can tell
  125. # [03:03] <Hixie> that is, the more you study its flaws, the more flaws you find
  126. # [03:04] <Hixie> http://lists.w3.org/Archives/Public/public-html/2008Nov/0219.html was my reply
  127. # [03:04] <roc> yeah
  128. # [03:05] * Quits: dave_levin (n=levin@72.14.227.1)
  129. # [03:07] <roc> I'd be worried about responding ... it seems impossible to address all flaws, and therefore one risks appearing to tacitly endorse them
  130. # [03:08] <Hixie> did i miss any flaws? :-)
  131. # [03:10] * Joins: dave_levin (n=levin@72.14.227.1)
  132. # [03:11] <roc> "the original Firefox team has moved on"
  133. # [03:11] <gavin> bz corrected that one
  134. # [03:11] <roc> "in a year or two, there will be other fresh ideas on browsing
  135. # [03:11] <roc> implementations. Such has been the case for over 15 years now"
  136. # [03:12] <Hixie> i didn't even know where to begin with those two
  137. # [03:12] <Hixie> bz addressed the first one
  138. # [03:12] <Hixie> the second... i didn't understand it
  139. # [03:12] <Hixie> i mean, it's not untrue
  140. # [03:12] <Hixie> and i couldn't tell what assumed disagreement made him want to specify it explicitly
  141. # [03:13] * Quits: KevinMarks (n=KevinMar@nat/google/x-6a095c97e3c22335) ("The computer fell asleep")
  142. # [03:13] * Joins: weinig_ (n=weinig@17.203.15.152)
  143. # [03:14] <roc> he seems to be talking about browser engines, and no new competitive browser engine has appeared in the last five years
  144. # [03:14] <othermaciej> I think WebKit is the most recent fresh idea in browser engines
  145. # [03:14] <othermaciej> that has achieved any serious level of market success
  146. # [03:14] <Hixie> it's the last one i know about for sure
  147. # [03:14] <roc> right
  148. # [03:14] <othermaciej> and certainly innovation in html parsing was not something we ever did or wanted to do
  149. # [03:15] <Hixie> and one major point of html5 is to help make competition easier
  150. # [03:15] <Hixie> so as to introduce more such browsers
  151. # [03:15] <Hixie> so who knows what he meant
  152. # [03:15] <roc> anyway, measuring the wrongness of Roy's position with great precision is not a good use of our time
  153. # [03:15] <Hixie> but it is somewhat entertaining
  154. # [03:16] <roc> it's as compelling as any car wreck
  155. # [03:16] <Hixie> (more seriously, i really do wish i could understand his position, as it would help us address his concerns and hopefully reduce the number of times he complains)
  156. # [03:18] * Quits: billyjackass (n=MikeSmit@58.157.21.205) (Read error: 110 (Connection timed out))
  157. # [03:20] * Joins: MikeSmith (n=MikeSmit@EM114-48-16-234.pool.e-mobile.ne.jp)
  158. # [03:21] <blooberry> has he brought forward any of these concerns in the past in the WG?
  159. # [03:21] <blooberry> or is he apparently having a Bad Day (eg: he has always had some disagreements and something finally made him "snap")
  160. # [03:22] <Hixie> he's always complaining about html5
  161. # [03:27] * Joins: aboodman9 (n=aboodman@nat/google/x-be036dbc16d62261)
  162. # [03:27] <roc> I think his position is quite clear. He has some false assumptions about Web browsers and Web developers, which you identified, and everything else flows from there.
  163. # [03:28] * Quits: weinig (n=weinig@nat/apple/x-1f6178a815a611f7) (Read error: 110 (Connection timed out))
  164. # [03:29] <Hixie> well hopefully we can correct those mistaken assumptions
  165. # [03:29] <roc> I'll bet money you can't
  166. # [03:32] <roc> you may impact lurkers who share some of those unexamined assumptions, though, so play on
  167. # [03:40] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  168. # [03:43] * Quits: MikeSmith (n=MikeSmit@EM114-48-16-234.pool.e-mobile.ne.jp) ("sex break")
  169. # [03:43] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  170. # [03:45] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  171. # [04:01] * Quits: dave_levin (n=levin@72.14.227.1)
  172. # [04:07] * Joins: smerp (n=smerp@cpe-066-057-061-202.nc.res.rr.com)
  173. # [04:10] * Joins: smerp_ (n=smerp@66.192.95.199)
  174. # [04:16] * aboodman9 is now known as aboodman2
  175. # [04:18] * Quits: dimich (n=dimich@72.14.227.1) (Read error: 110 (Connection timed out))
  176. # [04:24] <Hixie> apparently i ignore feedback
  177. # [04:24] <Hixie> wow
  178. # [04:24] <Hixie> i wonder what these thousands of e-mails i've been replying to have been, if not feedback
  179. # [04:27] * Joins: MikeSmith (n=MikeSmit@dhcp-246-124.mag.keio.ac.jp)
  180. # [04:28] * Quits: smerp (n=smerp@cpe-066-057-061-202.nc.res.rr.com) (Read error: 110 (Connection timed out))
  181. # [04:37] <Hixie> hmm
  182. # [04:37] <Hixie> window.resolveURL('test.html') or window.location.resolveURL('test.html') ?
  183. # [04:37] <Hixie> the former has more chance of clashing with scripts
  184. # [04:38] <Hixie> the latter might mislead authors when there's a <base> around
  185. # [04:38] <sicking> othermaciej, ping
  186. # [04:38] <othermaciej> sicking: yo
  187. # [04:38] * othermaciej has a half-composed reply to Roy that he thinks better of
  188. # [04:38] <sicking> othermaciej, do you know where the ECMA spec for JSON lives?
  189. # [04:39] <othermaciej> sicking: you mean for the soon-to-be-standard JSON parsing API, or for the syntax of JSON?
  190. # [04:39] <sicking> othermaciej, both actually
  191. # [04:39] <othermaciej> sicking: the former is in ES3.1 drafts (see es3.x-discuss mailing list for latest draft link) and the latter is I believe an RFC
  192. # [04:39] <sicking> othermaciej, the latter more so
  193. # [04:40] <othermaciej> (IETF RFC)
  194. # [04:40] <jcranmer> http://www.ietf.org/rfc/rfc4627.txt
  195. # [04:40] <sicking> thanks!
  196. # [04:41] <jcranmer> thank awesomebar
  197. # [04:41] <sicking> othermaciej, is there a reason why it requires you to quote all attribute names? With double-quotes none the less?
  198. # [04:41] <sicking> othermaciej, took me quite a while to figure that one out
  199. # [04:42] <othermaciej> sicking: I am at a loss to explain any of the details of the JSON sytntax
  200. # [04:42] <Hixie> (fyi, s/none the less/no less/, probably)
  201. # [04:42] <Hixie> JSON syntax is Doug Crockford's brainchild
  202. # [04:42] <Hixie> as i understand it
  203. # [04:43] <sicking> bah, bummer
  204. # [04:43] <Hixie> ok window.location.resolveURL('foo'); will resolve the url 'foo' to an absolute URL
  205. # [04:43] <Hixie> then you can use that to pass the URL to a worker
  206. # [04:43] <Hixie> any objections?
  207. # [04:44] <Hixie> (sicking?)
  208. # [04:44] <sicking> Hixie, hmm.. the base thing seems like a problem :(
  209. # [04:44] <sicking> Hixie, or will that resolve against the base?
  210. # [04:44] <Hixie> it'll resolve against the base
  211. # [04:44] <Hixie> which is mildly confusing since Location doesn't have the base
  212. # [04:44] <Hixie> but oh well
  213. # [04:44] <sicking> right
  214. # [04:44] <Hixie> i'm scared of putting it on Window
  215. # [04:45] <sicking> don't feel strongly either way
  216. # [04:45] <sicking> right
  217. # [04:45] <Hixie> k
  218. # [04:45] <Hixie> well we'll try that
  219. # [04:45] <Hixie> and see who whines :-)
  220. # [04:47] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  221. # [04:48] <sicking> othermaciej, so i'd really like to be able to pass primitive values, such as 0 and false, through JSON.stringify/JSON.parse
  222. # [04:48] <sicking> othermaciej, i suppose that's not likely to happen at this point, right?
  223. # [04:48] <othermaciej> sicking: I haven't read up on what is spec'd for JSON
  224. # [04:48] <othermaciej> sicking: I think there is a desire to remain compatible with json2.js unless there is a major reason to do otherwise
  225. # [04:48] * Joins: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  226. # [04:49] <sicking> othermaciej, ok
  227. # [04:49] <othermaciej> I think the root of a JSON structure has to be an array or object
  228. # [04:49] <othermaciej> so the strings "0" or "false" would not be valid JSON
  229. # [04:49] <sicking> othermaciej, the reason is that I want to allow JSON "values" to be passed through a bunch of the DOM APIs, such as postMessage or pushState
  230. # [04:50] <sicking> othermaciej, yeah, it seemed like that was what our JSON.stringify implementation accepted
  231. # [04:50] <othermaciej> sicking: that does seem like a good idea in general
  232. # [04:50] <jcranmer> A JSON text is a serialized object or array.
  233. # [04:50] <sicking> othermaciej, how so?
  234. # [04:50] <othermaciej> sicking: your idea
  235. # [04:50] <Hixie> sicking: i think when we define what is passed through postMessage(), we'll use something that is wider than JSON
  236. # [04:50] <othermaciej> " I want to allow JSON "values" to be passed through a bunch of the DOM APIs, such as postMessage or pushState"
  237. # [04:50] <othermaciej> I think you would want to define an extended JSON that can be either a JS primitive value, or a JSON-compatible object
  238. # [04:50] <sicking> i know what i said :) i was wondering why you didn't think its a good idea
  239. # [04:51] <othermaciej> I do think it is a good idea!
  240. # [04:51] <othermaciej> I said: "sicking: that does seem like a good idea in general"
  241. # [04:51] <sicking> oh :)
  242. # [04:51] <Hixie> man, you're so negative
  243. # [04:51] <Hixie> always saying ideas are bad :-P
  244. # [04:51] <sicking> what can i say
  245. # [04:51] <sicking> i hate stuff
  246. # [04:51] <Hixie> i meant maciej :-P
  247. # [04:51] <othermaciej> clearly it is what people expect of me
  248. # [04:51] <jcranmer> A JSON parser MAY accept non-JSON forms or extensions.
  249. # [04:52] <Hixie> go interoperability
  250. # [04:52] <jcranmer> I'd be surprised to find a JSON parser that couldn't parse the string "0"
  251. # [04:52] <othermaciej> sicking: anyway, I would make postMessage and pushState eventually use a string conversion algorithm which accepts either primitives or JSON-compatible objects, and deserialize on the other end
  252. # [04:53] <othermaciej> sicking: actually I guess it is not necessary per spec for it to even stringify; the implementation could serialize and deserialize however it wants
  253. # [04:53] <sicking> right, that's what bens patch does
  254. # [04:53] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  255. # [04:53] <sicking> (well, it does stringify, though that's not technically needed)
  256. # [04:54] <Hixie> right, i would just define a set of things that must be supported, and everything else would just be stringified
  257. # [04:54] <Hixie> not sure how to define it yet
  258. # [04:54] <Hixie> it's one reason i haven't specced it yet
  259. # [04:55] <othermaciej> one question is what to do with non-JSON-compatible object graphs
  260. # [04:55] <othermaciej> otherWin.postMessage({"a": 1, "b": 2, "c": document.body})
  261. # [04:56] <othermaciej> I can think of at least 3 reasonable things to do
  262. # [04:56] <othermaciej> gotta head home
  263. # [04:56] <othermaciej> later folks
  264. # [04:59] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  265. # [05:01] <Hixie> null, exception, stringify?
  266. # [05:01] * Quits: roc (n=roc@202.0.36.64)
  267. # [05:01] <othermaciej> null was not one I thought of
  268. # [05:01] <othermaciej> the two different ones were stringify generically at top level, vs stringify at JSON-compatibility failure point
  269. # [05:02] <othermaciej> so [object Object]
  270. # [05:02] <othermaciej> or something with [object HTMLBodyElement] somewhere in the middle
  271. # [05:02] <othermaciej> ciao
  272. # [05:02] * Quits: othermaciej (n=mjs@17.203.15.159)
  273. # [05:03] <deltab> sicking: quoting names mean that there doesn't have to be a syntax rule for identifiers
  274. # [05:05] <sicking> deltab, how do you mean? {this: 0} should parse as {"this": 0} no?
  275. # [05:07] <deltab> yes, but {"foo:bar": 0} isn't equivalent to {foo:bar: 0}
  276. # [05:08] <sicking> sure
  277. # [05:08] <sicking> there can be parse errors
  278. # [05:08] * Quits: weinig_ (n=weinig@17.203.15.152)
  279. # [05:09] <sicking> anyway, the discussion is moot since a decision has been made
  280. # [05:09] <deltab> I just thought you'd like to know why
  281. # [05:09] <sicking> sure, if you know why i'm curious :)
  282. # [05:10] <deltab> I don't
  283. # [05:10] <sicking> ah :)
  284. # [05:10] * Quits: dglazkov_ (n=dglazkov@72.14.224.1)
  285. # [05:10] <deltab> I guess you're writing something
  286. # [05:11] * Joins: pergj (n=pergj@dhcp206-59-244-232.ssb.sjc.wayport.net)
  287. # [05:11] <sicking> deltab, http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017276.html
  288. # [05:11] <sicking> deltab, though unrelated to the quoting issue
  289. # [05:12] <sicking> deltab, the quoting issue came up because it took me about 5 times as long to test out the JSON support
  290. # [05:13] <Hixie> sicking: btw i definitely agree with the need to do this, and will be adding it in due course, though i'd really like to see more stability in those sections and implementation experience (thanks for sending this!) before i spec it out formally
  291. # [05:13] <sicking> Hixie, sounds good. Mostly wanted to check that people wasn't gonna get upset if we added support
  292. # [05:14] <Hixie> i don't think anyone thinks it's a bad idea, no. certainly i haven't heard anyone say it's a bad idea, and i've been floating around for a while.
  293. # [05:14] <Hixie> i'm a little apprehensive about how i'm gonna spec it, but we'll see
  294. # [05:17] * Joins: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net)
  295. # [05:18] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Connection timed out)
  296. # [05:30] <sicking> aboodman: you gotta stop top-quoting ;)
  297. # [05:31] <jcranmer> A: Because I said so.
  298. # [05:31] <jcranmer> Q: Why?
  299. # [05:32] <aboodman2> sicking: I usually bottom quote, not sure what was with me today.
  300. # [05:32] <sicking> aboodman2, cool :)
  301. # [05:32] <aboodman2> sicking: you top quoted too
  302. # [05:32] <aboodman2> sicking: were you just sticking to my convention or something?
  303. # [05:33] <aboodman2> I suppose I am getting lazy.
  304. # [05:33] <sicking> yeah, it's hard to reply to a top-quoted mail while bottom-quoting
  305. # [05:33] <sicking> i modified someone elses mail to bottom quote the other day and it seemed a bit rude
  306. # [05:33] <sicking> so i'll just be rude in here instead :)
  307. # [05:33] <jcranmer> bah, it's the internt
  308. # [05:33] <jcranmer> er, Internet
  309. # [05:34] <jcranmer> everything you're say is expected to be mangled and taken out of context
  310. # [05:34] * sicking slaps jcranmer with a wet salmon
  311. # [05:34] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  312. # [05:34] <sicking> oh, sorry, i thought your point was that it's Internet, you're supposed to be rude :)
  313. # [05:34] <aboodman2> sicking: meh
  314. # [05:35] <jcranmer> oh, goodness gracious, no!
  315. # [05:35] <jcranmer> no one would be surprised if you were rude, though
  316. # [05:38] * sicking slaps jcranmer with a pickled herring
  317. # [05:38] * jcranmer eats the pickled herring
  318. # [05:38] <sicking> care for some sour-cream with it?
  319. # [05:39] <jcranmer> no, just ketchup
  320. # [05:41] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  321. # [05:42] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  322. # [05:43] * Quits: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Read error: 110 (Connection timed out))
  323. # [05:49] * Quits: smerp_ (n=smerp@66.192.95.199)
  324. # [05:52] * Joins: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net)
  325. # [05:56] * Quits: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net) (Client Quit)
  326. # [05:57] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  327. # [06:00] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  328. # [06:01] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  329. # [06:29] * Joins: aboodman3 (n=aboodman@67.218.105.40)
  330. # [06:31] * Quits: aboodman2 (n=aboodman@nat/google/x-be036dbc16d62261) (Read error: 110 (Connection timed out))
  331. # [06:31] * Joins: aboodman4 (n=aboodman@67.218.105.40)
  332. # [06:37] * Quits: dglazkov_ (n=dglazkov@72.14.224.1)
  333. # [06:40] * Quits: aboodman3 (n=aboodman@67.218.105.40) (Read error: 145 (Connection timed out))
  334. # [06:44] * Quits: doublec (n=chris@202.0.36.64) ("Leaving")
  335. # [06:48] <Hixie> sicking: i reformat and fix spelling and grammar mistakes in people's e-mails all the time :-)
  336. # [06:50] <sicking> Hixie, i'm a nicer guy than you :)
  337. # [06:50] * sicking continues his new embrace of the way of the Internet to be rude
  338. # [06:50] * Joins: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net)
  339. # [06:50] <Hixie> sicking: :-P
  340. # [06:51] * Quits: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net) (Client Quit)
  341. # [06:51] <sicking> sorry, in a grumpy mood today, backporting stupid patches to old stupid releases
  342. # [06:51] * aboodman4 is now known as aboodman2
  343. # [06:51] <aboodman2> the irc protocl makes me grumpy
  344. # [06:51] <aboodman2> protocol*
  345. # [06:52] * Joins: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net)
  346. # [06:52] * Quits: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net) (Client Quit)
  347. # [06:53] * Joins: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net)
  348. # [06:54] * Quits: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  349. # [06:56] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  350. # [06:57] * Joins: eric_carlson_ (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  351. # [06:58] * Quits: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Read error: 54 (Connection reset by peer))
  352. # [06:59] * Joins: dave_levin_ (n=levin@72.14.224.1)
  353. # [06:59] * Quits: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net) ("g'night")
  354. # [07:15] * Quits: dave_levin (n=levin@c-98-203-247-78.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  355. # [07:20] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  356. # [07:21] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  357. # [07:27] * Quits: aboodman2 (n=aboodman@67.218.105.40) (Read error: 110 (Connection timed out))
  358. # [07:27] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  359. # [07:30] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  360. # [07:54] * Joins: maikmerten (n=merten@129.217.26.195)
  361. # [07:56] * Joins: ap (n=ap@195.239.126.11)
  362. # [08:08] * Joins: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  363. # [08:27] * Joins: mpt (n=mpt@nat/canonical/x-02d93a34e49388d4)
  364. # [08:31] * Joins: heycam (n=cam@210-84-56-87.dyn.iinet.net.au)
  365. # [08:32] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  366. # [08:34] <Hixie> hm the content model of <menu> is all wrong
  367. # [08:36] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  368. # [08:42] * Joins: roc (n=roc@121-72-175-254.dsl.telstraclear.net)
  369. # [08:44] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  370. # [08:58] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  371. # [09:00] * Quits: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  372. # [09:06] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  373. # [09:11] * Joins: pesl (n=retep@procurios.xs4all.nl)
  374. # [09:18] * Joins: ap_ (n=ap@195.239.126.11)
  375. # [09:24] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  376. # [09:26] * Joins: aaronlev_ (n=chatzill@e180226050.adsl.alicedsl.de)
  377. # [09:26] * aaronlev_ is now known as aaronlev
  378. # [09:26] * Quits: ap (n=ap@195.239.126.11) (Nick collision from services.)
  379. # [09:26] * ap_ is now known as ap
  380. # [09:44] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  381. # [09:44] * Joins: ap_ (n=ap@195.239.126.10)
  382. # [09:46] * Quits: ap (n=ap@195.239.126.11) (Read error: 60 (Operation timed out))
  383. # [09:46] * ap_ is now known as ap
  384. # [09:55] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  385. # [09:55] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  386. # [10:02] * Joins: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net)
  387. # [10:10] * Quits: sverrej (n=sverrej@cm-84.208.153.202.getinternet.no) (Read error: 113 (No route to host))
  388. # [10:19] <hsivonen> As far as I can tell, the JSON practice towards errors in Draconianness
  389. # [10:19] <hsivonen> except when its not
  390. # [10:19] <hsivonen> which leads to interop trouble
  391. # [10:19] * Quits: jwalden (n=waldo@guest-225.mountainview.mozilla.com) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  392. # [10:20] <Hixie> json is a mess
  393. # [10:22] <hsivonen> s/in/is/
  394. # [10:25] <hsivonen> Hixie: do you have document.write test cases that I should walk through both with the spec and with the idea I sent to the list?
  395. # [10:26] <Philip`> Has anyone tested IE8's JSON implementation to see how spec-compliant it is?
  396. # [10:26] <Hixie> hsivonen: don't think so
  397. # [10:27] <hsivonen> Hixie: ok. did what I sent to the list look superficially reasonable?
  398. # [10:28] <hsivonen> I'm expecting that the following properties are true of the spec:
  399. # [10:28] <hsivonen> 1) If a given script has not document.written before, the insertion point is where the tokenization position is
  400. # [10:29] <hsivonen> 2) When the tokenizer reaches an insertion point, nothing can write to that insertion point any longer
  401. # [10:29] <hsivonen> (or if something document.writes to that point, it degenerates into case #1)
  402. # [10:29] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  403. # [10:29] <Hixie> i cannot offhand tell if the implementation strategy you describe is equivalent to the spec
  404. # [10:29] * Quits: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
  405. # [10:30] <hsivonen> Hixie: OK. I guess I'll try it and see if there are issues that I didn't consider
  406. # [10:30] <hsivonen> Hixie: thanks
  407. # [10:31] <Hixie> i'd just make an object that exposes a string that represents the concept in the spec, personally
  408. # [10:31] <Hixie> i.e. an object that has an insertion point and a current position
  409. # [10:31] <Hixie> and that keeps track of what strings have been inserted where
  410. # [10:32] <Hixie> so that it is transparent to the reader
  411. # [10:32] <Hixie> it could even do the CRLF expansion stuff transparently
  412. # [10:33] <hsivonen> doing CRLF expansion strictly before tokenization seems inefficient
  413. # [10:33] <Hixie> yeah this might not be the most efficient solution, certainly
  414. # [10:34] <hsivonen> Considering that HTML parsing is perf critical to a browser, I think I'm going to tolerate abstraction leaks here
  415. # [10:34] <hsivonen> or rather, not having a proper abstraction for the UTF-16 stream at all
  416. # [10:35] <hsivonen> Specifically, once the Unicode decoder has written data to a range of memory, I don't want to move that data
  417. # [10:36] <Hixie> yeah i was going to say that in general i advise against premature optimisation but in this case it may be a case where we know that that part will need optimising anyway
  418. # [10:42] * Joins: jwalden_ (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net)
  419. # [10:42] * jwalden_ is now known as jwalden
  420. # [10:42] * Joins: tthorsen (n=tommy@home.kvaleberg.no)
  421. # [10:47] * Quits: MikeSmith (n=MikeSmit@dhcp-246-124.mag.keio.ac.jp) ("sex break")
  422. # [10:59] <hsivonen> clearly, Roy Fielding has a different view of who are experts in the Web standards community
  423. # [11:00] <jwalden> sicking: so one reason, I think, is that JSON is then also a subset of Python syntax, but I don't know if that's an actual reason; simplicity might be, tho (same way XML requires attributes be quoted or something)
  424. # [11:01] <Philip`> jwalden: It's not a subset - Python doesn't have true and false and null
  425. # [11:02] <hsivonen> Philip`: but one could do
  426. # [11:02] <hsivonen> true = 1
  427. # [11:02] <hsivonen> false = 0
  428. # [11:02] <hsivonen> null = None
  429. # [11:02] <hsivonen> as boilerplate
  430. # [11:03] <hsivonen> although in practice, parsing JSON using anything but a dedicated JSON parser leads to interop problems
  431. # [11:03] <Philip`> Also Python doesn't seem to understand "\u1234"
  432. # [11:03] <Philip`> (since you have to do u"\u1234" instead)
  433. # [11:03] <hsivonen> good point
  434. # [11:06] <Philip`> That's why JSON is dangerous - people think they can parse it easily just by twiddling a few bits and using "eval" in their favourite language, and it sorts of works but isn't quite interoperable
  435. # [11:06] * Joins: ROBOd (n=robod@89.122.216.38)
  436. # [11:07] <hsivonen> I wonder what classes of products Roy has in mind that can't comply to HTML5 as written
  437. # [11:07] <jwalden> er, hm
  438. # [11:07] * hsivonen avoids getting involved in the thread, though
  439. # [11:07] <jwalden> I could have sworn I read somewhere about that being true
  440. # [11:09] <Philip`> Oh, and even if Python did understand "\u1234" then it probably wouldn't understand "\ud800\udc00 etc" for non-BMP characters
  441. # [11:12] <Philip`> "Those [authoring] tools are developed based on language specifications and generic templates, not by "designing for current browsers" ..." - is he failing to consider that people actually design and develop and extend the markup templates and fragments generated by those tools, and that's basically the same as hand authoring?
  442. # [11:14] <Philip`> People write e.g. blog templates by writing some HTML in a text editor, telling the blog software to use it, then repeatedly testing it in their current browser and tweaking it until it looks alright
  443. # [11:15] <Philip`> and when we talk about "authors" we mean mainly those people (as far as I'm aware) rather than the people writing the textual content
  444. # [11:19] * Hixie replies to roy
  445. # [11:23] <Hixie> ok bed time
  446. # [11:23] <Hixie> nn
  447. # [11:24] <roc> you made me look, and now I'm unhappy again
  448. # [11:25] <Hixie> aww
  449. # [11:25] <Hixie> i'm sorry
  450. # [11:26] <roc> people who say things like "a resident memory size of 141M is ridiculous", with no context at all, are very annoying
  451. # [11:27] <hsivonen> I'm sure there's a non-contrived context where Apache 2 takes 141 MB of resident memory
  452. # [11:28] <Hixie> my apache instance is taking upwards of half a gig
  453. # [11:28] <Hixie> 20mb per thread
  454. # [11:28] <Hixie> which is pretty insane too
  455. # [11:28] <Philip`> Resident, and not shared etc?
  456. # [11:29] * Philip` tends not to worry until Opera's using ~1GB of memory, and then he restarts it and carries on
  457. # [11:30] <Hixie> my machine as a whole has 0kb swapped out, and about all that's running on it is apache
  458. # [11:30] <Hixie> and the total amount used is about 0.7gb
  459. # [11:30] <Hixie> so
  460. # [11:31] * Philip` likes writing games, because you can get away with using half a gigabyte of RAM and nobody minds at all
  461. # [11:37] * Joins: hallvors (n=hallvord@cm-84.208.78.204.getinternet.no)
  462. # [11:47] * Joins: MikeSmith (n=MikeSmit@EM114-48-38-110.pool.e-mobile.ne.jp)
  463. # [11:53] * ap is now known as ap|brb
  464. # [11:55] * Quits: roc (n=roc@121-72-175-254.dsl.telstraclear.net)
  465. # [11:56] * ap|brb is now known as ap
  466. # [12:08] * Joins: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  467. # [12:08] <yecril71> If an URI should mark a resource regardless of its form,
  468. # [12:09] <yecril71> the decision on which form to use should be entirely on the user agent.
  469. # [12:09] <yecril71> The author should have no say here.
  470. # [12:12] <yecril71> PUT and DELETE are outside the scope of user agents.
  471. # [12:12] <yecril71> User agents are for viewing content, not for publishing it.
  472. # [12:13] <yecril71> (except in the limited case of POST)
  473. # [12:16] <yecril71> An embedded device’s resources can be exhausted with setTimeout
  474. # [12:16] <yecril71> just as they can be exhausted with time update.
  475. # [12:17] <yecril71> If the user encounters a rogue site that does bad things to the device,
  476. # [12:17] <yecril71> he can just blacklist it so that it cannot do so any more.
  477. # [12:20] <yecril71> Oops, sorry, I was just repeating Adrian (unintentionally).
  478. # [12:25] <Philip`> URIs were a good idea because you could refer directly to concrete things - instead of saying "download this pretty document via FTP on example.org in /pub/stuff.pdf" you could say "download ftp://example.org/pub/stuff.pdf". If you have to start saying "download http://example.org/pub/stuff using a PDF reader or with Accept:application/pdf" then that seems like a step in the wrong direction
  479. # [12:29] <hsivonen> Hixie: do you remember if Gecko has the kind of cache-related document.write behavior that we want to avoid with HTML5?
  480. # [12:32] * Joins: othermaciej_ (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  481. # [12:32] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  482. # [12:44] * Quits: blooberry (n=brian@c-76-126-199-19.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  483. # [12:46] <hallvors> URIs are a reasonable compromise between computers and humans
  484. # [13:03] * Quits: ap (n=ap@195.239.126.10)
  485. # [13:03] <yecril71> Resources can have various representations, and the user is free to choose whatever representation suits him best.
  486. # [13:04] * Joins: ap (n=ap@195.239.126.11)
  487. # [13:04] * Quits: ap (n=ap@195.239.126.11) (Remote closed the connection)
  488. # [13:04] <yecril71> So I would rather say "Download this pretty document via HTML;
  489. # [13:04] <yecril71> oops, HTTP;
  490. # [13:04] * Joins: ap (n=ap@195.239.126.11)
  491. # [13:05] <yecril71> the server will deliver your preferred format."
  492. # [13:05] <hsivonen> yecril71: with conneg, the user doesn't know what's available
  493. # [13:06] <yecril71> Well, if the preferred format is unavailable, the server can return the next preferred one.
  494. # [13:06] <yecril71> Why is the information of what is available needed?
  495. # [13:07] <hsivonen> yecril71: the automation is not needed
  496. # [13:07] <hsivonen> and the particular kind of automation suggested sucks
  497. # [13:11] <hsivonen> Somehow I'm not surprised: http://twitter.com/waka/statuses/1011080251
  498. # [13:15] * Quits: MikeSmith (n=MikeSmit@EM114-48-38-110.pool.e-mobile.ne.jp) ("sex break")
  499. # [13:20] <Lachy> oh crap. Dmitry Turin has emailed me off list now about HTML6 :-(
  500. # [13:20] * Lachy will not respond
  501. # [13:27] * hallvors responds, realising part of the reason he reads public-html is that weird people are interesting :-p
  502. # [13:27] <hallvors> (I just said "noone will reply to that question because it's impossible to estimate and commercially sensitive information")
  503. # [13:28] <Lachy> hallvors, did Dmitry email you too?
  504. # [13:29] <Lachy> I would have told him that no-one is interested in implementing HTML6 at all, but he's on my do-not-respond list
  505. # [13:29] * hsivonen guesses he emailed all Opera and Mozilla reps to the HTML WG
  506. # [13:30] <hallvors> no, just saw him on public-html. I'll see if that bait makes him too much of a nuisance. :-p
  507. # [13:30] <Philip`> yecril71: The hypothetical document is only pretty in PDF; the HTML one has ugly fonts and bad layout, which is why I was telling the hypothetical person to download the PDF
  508. # [13:31] <hallvors> yecril71: what type of content I think I'm getting is important to me. If I can choose between a .html and a .pdf link, I am in control. Content negotiation and extension-free links actually take that control away from the user.
  509. # [13:34] * Philip` prefers to think about "things" rather than about "resources" and "representations", and considers a PDF document to be a thing, and wants to have a simple uniform way to refer to such things, because then the world is nice and simple and makes sense
  510. # [13:34] * Quits: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) ("Leaving")
  511. # [13:34] * Joins: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl)
  512. # [13:35] * Joins: ap_ (n=ap@195.239.126.12)
  513. # [13:36] * hsivonen sees http://html60.euro.ru/site/html60/
  514. # [13:37] <yecril71> You can choose between .html and .pdf.
  515. # [13:37] <yecril71> You achieve that goal by setting your preferences.
  516. # [13:37] <yecril71> If the document in HTML is unusable, it should not be there in the first place.
  517. # [13:41] * Joins: webben (n=webben@nat/yahoo/x-158770da8ff656d6)
  518. # [13:42] * Quits: ap (n=ap@195.239.126.11) (Read error: 145 (Connection timed out))
  519. # [13:47] * Joins: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  520. # [13:49] * ap_ is now known as ap
  521. # [13:58] <hallvors> yecril71: I do NOT want to reconfigure my browser each time I need a specific variant of a resource. That is a rather silly suggestion. I happen to know how to do it (which most users don't) and even then it's a bad idea.
  522. # [13:59] <mookid> hey hey! someone else understands HTTP!
  523. # [13:59] <mookid> rejoice!
  524. # [14:00] <mookid> Philip`: read what I just posted to the mailing list - that approach breaks caching
  525. # [14:01] <mookid> if you have a seperate URL for each representation and you update one of those URLs
  526. # [14:01] <mookid> then caching will only account for the update to the one specific representation
  527. # [14:01] <mookid> the others will be considered unchanged
  528. # [14:01] <BenMillard> mookid, what do you do for the websites you make?
  529. # [14:01] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  530. # [14:02] <mookid> I'm implementing both URI and protocol level conneg because I have to :)
  531. # [14:02] <mookid> If HTML was good enough I'd just use HTTP conneg
  532. # [14:02] <Philip`> mookid: Even if all representations shared the same URL, then when I update the resource it'll often also be updating totally separate resources that provide an index of all resources and indicate their modification times, and resources that list recent changes to the site, and all sorts of other things
  533. # [14:03] <BenMillard> mookid, what did you do on previous website(s)?
  534. # [14:03] <mookid> if they're seperate reasources why are they at the same URL ?
  535. # [14:03] <mookid> BenMillard: that's not an argument you're just pointing out that HTML is insufficient
  536. # [14:03] <mookid> I agree with you on that.
  537. # [14:04] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  538. # [14:04] <BenMillard> mookid, I'm not making an argument or commenting on HTML's cababilities. :/
  539. # [14:04] <mookid> If you read the original post on the mailing list I even pointed out that it would be best to have both options available.
  540. # [14:04] <Philip`> mookid: They aren't - there's e.g. http://example.com/exciting-document (which accepts GET and PUT as text/html or application/pdf), but also http://example.com/recent-changes-to-site (which is application/atom+xml or whatever it's called)
  541. # [14:05] <Philip`> mookid: so they're separate resources, at separate URLs, but updating one will cause changes to the other
  542. # [14:05] <mookid> right..
  543. # [14:05] <Philip`> mookid: so any caching solution has to take into account the fact that updates to one URL might invalidate caches of another URL
  544. # [14:05] <mookid> why?
  545. # [14:05] <mookid> your designign your applications badly then.
  546. # [14:05] <Philip`> mookid: How else would it be designed?
  547. # [14:06] <mookid> well why would recent changes to site make a difference to exciting document?
  548. # [14:06] <mookid> that's a nonsense example
  549. # [14:06] <Philip`> mookid: When you change the exciting-document, that's a recent change to the site, so it'll cause the list of recent changes to change
  550. # [14:06] <mookid> BenMillard: I assumed you were going to accuse me of being ahypocrite because I have used URI's for conneg
  551. # [14:07] <mookid> I have to.
  552. # [14:07] <mookid> what value is there in caching that resource?
  553. # [14:07] <mookid> if it's constantly changing
  554. # [14:07] <mookid> that's a stupid example
  555. # [14:08] <Philip`> mookid: It's not constantly changing; it's only changing when something else (at a different URL) changes, which might be quite rare
  556. # [14:08] <mookid> well ten you would change the caching settings to reflect that
  557. # [14:08] <mookid> ...
  558. # [14:09] <mookid> it's not wise to cache documents that are beign altered on teh backend
  559. # [14:09] <Philip`> If the caching system is able to cope with updates to exciting-document invalidating the cache of recent-changes-to-site, then exactly the same system could cope with updates to report.pdf invalidating caches of report.html, so there wouldn't be the caching problem you mentioned
  560. # [14:10] <mookid> wow.. what a total and complete waste of developer time
  561. # [14:10] <mookid> my way is alot easier..
  562. # [14:10] <mookid> caching systems support it out of the box..
  563. # [14:11] <mookid> hey look - someone updated it - update the cache
  564. # [14:11] <mookid> they really are clever folks these HTTP guys
  565. # [14:11] * hsivonen posits that according to REST lore, cacheability is regarded to be of higher importance than conneg
  566. # [14:12] <mookid> how many times do you hit a cache of some kind
  567. # [14:12] <mookid> do you know?
  568. # [14:12] <mookid> it's pretty often
  569. # [14:13] <mookid> and conneg works in conjunction with caching anyway.. if you use the HTTP conneg
  570. # [14:14] <mookid> that's the point I'm making..
  571. # [14:14] <mookid> !
  572. # [14:14] <yecril71> Each time you need a specific variant of the resource, you say
  573. # [14:15] <BenMillard> mookid, I was trying to figure out the conditions which made you feel existing features were insufficient for what you are doing.
  574. # [14:15] * Philip` notes that his university has switched off its university-wide web cache because it wasn't worth continuing
  575. # [14:15] <yecril71> File.OpenIn AcrobatReader (for example).
  576. # [14:15] <BenMillard> which first requires me understand what you were doing before
  577. # [14:15] <hsivonen> mookid: my point is that if you need an additional datum to travel with the URI and you need the additional datum to derefence, the better design is to bake that datum in the URI itself
  578. # [14:15] <mookid> BenMillard: I've done a pretty good job describing it on the mailing list - I jeep having to repeat myself because people don't read my posts :(
  579. # [14:15] <yecril71> And the browser asks your favourite application
  580. # [14:15] <yecril71> to download the same resource in its favourite form.
  581. # [14:16] <mookid> hsivonen: that is complete nonsense..!
  582. # [14:16] <hsivonen> mookid: why?
  583. # [14:16] <mookid> additional datum?
  584. # [14:16] <mookid> the header is THERE in every request
  585. # [14:16] <mookid> HTML just provides no way of telling browsers how to do something intresting with it
  586. # [14:17] <mookid> the URI is for RESOURCE indentification.. not resource + representation identification
  587. # [14:17] <hsivonen> mookid: it's not there when you put the URI in a href. It's not there when you email an URI to someone. It's not there on IRC. It's not there in PDF, OOXML, ODF, etc.
  588. # [14:17] <Philip`> URIs are useful as a uniform way of referencing stuff, but if you now have to say "open http://{some URI} in Acrobat" then it's no longer a uniform way of referencing stuff
  589. # [14:17] <mookid> well shouldn't it be up to them how they decide to view the resource?
  590. # [14:18] <mookid> Philip`: YES IT IS
  591. # [14:18] * Quits: maikmerten (n=merten@129.217.26.195) (Read error: 110 (Connection timed out))
  592. # [14:18] <mookid> that's a GET on that URI
  593. # [14:18] <mookid> that's completely uniform
  594. # [14:18] <mookid> what are you talking abuot?
  595. # [14:18] <mookid> seriously. :/
  596. # [14:18] <hsivonen> mookid: note that I don't accept as dogma that URIs should be used to identify abstract resources as opposed to be used for application-level network addressing
  597. # [14:18] <yecril71> Using File.OpenIn is uniform, it is even more uniform than using extensions in URLs.
  598. # [14:19] <mookid> hsivonen: that's because you incorrectly percieve HTTP as a transport protool
  599. # [14:19] <mookid> protocol
  600. # [14:19] <mookid> it's a TRANSFER ptorocol
  601. # [14:19] <yecril71> protocol
  602. # [14:19] <mookid> thanks.. :P
  603. # [14:20] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  604. # [14:20] <mookid> URI's are protocol level anyway
  605. # [14:20] <hsivonen> mookid: I said "application-layer" precisely to suggest the layer above the transport layer
  606. # [14:20] <mookid> and so..
  607. # [14:20] <mookid> ignoreing that..
  608. # [14:21] <yecril71> Content needs to be referenced, its particular representation does not.
  609. # [14:21] <hsivonen> Is the ISO C spec online with a paywall?
  610. # [14:21] <yecril71> Because it is content that matters.
  611. # [14:21] * Joins: ginger (n=nessy@124-168-178-122.dyn.iinet.net.au)
  612. # [14:21] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Client Quit)
  613. # [14:21] <yecril71> paywhat?
  614. # [14:21] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  615. # [14:22] <mookid> yecril71: you on WHATWG?
  616. # [14:22] <hsivonen> yecril71: a paywall is a thing where you have to pay in order to view documents behind the wall
  617. # [14:22] <Philip`> hsivonen: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf is a recent (most recent?) draft, and drafts are free
  618. # [14:22] <hsivonen> Philip`: thanks
  619. # [14:22] <BenMillard> mookid, can you link me to the message which describes the use-case where users of your website the current features lacking? I'm unable to find it...
  620. # [14:23] <BenMillard> s/website the current/website found the current/
  621. # [14:23] <mookid> BenMillard: it's not a case of 'extra' ends.. it's better means..
  622. # [14:23] <Philip`> "Septermber 7, 2007" (sic) - hmm
  623. # [14:23] <yecril71> I review the current progress at WHATWG.
  624. # [14:23] <mookid> well never mind HTTP lets concentrate on video tags!
  625. # [14:23] <mookid> serious business
  626. # [14:24] <yecril71> Or rather follow, since nobody is interested in my review :-)
  627. # [14:25] <yecril71> The ISO standards are on the ISO Web site.
  628. # [14:25] <hallvors> "content needs to be referenced, its particular representation does not" is a statement that I disagree with based on personal experience. I *often* want to reference a particular representation where multiple exist.
  629. # [14:25] <mookid> BenMillard: I just think HTML should do more to make HTTP more accessible
  630. # [14:25] <mookid> and you CANT
  631. # [14:25] <mookid> because
  632. # [14:25] <mookid> ...
  633. # [14:25] <mookid> HTML doesnt provide the mechanism for it
  634. # [14:25] <mookid> hello?
  635. # [14:25] <mookid> !
  636. # [14:25] <BenMillard> sure it does, you just include the file extension at the end of the href value :)
  637. # [14:26] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
  638. # [14:26] <mookid> that's using a URL for something it was never initially intended to do
  639. # [14:27] * Quits: nessy (n=nessy@124-171-61-96.dyn.iinet.net.au) (Read error: 101 (Network is unreachable))
  640. # [14:27] <Philip`> The whole web is being used for things it was never initially intended to do
  641. # [14:27] <mookid> well..
  642. # [14:27] <Philip`> and that's good, because it's evolved to do things that people find useful
  643. # [14:27] <mookid> don't you think a new version of HTML is a good opporutity to fix that?
  644. # [14:27] <mookid> HTML has nothing to do with that
  645. # [14:27] * ginger is now known as nessy
  646. # [14:27] <mookid> it's mor eof a hindrance than a help
  647. # [14:28] <mookid> look at the prevelance of javascript
  648. # [14:28] <mookid> moslty down to the failures of html/browsers
  649. # [14:28] <mookid> ajax is slightly difference
  650. # [14:28] <mookid> different
  651. # [14:28] <yecril71> Nothing precludes the particular representations from having their separate URIs.
  652. # [14:28] <mookid> and there's that^
  653. # [14:29] <mookid> support HTTP - whcih is both methods
  654. # [14:29] <yecril71> However, the only use case for that I can think of is internal editorial review.
  655. # [14:29] <mookid> don't take that descision away from develoeprs
  656. # [14:29] <mookid> that's arrogant and it's wrong
  657. # [14:30] <yecril71> I still think the choice of format is on the viewer.
  658. # [14:30] <Philip`> The whole point of standards is to take decisions away from developers
  659. # [14:30] <mookid> er
  660. # [14:30] <mookid> the whole point?
  661. # [14:31] <Philip`> I might be exaggerating :-p
  662. # [14:31] <yecril71> It also helps the authors to produce reliable content.
  663. # [14:31] <yecril71> And it can help end users in obtaining technical support from their providers.
  664. # [14:32] <mookid> I love how hyper text's markup language has complete contempt for it's transfer protocol
  665. # [14:32] <Philip`> The whole point of standards is to take decisions away from developers and authors
  666. # [14:32] <mookid> the attitude of "well yeah they put that in but we dont need it"
  667. # [14:32] <mookid> what exactly did the HTTP guys produce an rfc for if it wasnt to tell you guys how to use their protocol properly
  668. # [14:33] <mookid> ?
  669. # [14:33] <Philip`> (as evidenced by standards being written as a set of restrictions and requirements on developers and authors)
  670. # [14:33] <mookid> like an rfc?
  671. # [14:33] <yecril71> HTTP and HTML should be kept separate.
  672. # [14:34] <yecril71> They meet at the implementor’s desk, and both are binding.
  673. # [14:34] <yecril71> HTML is for HTTP, but not vice-versa, since HTTP can trasfer other resources equally well.
  674. # [14:35] <yecril71> What did I say? It should be HTTP is for HTML.
  675. # [14:36] * Joins: ehird (n=ehird@eso-std.org)
  676. # [14:36] <yecril71> Since HTTP is not limited to HTML, there is no need for HTML to mirror HTTP in full.
  677. # [14:37] <yecril71> I hope this makes sense.
  678. # [14:37] * Joins: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp)
  679. # [14:38] * Joins: ginger (n=nessy@124-171-15-183.dyn.iinet.net.au)
  680. # [14:43] <Dashiva> Is Smylers in here?
  681. # [14:45] * Quits: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  682. # [14:45] * Philip` frowns
  683. # [14:45] * Joins: smerp (n=smerp@66.192.95.199)
  684. # [14:47] * Quits: nessy (n=nessy@124-168-178-122.dyn.iinet.net.au) (Read error: 101 (Network is unreachable))
  685. # [14:47] <mookid> I'm being asked to explain the advantages.. I'm giving them: It makes use of HTTP conneg and appropriate use of URIs..
  686. # [14:47] <mookid> when I do that
  687. # [14:47] <mookid> I get the response
  688. # [14:47] <mookid> "real world examples please"
  689. # [14:48] <mookid> wel.. there are very few real world examples ebcause the browser support isnt there
  690. # [14:48] <mookid> that doesnt exactly encourage use does it
  691. # [14:48] <mookid> it encourages the complete opposite
  692. # [14:48] <mookid> (conneg in URIs)
  693. # [14:49] <mookid> it's like dealing with politicians or something.. constantly arguing circles so that it ends up being too late to do anything about it
  694. # [14:51] <mookid> the issue here is that the benefits are hard to understand because you have to ignore your preconceptions about what a URI is and how conneg should work
  695. # [14:51] * Quits: ginger (n=nessy@124-171-15-183.dyn.iinet.net.au) ("This computer has gone to sleep")
  696. # [14:51] <mookid> it's viewed as 'difficult' because its a change to what people are used to thinking
  697. # [14:52] <mookid> there are obvious benefits of using protocol level conneg with HTTP.. if there weren't - they wouldnt have spent the time including it in the HTTP spec
  698. # [14:53] <mookid> the fact that it is not used is a criticism of HTML and browsers
  699. # [14:53] <Philip`> It doesn't have to be examples that already exist in the real world and use the feature that doesn't exist - it's more about concrete examples where a realistic developer would encounter a problem and the best way to solve the problem would be the proposed solution, rather than abstract ideas like "supporting HTTP is inherently good"
  700. # [14:53] <mookid> what like the examples I gave
  701. # [14:53] <mookid> of telling people theres a report at a given URI
  702. # [14:53] * Joins: aaronlev_ (n=chatzill@e180226059.adsl.alicedsl.de)
  703. # [14:53] <mookid> and they can use several different UA's ?
  704. # [14:54] <hallvors> ..my counter-claim is that those URLs are more usable with extensions..
  705. # [14:54] <mookid> more usable?
  706. # [14:54] <Philip`> mookid: Yes, like that
  707. # [14:55] <mookid> read the latest email I wrote - it's completely confusing
  708. # [14:55] <mookid> if I update report.pdf.. does that update report.html ?
  709. # [14:55] <Philip`> mookid: (but in that example, people aren't convinced that it's easier than providing a different URI for each UA, so they want more convincing examples)
  710. # [14:55] <ehird> hallvors: i disagree
  711. # [14:56] <mookid> right.. they're two seperate methods
  712. # [14:56] <mookid> that both 'work'
  713. # [14:56] <mookid> having content negotiation in the URI has massive potential for misleading users, actually
  714. # [14:59] <mookid> at th end of the day.. the benefits are that you support HTTP transactions in browsers better - yuo provide more options for developers to use URIs appropriately.. whilst at the same time protecting backwards compatability
  715. # [15:00] <mookid> if the Accept attribute is optional, it makes no difference to developers who insist on using URIs for conneg
  716. # [15:00] <mookid> and gives the ability to those who would like to.. do I have to do market research or can we all be grown up about it?
  717. # [15:01] <Philip`> mookid: But one method (separate URI per target UA) already works, and the other would require dozens of browser developers to spend time writing and testing and security-analysing and documenting the feature and would result in some users being unable to use some sites because they haven't upgraded their UA yet, so it has a non-negligible cost
  718. # [15:02] <mookid> security analysing?
  719. # [15:02] <mookid> at the moment the browser sends Accept */*
  720. # [15:03] <Philip`> Someone might write <a href="whatever" accept="&#x0a;&#x0a;oh no it's an unexpected request body"> and that'd be kind of bad, so you'd have to make sure nobody can do that
  721. # [15:03] <mookid> Actualyl there are clever things you can do at the server side to look at the client - if that was a problem
  722. # [15:03] <mookid> so you wouldn't necessarily have to update the UA
  723. # [15:04] <mookid> why would that be bad?
  724. # [15:04] <mookid> explain to me why that's bad
  725. # [15:05] <mookid> it's stupid.. but I can't see how "allowing" that is inherently a bad thign
  726. # [15:05] <Philip`> It would be bad for the same reasons that XMLHttpRequest doesn't let you set arbitrary HTTP headers, and blacklists things like "Host" and "Referer"
  727. # [15:05] * Quits: eric_carlson_ (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Read error: 110 (Connection timed out))
  728. # [15:05] <mookid> what reason is that?
  729. # [15:05] * hsivonen agrees with hallvors about wanting to address particular representations
  730. # [15:06] <mookid> that's because that's what you're used to
  731. # [15:06] <mookid> it's just fear of change
  732. # [15:06] <hallvors> mookid: look up HTTP request splitting
  733. # [15:06] <mookid> why?
  734. # [15:07] <hallvors> it's a cache-poisoning technique that causes potential security problems
  735. # [15:07] <mookid> and..?
  736. # [15:07] <Philip`> mookid: Some sites trust Referer to check that users came from the right place, to prevent dangerous cross-site requests, and that works now because Referer is only set by UAs and an attacker can't set it to an arbitrary value
  737. # [15:07] <hallvors> that's why adding methods to set http headers must be done very carefully
  738. # [15:07] <mookid> hahahahaha
  739. # [15:08] <mookid> that's awesome
  740. # [15:08] <mookid> does security by obscurity mean anything to you?
  741. # [15:08] <hsivonen> mookid: in general, "if there weren't - they wouldn't have spent the time of including it in the HTTP spec" is a bogus argument
  742. # [15:08] <mookid> no it's not.. they designed the protocol they would knwo the most appropriate way of using it
  743. # [15:08] <mookid> en dof
  744. # [15:09] <mookid> the fact that HTML has FAILED miserably to provide adequate mechanisms for making full use of their protocol
  745. # [15:09] <mookid> and so it is common place for peolpe to hack conneg into URIs
  746. # [15:09] <Philip`> mookid: Sure, but the Referer thing can actually achieve its goal of making it impossible for a user using a standard web browser to be tricked into making cross-site requests
  747. # [15:10] <mookid> what has that got to do with anything?
  748. # [15:10] <hallvors> if they didn't consider "URL usability" when authoring the specs they may have drawn the wrong conclusions..
  749. # [15:10] <mookid> well they did..
  750. # [15:10] <mookid> URLs (funnily enough) are used to locate resoruces
  751. # [15:10] <Philip`> It's a bit of a rubbish way of doing it, but it works in practice, so people rely on it, so browsers can't now start violating the assumptions people made, so they have to be very careful about how a web page can control the HTTP requests they send
  752. # [15:10] <mookid> resources.. and nott representations
  753. # [15:11] <hsivonen> mookid: in general, it's bogus to assume that the WG that defined HTTP 1.1 (or HTML 4) was axiomatically enlightened but that the WHATWG isn't equally axiomatically enlightened
  754. # [15:11] <hallvors> well, I disagree that the result is usable :) because I want to identify representations..
  755. # [15:11] <mookid> well from what I've read so far I'm onyl seeing circular disstractive arguments
  756. # [15:11] <mookid> so I'd say that wouldn't be a bad guess
  757. # [15:11] <hsivonen> to be clear, I'm not suggesting that the WHATWG is axiomatically enlightened. I'm suggesting that the HTTP 1.1 spec can contain bad stuff.
  758. # [15:12] <Philip`> Clearly the WHATWG should write HTTP5 which defines Uniform Representation Identifiers, and then we'd be okay
  759. # [15:12] <hsivonen> Philip`: nope, Locators!
  760. # [15:12] <mookid> you havent even given HTTP conneg a decent shot
  761. # [15:12] <mookid> so that is ridiculous logic
  762. # [15:12] * othermaciej_ is now known as othermaciej
  763. # [15:13] <Philip`> hsivonen: Whatever, they're basically the same thing :-p
  764. # [15:13] <mookid> Uniform Resource and/or Representation Indentifiers
  765. # [15:13] * Quits: aaronlev (n=chatzill@e180226050.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  766. # [15:13] <mookid> no.. no they arent.
  767. # [15:13] <hsivonen> Hixie: we should call the things that are not quite URIs in the HTML5 spec "Uniform Representation Locators"
  768. # [15:14] <Dashiva> Can't we endlessly debate what makes a Resource instead?
  769. # [15:14] <hsivonen> http://lists.w3.org/Archives/Public/www-tag/2008Mar/0026.html
  770. # [15:14] <ehird> well, a representation has to be a representation of SOMETHING
  771. # [15:14] <ehird> and resource is the generic term for something that can be represented, I guess
  772. # [15:15] <Philip`> hsivonen: Why does the acronym need to have an expansion? Just define it as an atomic term whose meaning is defined by some spec and not by a three-word description
  773. # [15:16] <jcranmer> like ISO
  774. # [15:16] <mookid> ehird: exactly.
  775. # [15:16] <ehird> hmm
  776. # [15:16] <ehird> you can represent a representation
  777. # [15:16] <ehird> os representations of resources are resources
  778. # [15:16] <ehird> xD
  779. # [15:16] <ehird> bizarre, but consistent
  780. # [15:17] <mookid> sure, there's nothing to say you cant do that in the http spec either
  781. # [15:17] <ehird> everything is a resource, a representation is of a resource.
  782. # [15:17] <ehird> representations are just a subset of resources
  783. # [15:17] <mookid> hmm
  784. # [15:17] <mookid> not really
  785. # [15:17] <jcranmer> it doesn't matter what the spec says
  786. # [15:17] <Philip`> If I can represent *any* representation, and representations represent resources, then all representations are resources, so we might as well call them all the same thing :-)
  787. # [15:18] <jcranmer> it matters what who implements the spec do
  788. # [15:18] <ehird> mookid: why not?
  789. # [15:18] <ehird> Philip`: well, yes, but
  790. # [15:18] <ehird> there are resources that are not representations
  791. # [15:18] <hsivonen> at the end of the day, representations are what cross the wire, so resources don't matter as much
  792. # [15:18] <mookid> jcranmer: well no it doesnt from my perspective - I know what the best practice is and why it would work - I've spent a while studying it
  793. # [15:18] <ehird> hsivonen: exactly
  794. # [15:18] <ehird> you can't send me, a person over the wire
  795. # [15:18] <mookid> that's how you see it at the moment..
  796. # [15:18] <ehird> but you can send a representation of me over the wire
  797. # [15:18] <ehird> and yet that representation is also a resource
  798. # [15:18] <mookid> you're all looking at URIs in tehw ay they're used at the moment
  799. # [15:18] <ehird> just one that happens to not be in meatspace
  800. # [15:18] * Joins: maikmerten (n=merten@129.217.26.195)
  801. # [15:19] <mookid> can we just step back from that a second
  802. # [15:19] <jcranmer> mookid: example
  803. # [15:19] <ehird> mookid: sure, if you give us some reasons why
  804. # [15:19] <jcranmer> HTML is SGML, by definition
  805. # [15:19] <jcranmer> ever try using the advanced SGML features in HTML?
  806. # [15:19] <mookid> why do you ask?
  807. # [15:19] <jcranmer> in practice, then, HTML uses a subset of SGML
  808. # [15:19] <Lachy> jcranmer, HTML5 is not SGML by definition
  809. # [15:20] <jcranmer> Lachy: lemme clarify... HTML 4.01
  810. # [15:20] <jcranmer> (hence why HTML5 is not SGML AIUI)
  811. # [15:20] <mookid> I still dont understand why it's so bad to include an optional attribute that will significantly help RESTful developers
  812. # [15:20] <mookid> is it laziness?
  813. # [15:20] <mookid> what?
  814. # [15:20] <ehird> mookid: what exactly is it
  815. # [15:20] <ehird> i'm uninformed
  816. # [15:21] <Philip`> mookid: It's cost vs benefit, both of which are non-zero
  817. # [15:21] <mookid> is it really that costly to implement oen attribute?
  818. # [15:21] <mookid> I think you might have problems with yoru processes.
  819. # [15:21] <mookid> -_-
  820. # [15:21] <jcranmer> mookid: you don't understand, I think
  821. # [15:21] <ehird> mookid: if every semi-useful attrib was added
  822. # [15:21] <hsivonen> mookid: it makes the address a pair instead of a single value, which sucks, because existing systems deal with one value
  823. # [15:21] <ehird> we'd have a monstrosity
  824. # [15:21] <Dashiva> Opportunity cost, maintenance costs, attack surface...
  825. # [15:21] <ehird> now someone tell me what it actually is ;)
  826. # [15:22] <mookid> hsivonen: it doesn't do anything of the sort
  827. # [15:22] <jcranmer> the mere virtue of adding something is a csot
  828. # [15:22] <mookid> HTTP already is a pri.. it's headers and body
  829. # [15:22] <mookid> pair^
  830. # [15:22] <ehird> whats that got tot do with uris.
  831. # [15:22] <jcranmer> then there's the costs of the actual implementation of the attribute, and what it does
  832. # [15:22] <mookid> everything
  833. # [15:23] <ehird> i see.
  834. # [15:23] <mookid> well the attribute isn't exactly complicated is it
  835. # [15:23] <mookid> and there's no greater attack surface
  836. # [15:23] <mookid> it's restricting the header which is allready catcha ll
  837. # [15:23] <mookid> so..
  838. # [15:23] <mookid> chill out on that one Neo
  839. # [15:23] <ehird> someone wanna tell me what it is yet? :q
  840. # [15:23] <ehird> or at least a link
  841. # [15:23] <mookid> a URI?
  842. # [15:24] <jcranmer> mookid: no HTTP uri mechanism, that I know of, allows you to specify headers
  843. # [15:24] <Philip`> ehird: What the proposed feature we're discussing is? I think it's <a href="report" accept="application/pdf">
  844. # [15:24] <ehird> Philip`: ewwwwwwwww
  845. # [15:24] <mookid> HTTP uri mechanism?!
  846. # [15:24] <ehird> how is that represented in the browser's URI box?
  847. # [15:24] <mookid> wth is that?
  848. # [15:24] <ehird> if you copy the URI there
  849. # [15:24] <ehird> and paste it in a new window
  850. # [15:24] <ehird> might you get a different representation?
  851. # [15:24] <ehird> if so... awful, awful, just plain awful
  852. # [15:24] * jcranmer heads off to class
  853. # [15:24] <hsivonen> ehird: details! :-)
  854. # [15:25] <mookid> if you put a URI into a browser 'uri box' then it will fetch HTML.. that's the desired behaviour in that use case
  855. # [15:25] <Philip`> ehird: Yes, but it'll be a representation appropriate to the UA you paste it into, and it'll be the same resource so you'll never mind the difference
  856. # [15:25] <ehird> Philip`: Except that the page evidently thought that it was important I get THIS representation
  857. # [15:25] <ehird> So... not irrelevant, evidently
  858. # [15:25] <mookid> why is it awful to get the most appropriate representation of the exact same data?
  859. # [15:26] <Philip`> Depends on what you mean by "most appropriate" - when someone tells me to look at something specific, the most appropriate thing for me to see is the same thing they're seeing, and not a UA-dependent variant in a different format
  860. # [15:26] <mookid> oh damn... my user agent got the information in the best format for it.. shock horror
  861. # [15:27] <mookid> well then use the same UA..
  862. # [15:27] <mookid> einstein..
  863. # [15:27] <ehird> mookid: snide jabs help nobody
  864. # [15:27] <mookid> well cmon.. that's just ridiculous
  865. # [15:27] <Philip`> Then they'd have to tell me what UA they were using, so they're now using a (uri, ua) pair (for which no nice uniform syntax is defined) as the reference
  866. # [15:28] <mookid> what?
  867. # [15:28] <mookid> you would just send them the URI and say 'i'm looking at the pdf'
  868. # [15:28] <mookid> why does it matter that much what the format of the data is?
  869. # [15:28] <ehird> mookid: I thought you were advocating ADDING the conneg attribute?
  870. # [15:28] <ehird> Bit of a turn around there .. ?
  871. # [15:29] <mookid> I am - conneg in this isntance is seperated from the URI
  872. # [15:29] <mookid> so, normally your UA woud have fixed defaults
  873. # [15:29] <mookid> like a PDF document
  874. # [15:29] <mookid> reader
  875. # [15:29] <mookid> or iTunes (mp3)
  876. # [15:29] <mookid> btu browsers Get lots of different stuff and pass it to the OS
  877. # [15:29] <mookid> so you need a way of making the browser Accept header dynamic
  878. # [15:29] * ehird shrugs. My thoughts: Overly complex, not a nice user experience when copying&pasting the resulting URI, not worth the effort required to implement even for the gains it might bring.
  879. # [15:30] <mookid> well it's a better user experience because they can use the UA that suits them
  880. # [15:30] <Philip`> What about an iTunes-like music player that had an embedded web browser?
  881. # [15:30] <ehird> Philip`: cough - songbird - cough?
  882. # [15:30] <ehird> ;)
  883. # [15:30] <mookid> well it depends where in teh GUI you put the URI..
  884. # [15:30] <mookid> doesnt it?
  885. # [15:31] <mookid> you keep saying stuff that you clearly think is valid when it's not.... :/
  886. # [15:31] <Philip`> You put it in the text box at the top of the window, which is where you put all your URIs and search queries and other textual input
  887. # [15:32] <mookid> so the brwoser would open up the html page which would (heopfully) provide hyper text links to all the other representations.. if HTML5 works properly that will be the same URI but with a differet Accept headerconfiguration indicated
  888. # [15:32] <mookid> YES you can do that with URIs
  889. # [15:32] <mookid> I know.
  890. # [15:33] <mookid> please don't tell me that AGAIN
  891. # [15:33] <Philip`> You can do that with UR... oh, okay
  892. # [15:33] <ehird> you can do that with UR*shot*
  893. # [15:33] <ehird> damnit Philip`
  894. # [15:33] <ehird> :(
  895. # [15:33] * Philip` is probably not being very helpful
  896. # [15:34] <mookid> essentially what you're saying is that in WHATWG's opinion.. the HTTP Accept header should be deprecated
  897. # [15:34] <ehird> what I'm saying is that you don't "get" Accept
  898. # [15:35] <ehird> accept is for the user/browser to dictate what formats they want.
  899. # [15:35] <ehird> not the page.
  900. # [15:35] <mookid> er
  901. # [15:35] <ehird> if the page must dictate the format, use file extensions
  902. # [15:35] <ehird> in the URI
  903. # [15:35] <mookid> I'm not even going to bother.. :/
  904. # [15:35] <ehird> then you won't convince me.
  905. # [15:35] <ehird> nice way to have an argument, but a bit peculiar
  906. # [15:35] <mookid> I KNOW!!! :D
  907. # [15:36] <ehird> sooo
  908. # [15:36] <ehird> why are you talking if you don't want to convince
  909. # [15:36] <mookid> well you're arguing in circles and you arent making sense
  910. # [15:36] <mookid> I'm saying
  911. # [15:36] <mookid> ok
  912. # [15:36] <mookid> bear with me
  913. # [15:36] <hsivonen> mookid: I suggest going back to what BenMillard said: giving a rationale in terms of use cases instead of appealing to the authority of the definers of HTTP.
  914. # [15:37] <mookid> developers need a way to construct HTML that can allow the user.. a way of modifying the Accept header in an HTML interface
  915. # [15:37] <ehird> no
  916. # [15:37] <ehird> i disagre
  917. # [15:37] <ehird> e
  918. # [15:37] <mookid> that isnt possible at the moment.. so URIs are used instead as a hack
  919. # [15:38] <mookid> it's a hack though
  920. # [15:38] <ehird> i disagree with your first point
  921. # [15:38] <mookid> it's just what people are used to
  922. # [15:38] <ehird> therefore you cannot convince me without convincing me of your first point.
  923. # [15:38] <hsivonen> mookid: It's a hack only from the point of view of a particular dogma that you haven't justified
  924. # [15:38] <BenMillard> ehird, file extensions in href (or src and so forth) seem like an solution to me, too. I consider this a Solved Problem, although if mookid follows hsivonen's advice maybe that'll unearth a widespread user need we haven't thought of.
  925. # [15:38] <mookid> dogma?
  926. # [15:38] <hsivonen> mookid: yes
  927. # [15:38] <mookid> lol
  928. # [15:39] <ehird> i hate it when people say "lol" when they run themselves into a corner
  929. # [15:39] <ehird> and don't justify their position...
  930. # [15:39] <mookid> what
  931. # [15:39] <mookid> it's not dogma
  932. # [15:39] <mookid> he's being a douchebag
  933. # [15:39] <ehird> gee, that's very kind
  934. # [15:39] <mookid> so is describing my poitn of view as dogma.
  935. # [15:40] <ehird> that's not a personal attack, that's a criticism of your views.
  936. # [15:40] <mookid> that's not a criticism
  937. # [15:40] <jcranmer> mookid: look at it like this
  938. # [15:40] <jcranmer> under your proposal
  939. # [15:40] <hsivonen> mookid: you can make it non-dogma by explaining in terms of use cases and addressing use cases and problems and solutions why putting ".pdf" in the URI is inappropriate
  940. # [15:40] <jcranmer> the accept is static
  941. # [15:40] <mookid> I DID EXPLAIN THE USE CASE
  942. # [15:41] <jcranmer> the page itself defines what it wants
  943. # [15:41] <mookid> "here theres somethign interesting here: example.com/report - have a look"
  944. # [15:41] <mookid> user can use whatever UA they want
  945. # [15:41] <mookid> that's a use case.
  946. # [15:41] <jcranmer> mookid: if the page says, "I want this to be HTML"
  947. # [15:41] <jcranmer> why not just tack on the .html at the end?
  948. # [15:41] <hsivonen> mookid: s without specifying accept, they get whatever
  949. # [15:41] <ehird> mookid: and?
  950. # [15:41] <hsivonen> s/s /so /
  951. # [15:42] <mookid> you can't do that using URIs for conneg
  952. # [15:42] <mookid> how would you say
  953. # [15:42] <hsivonen> mookid: if you want to send someone a link to a pdf, why is putting ".pdf" in the URI not an acceptable way to address the use case?
  954. # [15:42] <ehird> hsivonen ++
  955. # [15:42] <ehird> it's not a hack at all
  956. # [15:42] <ehird> if the type really is important, specify .pdf
  957. # [15:42] <ehird> BUT
  958. # [15:42] <ehird> Accept is for the user agent
  959. # [15:42] <mookid> "hey look at this URI and use whatever UA you want to look at it" if conneg is done in the URI ?
  960. # [15:42] <ehird> s
  961. # [15:42] <ehird> and the users
  962. # [15:42] <ehird> NOT the content authors
  963. # [15:42] <mookid> what?
  964. # [15:43] <ehird> the users, and their user agents, specify what types THEY personally want
  965. # [15:43] <ehird> it's not for the content authors to decide
  966. # [15:43] <ehird> for that, they should use .pdf and similar
  967. # [15:43] <hsivonen> mookid: should I try Firefox, iTunes, Word, Excel, OOo, etc. to see what you serve to each?
  968. # [15:43] <mookid> it's the SAME resource
  969. # [15:43] <mookid> it's the SAME data
  970. # [15:43] <mookid> it's just a DIFFERENT REPRESENTATION
  971. # [15:43] <ehird> I agree with that much.
  972. # [15:43] <jcranmer> at some point
  973. # [15:44] <jcranmer> you realize that idealism doesn't match up with reality
  974. # [15:44] <mookid> oh right
  975. # [15:44] <ehird> But I say that pragmatically, file extensions are the way to solve this
  976. # [15:44] <ehird> and the Accept changing damages repeatability
  977. # [15:44] <mookid> maybe that's becaue of belligerant spec writerS?
  978. # [15:44] <ehird> (copy&paste the uri and get the same thing)
  979. # [15:44] <jcranmer> no
  980. # [15:44] <mookid> possibly?
  981. # [15:44] <hsivonen> mookid: if it's same enough that the representation doesn't matter, why do you care about the accept value?
  982. # [15:44] <mookid> no?
  983. # [15:44] <mookid> thoguht not.
  984. # [15:44] <ehird> and is not good use of Accept
  985. # [15:44] <ehird> it's for users/user agents
  986. # [15:44] <jcranmer> mookid: no, implementors
  987. # [15:44] <mookid> omg..
  988. # [15:44] * BenMillard realises what the most productive thing to do at this point is.
  989. # [15:45] <jcranmer> specs mean nothing if they're not implemented
  990. # [15:45] * Parts: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  991. # [15:45] <ehird> mookid: If you weren't being condescending and insulting, I'd talk more.
  992. # [15:45] <jcranmer> ask the ACAP author
  993. # [15:45] <mookid> hsivonen: because the accept value is the only way you can serve multiple content types from one URI
  994. # [15:45] <ehird> And?
  995. # [15:45] <mookid> that's important..
  996. # [15:45] <mookid> that's how HTTP was designed
  997. # [15:45] <ehird> Is it now.
  998. # [15:45] <mookid> yes it is now.
  999. # [15:45] <jcranmer> mookid: are you are an HTTP developer?
  1000. # [15:45] <ehird> Well, it'd be nice if you justified that.
  1001. # [15:45] <hsivonen> mookid: but you shouldn't serve them from one URI unless you are indifferent towards which representation a user gets
  1002. # [15:45] <ehird> exactly
  1003. # [15:45] <mookid> no I'm an architect
  1004. # [15:45] <ehird> if it matters, separate the URIS
  1005. # [15:45] * Joins: danbri (n=danbri@unaffiliated/danbri)
  1006. # [15:46] <mookid> I *actually use* this stuff
  1007. # [15:46] <jcranmer> do you know the contents of the HTTP development meetings?
  1008. # [15:46] <danbri> are the list archives borken? http://lists.whatwg.org/pipermail/help-whatwg.org/
  1009. # [15:46] <mookid> to do new interesting stuff.
  1010. # [15:46] <mookid> and progress this stuff forwards..
  1011. # [15:46] <mookid> rather than continuing to do the same stuff that doesnt really work very well
  1012. # [15:46] <danbri> ah, i'm mixing up lists
  1013. # [15:46] <ehird> danbri: wfm
  1014. # [15:46] <jcranmer> you seem to be claiming to channel the HTTP spec writers
  1015. # [15:47] * Joins: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  1016. # [15:47] <ehird> spec development via spiritual energy
  1017. # [15:47] <mookid> no I'm not.. I just look at the Accept haeder and thing.. hmm WHAT MIGHT BE THE REASON FOR THAT BEIGN THERE
  1018. # [15:47] <mookid> OH I DONT KNOW
  1019. # [15:47] <mookid> for fun.
  1020. # [15:47] <ehird> mookid: for users
  1021. # [15:47] <ehird> and
  1022. # [15:47] <ehird> user agents
  1023. # [15:47] <mookid> for suers?
  1024. # [15:47] <jcranmer> for UAs
  1025. # [15:47] <ehird> to specify what types they prefer to get data in.
  1026. # [15:47] <ehird> NOT for content authors
  1027. # [15:47] <mookid> YES
  1028. # [15:47] <mookid> AND MOST UAs
  1029. # [15:47] <danbri> (i read meaning into http://www.whatwg.org/mailing-list url and assumed was only one list)
  1030. # [15:47] <ehird> USE ALL CAPS
  1031. # [15:47] <mookid> have fixed Accept headers
  1032. # [15:47] <ehird> that's their problem
  1033. # [15:47] <mookid> brwosers
  1034. # [15:47] <ehird> next
  1035. # [15:47] <mookid> dont
  1036. # [15:47] <mookid> they're Hypermedia brwosers
  1037. # [15:48] <mookid> hypermedia provides a window for the OS
  1038. # [15:48] <ehird> yawn, this is the part where I realise you're not actaully listening to us and stop talking to you
  1039. # [15:48] <jcranmer> yep
  1040. # [15:48] <mookid> well yuo're tlaking crap that's why
  1041. # [15:48] <mookid> no offence
  1042. # [15:48] <jcranmer> [ citation needed ]
  1043. # [15:48] <ehird> mookid: no, i'm talking a representation of crap
  1044. # [15:48] <ehird> obviously.
  1045. # [15:48] <mookid> hillarious.
  1046. # [15:49] <ehird> almost as hilarious as calling people who disagree with you douchebags!
  1047. # [15:49] <mookid> you clearly don't knwo what yuo're tlaking abuot just pipe down
  1048. # [15:49] <ehird> anyway, i thought i said i'd stop talking to you
  1049. # [15:49] <mookid> good you do that
  1050. # [15:49] <jcranmer> ehird: ever visit any Usenet groups recently?
  1051. # [15:49] <ehird> jcranmer: No -- and there's a good reason for that
  1052. # [15:49] <ehird> :)
  1053. # [15:49] <Philip`> It's much easier to say you're going to stop talking to someone, than to actually stop talking to them
  1054. # [15:50] <ehird> Philip`: yep
  1055. # [15:50] <hsivonen> http://www.joelonsoftware.com/articles/fog0000000018.html
  1056. # [15:50] <mookid> jcranmer: you stopped that train of thought I noticed
  1057. # [15:50] <mookid> omg URI conneg!
  1058. # [15:50] <jcranmer> ehird: shame... he reminds me of JSH or Twisted on sci.math and comp.lang.java.programmer in recent months
  1059. # [15:50] <jcranmer> hmm, not so much JSH though
  1060. # [15:50] <ehird> hsivonen: i was gonna link to that
  1061. # [15:50] * Philip` thinks joelonsoftware.com's URLs indicate great optimism as to how many articles will be published
  1062. # [15:50] <ehird> when he said architet
  1063. # [15:51] <ehird> *architect
  1064. # [15:51] <ehird> Philip`: lol :)
  1065. # [15:51] <ehird> Philip`: interestingly, the URIs actually go downwards
  1066. # [15:51] <mookid> "there's no such thing as superior beings" - actually there is that's how genetics work deal with it
  1067. # [15:51] <ehird> http://www.joelonsoftware.com/Archive.html
  1068. # [15:52] <ehird> and then up again
  1069. # [15:52] <ehird> go figure
  1070. # [15:52] <mookid> jcranmer: we didnt finisht aht off
  1071. # [15:53] <mookid> so.. most UAs have specific Accept requirements that dont change
  1072. # [15:53] <mookid> Browsers are a special case that do hypermedia but ALSO pass other content types to the OS
  1073. # [15:53] <mookid> HTML needs to take account for that if people are to start using URIs properly
  1074. # [15:53] <ehird> *crickets*
  1075. # [15:53] <mookid> the reasont hey dont do that now
  1076. # [15:54] <mookid> is becaue its impossible
  1077. # [15:54] <mookid> not because it's "hard"
  1078. # [15:54] <ehird> i considered something similar when i first starting using content negotiation
  1079. # [15:54] <mookid> if you look at Rails.. Jax-RS..
  1080. # [15:54] <ehird> except I realised why it was silly a few minutes after.
  1081. # [15:54] <mookid> yeah silly..
  1082. # [15:54] <mookid> that's why JAX-RS is built around it
  1083. # [15:54] <ehird> yeah- silly
  1084. # [15:54] <mookid> I suppose
  1085. # [15:54] <mookid> do you know what JAX-RS is?
  1086. # [15:55] * ehird sighs
  1087. # [15:55] <ehird> appeal to authorityyyyyyy
  1088. # [15:55] <mookid> look it up then
  1089. # [15:55] <mookid> I am not affiliated with them
  1090. # [15:55] <hsivonen> Repetitive Strain XML binding for Java?
  1091. # [15:55] <mookid> no it's got nothing to do with XML actually
  1092. # [15:56] <mookid> it's content-type neutral
  1093. # [15:56] <mookid> but the syntax is designed around HTTP methods.. and as a subset.. requested representation
  1094. # [15:56] * Joins: eric_carlson (n=ericc@17.203.15.222)
  1095. # [15:57] <mookid> I wonder why they did that..
  1096. # [15:57] <mookid> a URI.. split up by methods..
  1097. # [15:57] * Philip` thinks it's fun how http://www.intertwingly.net/code/mombo/htaccess process the Accept header via a collection of UA-specific regexps, so it's basically an obscured form of UA sniffing
  1098. # [15:57] <mookid> and content-type..
  1099. # [15:57] <ehird> Philip`: cute
  1100. # [15:57] <hsivonen> mookid: because WS-* went downhill, REST is in vogue and for each buzzword, Java has to hava a framework?
  1101. # [15:58] <mookid> REST is just codeword for not using HTTP retardedly
  1102. # [15:59] <hsivonen> mookid: right, so why do you need a framework beyond an HTTP framework?
  1103. # [15:59] <mookid> RAD
  1104. # [15:59] <mookid> duuuuh...
  1105. # [15:59] <mookid> you can make a REST interface with folders and index.php scripts if you want
  1106. # [15:59] <mookid> yuo've been able to do that for years
  1107. # [15:59] <ehird> totally RAD
  1108. # [15:59] <mookid> idiot.
  1109. # [15:59] <ehird> hey, there go the personal insults again
  1110. # [15:59] <ehird> i love this
  1111. # [15:59] * hsivonen subclasses HttpServlet, but whatever
  1112. # [16:00] <Philip`> If I upload a few static pages and serve them via Apache, is that REST?
  1113. # [16:00] <mookid> yes if you do it right
  1114. # [16:00] <mookid> of course it is
  1115. # [16:00] <mookid> REST isnt very complicated
  1116. # [16:00] <mookid> people use big words to make it sound all clever
  1117. # [16:01] <mookid> it's just "looking at HTTP and designing around it"
  1118. # [16:01] <mookid> partically speaking at least
  1119. # [16:01] <mookid> they get all beardy about it
  1120. # [16:01] <mookid> because you can be RESTful with another protocol or whatveer
  1121. # [16:01] <ehird> mookid: I believe we all know this
  1122. # [16:02] <mookid> I dont
  1123. # [16:02] <hsivonen> mookid: so why do you assume we are clueless but the HTTP folks and JAX-RS folks did everything for a good reason?
  1124. # [16:02] <mookid> REsources + representations
  1125. # [16:02] <mookid> caching
  1126. # [16:02] <mookid> HTTP
  1127. # [16:03] <ehird> REST = REsources?
  1128. # [16:03] <mookid> conneg
  1129. # [16:03] <jcranmer> hsivonen: because we disagree with him
  1130. # [16:03] <ehird> lol!
  1131. # [16:03] <ehird> Representational State Transfer
  1132. # [16:03] <mookid> jcranmer: you've stopped our conversation before
  1133. # [16:03] <mookid> why?
  1134. # [16:03] <ehird> mookid: because you're ignoring us, treating us as idiots, insulting us, being condescending, ...
  1135. # [16:04] <mookid> because I explained what a browser is supposed to do
  1136. # [16:04] <jcranmer> I'm also in middle of class
  1137. # [16:04] <mookid> and the function of hypermedia
  1138. # [16:04] <ehird> jcranmer: :-P
  1139. # [16:04] <mookid> ooh right ok my bad enjoy
  1140. # [16:04] <jcranmer> mookid: to be precise, you explaing what you THINK a browser is supposed to do
  1141. # [16:04] * Quits: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  1142. # [16:04] <mookid> well you tell me the alternative definition then
  1143. # [16:04] <ehird> ... but not WHY
  1144. # [16:05] <mookid> The benefits of protocol conneg are reasonably apparent I thin I've done a reasonable job putting them forwar
  1145. # [16:05] <mookid> when I do that
  1146. # [16:05] <mookid> I get
  1147. # [16:05] <mookid> "real world examples please?"
  1148. # [16:05] <ehird> well, you haven't
  1149. # [16:05] <ehird> unfortunately
  1150. # [16:05] * Joins: MikeSmith (n=MikeSmit@W182171.ppp.dion.ne.jp)
  1151. # [16:05] <mookid> just be quiet you no one cares what you think.. :/
  1152. # [16:06] <jcranmer> invert speaker and listener of last sentence
  1153. # [16:06] <Dashiva> mookid: It seems you just dismiss anyone who doesn't agree with you
  1154. # [16:06] <ehird> and this is why peopel don't talk to you
  1155. # [16:06] <mookid> no I dont I just dismiss people who dont do me the respect of reading and comprehending what I'm communicating to them
  1156. # [16:06] <Philip`> ehird: People here are doing a very bad job if they're intending to not talk to him
  1157. # [16:07] <ehird> indeed...
  1158. # [16:07] <mookid> indded?
  1159. # [16:07] <mookid> just shush please
  1160. # [16:07] <jcranmer> true
  1161. # [16:07] * ehird shushes please
  1162. # [16:07] <mookid> yeah I completely respect people for having thei opinion I just dont feel ilke some people are really opening up
  1163. # [16:08] <mookid> in how they consier what I'm saying
  1164. # [16:08] <Dashiva> Have you ever considered that you might be wrong?
  1165. # [16:08] <mookid> because most of the respnses I get are already dealt with in other stuf I've said
  1166. # [16:08] <ehird> Dashiva: oh, you joker!
  1167. # [16:08] <mookid> well I've been looking at this for a while now
  1168. # [16:08] <mookid> so..
  1169. # [16:08] <mookid> I havent heard antyhign from anyone
  1170. # [16:08] <mookid> and actually
  1171. # [16:08] <mookid> most of the peolpe who sound like they know what they're talkign abuot
  1172. # [16:09] <mookid> arent suggesting i'm wrong
  1173. # [16:09] <jcranmer> look up Michelson-Moore
  1174. # [16:09] <mookid> they're suggesting I need to come up with a use case and real world examples
  1175. # [16:09] <jcranmer> you can work on something for a while and still be wrong
  1176. # [16:09] <mookid> yeah true
  1177. # [16:09] <mookid> I agree.
  1178. # [16:09] <mookid> you can get so caught up in a certain way of doing thigns
  1179. # [16:09] * Quits: MikeSmith (n=MikeSmit@W182171.ppp.dion.ne.jp) (Remote closed the connection)
  1180. # [16:09] <Dashiva> jcranmer: Morley, you mean?
  1181. # [16:09] <mookid> that the alternative seems totally unviable
  1182. # [16:09] <jcranmer> Dashiva: maybe?
  1183. # [16:09] <Philip`> jcranmer: <troll>Or look up religion</troll>
  1184. # [16:09] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.84 [Firefox 3.1b2pre/20081117020249]")
  1185. # [16:09] <jcranmer> I don't know off the top of my head
  1186. # [16:10] <jcranmer> Philip`: what if they're ALL right?
  1187. # [16:10] <hsivonen> http://en.wikipedia.org/wiki/Michelson-Morley_experiment
  1188. # [16:10] * Joins: MikeSmith (n=MikeSmit@W182171.ppp.dion.ne.jp)
  1189. # [16:11] <jcranmer> g'evening, MikeSmith
  1190. # [16:11] <mookid> The strangest thing abuot this is tha tI'm not even the one claiming to be right.. I'm just saying we cant tell
  1191. # [16:11] <mookid> until you provision it
  1192. # [16:11] <mookid> there's no feasible way of testing HTTP conneg
  1193. # [16:11] <MikeSmith> jcranmer: hei
  1194. # [16:11] <mookid> because developers wont move
  1195. # [16:11] <mookid> because they cant..
  1196. # [16:12] <hsivonen> mookid: you don't need to try everything. You can see problems with some things before implementation.
  1197. # [16:12] <mookid> if your persepective is wrong sure.
  1198. # [16:13] <mookid> The caching issue is an interesting one which no one seems to have adressed
  1199. # [16:14] <Philip`> We can't afford to try every idea, so we have to imperfectly predict whether they'll be worthwhile based on what we already know
  1200. # [16:14] <Philip`> particularly since it's impossible to ever remove a feature once it's been added, even if it turns out to be a terrible idea
  1201. # [16:15] <mookid> why is it terrible to provide an optional mechanism for controlling Accept headers?
  1202. # [16:17] <Dashiva> How about an optional mechanism to control font size?
  1203. # [16:18] <mookid> css?
  1204. # [16:18] <Dashiva> No, in the resources provided by the server
  1205. # [16:18] <mookid> css?
  1206. # [16:18] <Dashiva> CSS in a powerpoint file? A pdf?
  1207. # [16:18] <mookid> er what?
  1208. # [16:19] <mookid> we talkign abuot HTML here or not?
  1209. # [16:19] * Philip` doesn't understand Dashiva
  1210. # [16:19] <Dashiva> <a href="file.pdf" accept-font-size="14pt">
  1211. # [16:19] <Dashiva> So it doesn't give me documents where I have to zoom in
  1212. # [16:19] <jcranmer> :-)
  1213. # [16:20] * jcranmer winks
  1214. # [16:20] <mookid> HTTP conneg is a bti mroe fundamental than font size
  1215. # [16:20] <jcranmer> but why not?
  1216. # [16:20] <Dashiva> Surely adding just this one attribute is easy
  1217. # [16:20] <Dashiva> And we don't know if it'll work before we try
  1218. # [16:20] <jcranmer> it's not like it's terribly costly to implement
  1219. # [16:20] <mookid> if you think that's the same thing that explains alot
  1220. # [16:20] <mookid> :)
  1221. # [16:20] <hsivonen> mookid: why? Font size is relevant to all text. Conneg isn't.
  1222. # [16:21] <mookid> Conneg is relevant to every request
  1223. # [16:21] <mookid> conneg is part of the browser request
  1224. # [16:21] <jcranmer> it's also pointing out something of your method
  1225. # [16:22] <mookid> not really i't sjust more diversionary rubbish
  1226. # [16:22] <mookid> to be expected
  1227. # [16:22] <jcranmer> you rejected it offhand without giving it thought
  1228. # [16:22] <jcranmer> the priniciples are the same
  1229. # [16:22] * Joins: csarven (i=nevrasc@univcomm-allison-gm606-37.Concordia.CA)
  1230. # [16:23] <jcranmer> we essentially gave the same "reasons" that you did
  1231. # [16:24] <mookid> we?
  1232. # [16:24] <jcranmer> Dashiva and I
  1233. # [16:24] <mookid> I really hope you arent involved in this in any significant sense
  1234. # [16:24] <mookid> you've added nothing so far.
  1235. # [16:24] <jcranmer> you've convinced us of nothing
  1236. # [16:25] <Dashiva> Have you talked to XHTML2 yet?
  1237. # [16:25] <mookid> not yet
  1238. # [16:25] <mookid> why?
  1239. # [16:26] <Dashiva> Just wondering
  1240. # [16:26] <Philip`> mookid: That's just the standard "go talk to some group we don't like because maybe your idea is the kind of crazy thing they'll like" insult
  1241. # [16:27] <Dashiva> Busted!
  1242. # [16:27] * Dashiva shakes fist
  1243. # [16:27] <Philip`> rather than a constructive suggestion
  1244. # [16:27] <mookid> god forbid.
  1245. # [16:27] * Philip` takes all Dashiva's guns and $100
  1246. # [16:27] <jcranmer> Philip`: you didn't have to say that out loud ;-)
  1247. # [16:27] <Dashiva> But it's also a place where you're more likely to find agreement
  1248. # [16:28] <Dashiva> Since they're more interested in architectural purity than HTML5 is
  1249. # [16:29] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  1250. # [16:30] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  1251. # [16:30] <ehird> mookid is still talking?
  1252. # [16:30] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  1253. # [16:30] <ehird> wow :D
  1254. # [16:30] <Philip`> It's also a place where (according to the groupmind here) the harmful effects of any crazy ideas will be prevented because nobody will implement XHTML2
  1255. # [16:31] <Dashiva> We don't get to be a hivemind?
  1256. # [16:31] <Philip`> so it's a safe place to send people to
  1257. # [16:31] <jcranmer> Philip`: so XHTML2 is the new ACAP?
  1258. # [16:31] <Philip`> jcranmer: An Agreement on the Conservation of Albatrosses and Petrels? I don't think it is
  1259. # [16:32] <Dashiva> Say, is html4all still around?
  1260. # [16:32] <jcranmer> +++ Binet-Simon test: 1st modern intel test
  1261. # [16:32] <jcranmer> ++++ abstract verbal reason skills
  1262. # [16:32] <jcranmer> ++++ metnal age: metal ability typical of child
  1263. # [16:32] <jcranmer> +++ ->
  1264. # [16:32] <jcranmer> dammit
  1265. # [16:33] <jcranmer> http://www.rfc-editor.org/rfc/rfc2244.txt
  1266. # [16:33] <jcranmer> (forgot to Ctrl-C the URI)
  1267. # [16:34] <Philip`> Dashiva: Their public list isn't dead, but I guess all the juicy stuff is happening behind closed doors
  1268. # [16:34] <Philip`> (or maybe it isn't happening at all, but that would be boring so I prefer my world-view)
  1269. # [16:35] <Philip`> jcranmer: What is its analogy with XHTML2?
  1270. # [16:35] <jcranmer> Philip`: dead, highly dead
  1271. # [16:35] <jcranmer> only one server implementation
  1272. # [16:36] <Dashiva> Mr. Last week is failing
  1273. # [16:36] <Dashiva> His suggestion for the new doctype to be <HIXIE> isn't compatible with standards mode
  1274. # [16:37] <Philip`> jcranmer: There are plenty of RFCs without even that many implementations
  1275. # [16:38] <hsivonen> Dashiva: and now there'd even be IRC material available
  1276. # [16:38] <ehird> Dashiva: <!doctype hixie>
  1277. # [16:38] <ehird> <hixie>...</hixie>
  1278. # [16:38] <Dashiva> Oh right
  1279. # [16:39] <Dashiva> We'll be famous for this
  1280. # [16:39] <Dashiva> *infamous
  1281. # [16:39] <ehird> just name every element after someone in here.
  1282. # [16:39] <jcranmer> Philip`: I've always used ACAP as my example of a dead protocol
  1283. # [16:39] <Philip`> Dashiva: That's why we just need everyone to upgrade to the Hixiefox and Hixiekit and Hixplorer and Hixpera browsers, and they can render it in standards mode
  1284. # [16:40] * Joins: billmason (n=bmason@ip41.unival.com)
  1285. # [16:40] <Dashiva> Philip`: Surely it would then be hixie mode
  1286. # [16:40] <jcranmer> and quirks mode is hixie pixie mode!
  1287. # [16:41] <ehird> <!doctype hixie><hixie><philip>hello world</philip><dashiva>An example Hixie5 page</dashiva><danbri>This is a paragraph</danbri></hixie>
  1288. # [16:41] <Philip`> Actually, Hixplorer sounds stupid, it should be HixIE
  1289. # [16:41] <Dashiva> FireFoxie
  1290. # [16:41] <ehird> Philip`: HixIEplorer
  1291. # [16:42] <Dashiva> What was HTML again, Hixie something Markup Language
  1292. # [16:42] <danbri> that should be <danbri xmlns='http://danbri.org/' /> :)
  1293. # [16:42] <ehird> Dashiva: It's HIXIE
  1294. # [16:42] <ehird> Stands for Hixie Ixie Xie Ie E
  1295. # [16:42] <ehird> Because it's an "echo" of the content. Totally.
  1296. # [16:43] * Quits: pergj (n=pergj@dhcp206-59-244-232.ssb.sjc.wayport.net) (Read error: 60 (Operation timed out))
  1297. # [16:43] <ehird> danbri: http://danbri.org/danbri
  1298. # [16:43] <Dashiva> ehird: Yeah, but we had an expansion of HTML last year
  1299. # [16:43] <ehird> :p
  1300. # [16:43] <ehird> ah, wait
  1301. # [16:43] <ehird> hmm, no
  1302. # [16:46] <Philip`> jcranmer: You could use HTML 3.0 as a more appropriate example, perhaps
  1303. # [16:46] <jcranmer> HTML 1.0
  1304. # [16:47] * Philip` likes how HTML 3.0's <math> element defines a new syntax that would parse to the same DOM tree as the usual SGMLish tags
  1305. # [16:48] <Philip`> e.g. <math>x^{1+2}</math> seems to be the same as <math>x<sup><box>1+2</box></sup></math>
  1306. # [16:48] * Joins: aroben (n=aroben@unaffiliated/aroben)
  1307. # [16:48] <ehird> wow, never heard of that
  1308. # [16:49] <Philip`> since that's a nice extension of the idea that the character-level syntax and parsed representation are really independent concepts
  1309. # [16:49] <Lachy> Dashiva, s/FireFoxie/FireHixie/
  1310. # [16:50] <Philip`> Oh, actually, I think that should be <math>x^{1+2}^</math>
  1311. # [16:51] <Philip`> Fire Hixie? Then we wouldn't have an editor
  1312. # [16:51] <danbri> that is interesting, yeah
  1313. # [16:53] * Joins: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net)
  1314. # [16:56] * Parts: hdh (n=hdh@118.71.123.123) ("Konversation terminated!")
  1315. # [16:57] <Philip`> Easy solution to the problem of thinking of precise antonyms for rel values: use some pattern along the lines of rel="rev-author"
  1316. # [17:00] <Lachy> I'm not even convinced of the need for rel='author", and even less convinced of the need for the reverse relationship
  1317. # [17:01] * Quits: dave_levin_ (n=levin@72.14.224.1)
  1318. # [17:02] * gsnedders awves
  1319. # [17:02] <gsnedders> *&waves
  1320. # [17:02] <Lachy> and considering that the concept of a reverse relationship is difficult for authors to grasp correctly, it would be a mistake to add it simply to cater for theoretical cases
  1321. # [17:02] <gsnedders> **waves
  1322. # [17:03] * Parts: billmason (n=bmason@ip41.unival.com)
  1323. # [17:04] * Quits: maikmerten (n=merten@129.217.26.195) (Remote closed the connection)
  1324. # [17:04] * Joins: epeus (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  1325. # [17:06] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  1326. # [17:07] * Joins: billmason (n=bmason@ip41.unival.com)
  1327. # [17:10] <jcranmer> wouldn't *&waves = waves?
  1328. # [17:11] <Philip`> Not if you overload the unary operator*
  1329. # [17:11] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  1330. # [17:11] <jcranmer> let's talk C here
  1331. # [17:11] <Philip`> How boring
  1332. # [17:12] <Dashiva> I'm still waiting for D to become popular
  1333. # [17:12] <Dashiva> It looks kinda neat
  1334. # [17:12] <jcranmer> doesn't DTrace use D?
  1335. # [17:12] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  1336. # [17:12] <jcranmer> oh wait, it's a different D
  1337. # [17:12] <Philip`> jcranmer: That's a completely different D
  1338. # [17:12] <Philip`> and isn't even Turing-complete
  1339. # [17:12] <jcranmer> D therefore shouldn't be popular
  1340. # [17:12] <jcranmer> don't want to confuse people
  1341. # [17:13] <Philip`> Dashiva: It looks kind of neat, but not neat enough to overcome the huge legacy advantage of C for systems programming, or to compete with proper languages for other types of programming
  1342. # [17:14] <jcranmer> any new language should be compatible with the C ABI
  1343. # [17:14] <jcranmer> for bonus point
  1344. # [17:15] <jcranmer> support C++ ABI
  1345. # [17:15] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Client Quit)
  1346. # [17:16] <Philip`> That's kind of hard when even C++ doesn't support the C++ ABI (if you mix compilers or compiler versions)
  1347. # [17:16] <Philip`> (unless I'm sadly mistaken about this)
  1348. # [17:17] <Philip`> Passing STL objects across DLL boundaries is fun
  1349. # [17:18] <jcranmer> ooh, I got caught by something similar
  1350. # [17:19] <jcranmer> an object I was working with (growable array) wouldn't work if the original array had 0 size, but with non-zero size, it worked
  1351. # [17:20] <jcranmer> all because of hidden static variables
  1352. # [17:20] <jcranmer> basically, &sEmptyHdr != &sEmptyHdr :-)
  1353. # [17:21] * Joins: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net)
  1354. # [17:27] * Joins: dave_levin (n=levin@72.14.227.1)
  1355. # [17:34] * Quits: tthorsen (n=tommy@home.kvaleberg.no) ("Leaving")
  1356. # [17:34] * Joins: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk)
  1357. # [17:36] <yecril71> Lynx uses LINK[rev="made"] for me to complain about a Web page.
  1358. # [17:36] <yecril71> Quite handy: press "C", no need to look around.
  1359. # [17:37] <yecril71> Is it possible to have type of a hyperlink influence the Accept header the browser sends?
  1360. # [17:38] <yecril71> s/possible/reasonable/
  1361. # [17:39] <Philip`> I imagine its handiness is significantly reduced by the problem that fewer than 1% of pages have rev=made
  1362. # [17:40] <Philip`> and shouldn't that be using LINK[rel="author"] anyway?
  1363. # [17:41] * Joins: pergj (n=pergj@65.219.59.50)
  1364. # [17:41] <yecril71> Perhaps it should; only Lynx does not support it.
  1365. # [17:42] * Philip` sees that nearly all <link rev=made> have href=mailto:...
  1366. # [17:42] <yecril71> So, to make my page conveniently usable for Lynx users, I have to use rev.
  1367. # [17:42] <ehird> the maker of the document is who you should contact about maintaining it
  1368. # [17:42] <ehird> the author of a document is the author of the content in the document
  1369. # [17:43] <yecril71> Now you are getting architectonic...
  1370. # [17:43] <yecril71> I have decribed the reality, and the reality is brutal.
  1371. # [17:44] * Philip` sees about as many <link rev=made href=example@example.com> (forgetting the "mailto:") as he sees <link rev=made href=http://...>
  1372. # [17:45] <Philip`> whereas rel=author most commonly links to a page instead of an email address
  1373. # [17:45] <yecril71> I guess that means it should really be rel="publisher"?
  1374. # [17:46] <Philip`> so it seems the semantics are defined more by convention (i.e. people copying examples and tutorials that use rel=author and rev=made for pages and emails) than by what anyone intended the values to really mean
  1375. # [17:47] <yecril71> rev=made is required as implemented.
  1376. # [17:49] * Quits: pesl (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  1377. # [17:52] * Quits: aaronlev_ (n=chatzill@e180226059.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  1378. # [17:54] * Joins: dglazkov (n=dglazkov@nat/google/x-e1c22b6c74229501)
  1379. # [17:58] <Lachy> does anyone here understand RB's distinction of "browser behaviour" and "HTML parsing"?
  1380. # [18:00] <Dashiva> does anyone here understand RB?
  1381. # [18:01] <Lachy> rarely
  1382. # [18:03] <yecril71> Is it reasonable to expect that specifying the type attribute of a hyperlink
  1383. # [18:03] <yecril71> will also influence the Accept header sent by the browser?
  1384. # [18:03] <Dashiva> Give an example?
  1385. # [18:04] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  1386. # [18:05] * Quits: epeus (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  1387. # [18:05] * Joins: epeus (n=KevinMar@72.14.224.1)
  1388. # [18:05] <Philip`> "making HTML depend on HTTP-specific features sounds like A Bad Idea" - like <form method> and <a ping> and <eventsource> and so on?
  1389. # [18:06] * Quits: epeus (n=KevinMar@72.14.224.1) (Remote closed the connection)
  1390. # [18:07] * Quits: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
  1391. # [18:08] <yecril71> <A HREF="report" TYPE="application/pdf" >?
  1392. # [18:09] <Dashiva> I'm getting this intense feeling of deja vu here
  1393. # [18:09] <yecril71> BTW, what does METHOD=POST mean for non-HTTP?
  1394. # [18:10] <yecril71> Déja vu of what?
  1395. # [18:11] <ehird> yecril71: aaah!
  1396. # [18:11] <ehird> kill!
  1397. # [18:11] <yecril71> (except that METHOD=POST is a good way to avoid opening a HTA in IE)
  1398. # [18:11] <ehird> begon, clone of mookid!
  1399. # [18:12] <yecril71> Please, I only want to understand what is already supported.
  1400. # [18:12] <ehird> i was joking
  1401. # [18:12] <ehird> :)
  1402. # [18:13] <ehird> but, no
  1403. # [18:13] <ehird> that won't.
  1404. # [18:13] <Dashiva> (or was he? DUN DUN DUN)
  1405. # [18:13] <ehird> Dashiva: i am actually travelling to where yecril71 (aka MOOKID) is right now so that i may cut up his intestines
  1406. # [18:13] <ehird> ... only kidding! haha!
  1407. # [18:13] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  1408. # [18:13] <yecril71> Joking is a good thing when you are also willing to help.
  1409. # [18:13] <Dashiva> yecril71: The user agent can use the value as a hint if it wants to
  1410. # [18:14] <Dashiva> But as far as I know, none of the major browsers do
  1411. # [18:14] <Philip`> yecril71: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#form-submission-algorithm step 14 defines what it means in HTML5 for any protocol
  1412. # [18:14] * Joins: aboodman2 (n=aboodman@69.36.227.135)
  1413. # [18:14] <ehird> yecril71: i answered
  1414. # [18:14] <ehird> <ehird> but, no
  1415. # [18:14] <ehird> <ehird> that won't.
  1416. # [18:14] <ehird> re: <yecril71> <A HREF="report" TYPE="application/pdf" >?
  1417. # [18:15] <yecril71> I must have missed your answer
  1418. # [18:18] <yecril71> MSHTA treats GET file: as mutation.
  1419. # [18:19] <yecril71> I do not know about ftp.
  1420. # [18:19] <yecril71> Why is file: out of scope?
  1421. # [18:20] <yecril71> OTOH, it does not modify the URL for POST file:, which is good.
  1422. # [18:23] <Philip`> Oops, when I said "any protocol" I was lying
  1423. # [18:23] <yecril71> "Attributes don’t reflect" means that getAttribute returns the initial value specified.
  1424. # [18:24] <Philip`> yecril71: file: is out of scope because it's not considered an area where interoperability is needed, and UAs can just do whatever they want
  1425. # [18:25] <Philip`> (I'm not entirely sure how to argue for why interoperability isn't needed in that case, though)
  1426. # [18:27] <yecril71> Do you thing that METHOD=POST is a wrong thing overall?
  1427. # [18:27] <yecril71> s/thing/think/
  1428. # [18:27] <Philip`> Uh... No?
  1429. # [18:28] <yecril71> It works with HTTP only, and you are for separation of HTML and HTTP.
  1430. # [18:28] <Philip`> I'm not for separation of HTML and HTTP :-)
  1431. # [18:28] * Joins: aboodman3 (n=aboodman@69.36.227.135)
  1432. # [18:28] * Joins: sverrej (n=sverrej@cm-84.208.153.202.getinternet.no)
  1433. # [18:29] <yecril71> But here HTML depends on HTTP-specific features,
  1434. # [18:29] <yecril71> which is a bad thing, Philip` said.
  1435. # [18:29] <yecril71> I am trying to decipher that text.
  1436. # [18:31] * Quits: aboodman3 (n=aboodman@69.36.227.135) (Read error: 54 (Connection reset by peer))
  1437. # [18:31] <Philip`> Do you mean when I said
  1438. # [18:31] <Philip`> 17:00 < Philip`> "making HTML depend on HTTP-specific features sounds like A Bad Idea" - like <form method> and <a ping> and <eventsource> and so on?
  1439. # [18:31] <Philip`> ?
  1440. # [18:31] <ehird> yecril71: he was quoting
  1441. # [18:31] <ehird> and using sarcasm
  1442. # [18:31] <ehird> to rebut it :P
  1443. # [18:31] <Philip`> That was quoting jcranmer
  1444. # [18:32] * Philip` attempts to increase the ratio of technical discussion on public-html, by pointing out a couple of terribly exciting typos
  1445. # [18:32] <jcranmer> method is something that could be easily specifiable to not be protocol-dependent (in my eyes at least)
  1446. # [18:33] <jcranmer> I'm not a fan of <a ping> to be honest
  1447. # [18:33] <jcranmer> and I've not read up on <eventsource>
  1448. # [18:33] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
  1449. # [18:36] <yecril71> How would you POST to file:?
  1450. # [18:36] <ehird> replace the file, obviously :-P
  1451. # [18:36] <ehird> <form method="POST" action="/etc/passwd">
  1452. # [18:36] <yecril71> That is not POST, that is PUT
  1453. # [18:36] <ehird> well, true.
  1454. # [18:37] <ehird> but it'd amount to the same thing for file:, probably.
  1455. # [18:37] <yecril71> But it would be very different from what GET does,
  1456. # [18:37] <yecril71> whereas it is not that different for http:.
  1457. # [18:38] <jcranmer> get would be a URI composition
  1458. # [18:38] <yecril71> How do you POST a file to file:?
  1459. # [18:39] <yecril71> The exciting thing is POST, not GET.
  1460. # [18:39] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("This computer has gone to sleep")
  1461. # [18:39] <yecril71> GET is already covered, assuming file: is similar to ftp:.
  1462. # [18:40] <jcranmer> looks like Hixie disagrees with me on GET
  1463. # [18:40] <yecril71> What does look like that?
  1464. # [18:41] <jcranmer> a non-Flash, non-jemalloc-related FF crash?
  1465. # [18:42] <yecril71> Am I getting every sixth message or what?
  1466. # [18:50] * Quits: aboodman2 (n=aboodman@69.36.227.135) (Read error: 110 (Connection timed out))
  1467. # [18:53] * Joins: maikmerten (n=maikmert@La123.l.pppool.de)
  1468. # [18:55] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  1469. # [19:05] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Remote closed the connection)
  1470. # [19:05] <yecril71> All right, I got your point with GET.
  1471. # [19:06] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  1472. # [19:17] * Joins: Lachy (n=Lachlan@85.196.122.246)
  1473. # [19:25] * Joins: dimich (n=dimich@72.14.227.1)
  1474. # [19:28] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  1475. # [19:31] <takkaria> christ, it's obviously troll season at the moment
  1476. # [19:33] <yecril71> I cannot see any at the moment.
  1477. # [19:35] * Joins: epeus (n=KevinMar@207.47.11.2.static.nextweb.net)
  1478. # [19:36] * Philip` sees that occam has a keyword that is defined as performing an infinite loop
  1479. # [19:37] <Philip`> which seems a peculiar but perfectly sensible thing to do
  1480. # [19:37] * aroben is now known as aroben|away
  1481. # [19:40] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  1482. # [19:41] <takkaria> I assume you can break out of it?
  1483. # [19:46] * Quits: csarven (i=nevrasc@univcomm-allison-gm606-37.Concordia.CA) (Read error: 110 (Connection timed out))
  1484. # [19:47] * Joins: nessy (n=nessy@124-171-15-183.dyn.iinet.net.au)
  1485. # [19:48] * Joins: csarven (i=nevrasc@univcomm-allison-gm606-37.Concordia.CA)
  1486. # [19:51] * Quits: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  1487. # [19:51] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  1488. # [19:51] <tndH> eh, 36 emails since yesterday
  1489. # [19:51] <tndH> and i went to bed at 2 :|
  1490. # [19:57] * Quits: webben (n=webben@nat/yahoo/x-158770da8ff656d6) (Read error: 104 (Connection reset by peer))
  1491. # [19:57] * Joins: blooberry (n=brian@c-76-126-199-19.hsd1.ca.comcast.net)
  1492. # [19:57] * Joins: webben (n=webben@nat/yahoo/x-f81d4c84c487c068)
  1493. # [19:59] <yecril71> If a resource with alternative formats gets updated,
  1494. # [19:59] <yecril71> all formats should be updated and not just one.
  1495. # [20:00] <yecril71> Where "updated" can mean "removed until someone handles it".
  1496. # [20:00] <yecril71> That is the publisher’s responsibility and it can be enforced by the server.
  1497. # [20:02] <yecril71> However, the mechanisms of updating resources are often different from the mechanisms of viewing it.
  1498. # [20:03] <yecril71> And that includes the URL, e.g. update ftp:, get http:.
  1499. # [20:06] * Joins: roc (n=roc@121-72-175-254.dsl.telstraclear.net)
  1500. # [20:08] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  1501. # [20:15] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  1502. # [20:18] * Quits: jwalden (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  1503. # [20:19] <Philip`> takkaria: No
  1504. # [20:20] <Philip`> takkaria: but the language is designed to run stuff in parallel
  1505. # [20:20] <Philip`> so all you're doing is sending one thread into an infinite loop
  1506. # [20:20] <Philip`> which is observationally identical to terminating the thread
  1507. # [20:20] <Philip`> (because it'll just stop outputting anything)
  1508. # [20:21] <Philip`> (hence the keyword is "STOP")
  1509. # [20:26] <hallvors> TAG fed the trolls..
  1510. # [20:32] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  1511. # [20:40] * Joins: aboodman3 (n=aboodman@nat/google/x-465968b26009d2c2)
  1512. # [20:41] * aboodman3 is now known as aboodman2
  1513. # [20:41] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  1514. # [20:41] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  1515. # [20:41] * Joins: jwalden_ (n=waldo@guest-225.mountainview.mozilla.com)
  1516. # [20:41] * jwalden_ is now known as jwalden
  1517. # [20:41] * Quits: epeus (n=KevinMar@207.47.11.2.static.nextweb.net) ("The computer fell asleep")
  1518. # [20:42] <takkaria> Philip`: heh
  1519. # [20:44] <takkaria> yecril71: see, all formats should be updated, but not all will be, always. and whilst a server *can* enforce this, it requires someone going out of their way to write code to do that, and as such will probably not be enforced most of the time
  1520. # [20:48] * Quits: nessy (n=nessy@124-171-15-183.dyn.iinet.net.au) (Remote closed the connection)
  1521. # [20:48] * Joins: nessy (n=nessy@124-171-15-183.dyn.iinet.net.au)
  1522. # [20:55] * Joins: andyhargreaves (n=ahargrea@andyhargreaves.plus.com)
  1523. # [21:02] <yecril71> Providing alternative representations already is going out of one’s way already.
  1524. # [21:02] <yecril71> Once you decide to do that, you should make sure you have all the tools necessary to maintain this setup.
  1525. # [21:03] * Parts: andyhargreaves (n=ahargrea@andyhargreaves.plus.com)
  1526. # [21:12] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  1527. # [21:12] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  1528. # [21:15] * Joins: aaronlev_ (n=chatzill@e180226059.adsl.alicedsl.de)
  1529. # [21:15] * aaronlev_ is now known as aaronlev
  1530. # [21:16] <webben> Can anyone remember whether the problem with http://lists.w3.org/Archives/Public/public-html/2008Aug/0116.html was CSS generated text (content: "TODO") or just a border?
  1531. # [21:17] <webben> wayback doesn't seem to have captured the relevant CSS
  1532. # [21:21] * Quits: roc (n=roc@121-72-175-254.dsl.telstraclear.net)
  1533. # [21:28] * Joins: hsivonen_ (n=hsivonen@kekkonen.cs.hut.fi)
  1534. # [21:29] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (Remote closed the connection)
  1535. # [21:33] * Quits: aaronlev (n=chatzill@e180226059.adsl.alicedsl.de) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  1536. # [21:36] <Philip`> In practice, if you have multiple formats for some resource, you'd quite possibly want to do the format conversion asynchronously as a batch operation rather than blocking the person who's doing the uploading while your really slow video transcoding / PDF OCRing / etc process goes on
  1537. # [21:37] <Philip`> and so invalidating the cache at the moment of upload is not sufficient, since you'll need to invalidate all the other formats at some unknown time in the future
  1538. # [21:39] <Philip`> webben: I'm pretty sure the CSS generated content was added ages ago, long before that email
  1539. # [21:40] <Philip`> Maybe gsnedders could add non-CSS generated content support into Anolis :-)
  1540. # [21:40] <gsnedders> Philip`: For what?
  1541. # [21:41] <gsnedders> Philip`: I have feedback from Hixie about the ** stuff, and doing stuff to issues
  1542. # [21:41] <Philip`> gsnedders: For the places where the spec currently uses CSS to add content:"Note" and content:"Warning" etc, since that's not just stylistic information and it means some UAs can't distinguish those notes/warnings
  1543. # [21:42] <Philip`> *can't distinguish from plain text
  1544. # [21:42] <gsnedders> Philip`: Yeah' I have an email from Hixie detailing what he wants there
  1545. # [21:42] <gsnedders> s/'/,/
  1546. # [21:42] <Philip`> gsnedders: Okay
  1547. # [21:42] <Philip`> webben: Blame gsnedders for not fixing it yet :-)
  1548. # [21:43] <gsnedders> Blame Apple for making a laptop that broke slowing me down :)
  1549. # [21:44] <Philip`> That's your fault for buying shoddy hardware
  1550. # [21:44] <Philip`> You should have got a Dell
  1551. # [21:46] <Philip`> Also you should have got a RAIL setup, so you have a hot-spare laptop to fall back on if one breaks
  1552. # [21:47] <gsnedders> Philip`: Buy me one. :P
  1553. # [21:47] <Philip`> Don't try shifting the blame!
  1554. # [21:49] <Dashiva> I wonder if the people complaining about DOM are aware that the charter includes DOM APIs
  1555. # [21:50] <gsnedders> Our charter doesn't :P
  1556. # [21:52] <Philip`> Be careful about arguing based on what the charter says, because other people might start doing the same when arguing against you on other issues :-)
  1557. # [21:52] <Dashiva> Are we talking about the same charter?
  1558. # [21:53] * Philip` assumes gsnedders was making some point about WHATWG vs HTML WG
  1559. # [21:53] <gsnedders> Dashiva: Philip` understands me better than you.
  1560. # [21:54] <Dashiva> A charter that nobody lawyers about isn't interesting :)
  1561. # [21:56] * Quits: maikmerten (n=maikmert@La123.l.pppool.de) (Remote closed the connection)
  1562. # [22:00] * hsivonen_ wishes the charter didn't have earmarks
  1563. # [22:00] <hsivonen_> hmm. probably not the right political word
  1564. # [22:03] <Philip`> Maybe "riders"?
  1565. # [22:04] <hsivonen_> Philip`: that's the word I was looking for, yes
  1566. # [22:04] <hsivonen_> thanks
  1567. # [22:05] * Joins: roc (n=roc@202.0.36.64)
  1568. # [22:07] * Joins: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com)
  1569. # [22:11] * aroben|away is now known as aroben
  1570. # [22:15] * Joins: weinig (n=weinig@17.203.15.152)
  1571. # [22:17] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  1572. # [22:37] * Quits: heycam (n=cam@210-84-56-87.dyn.iinet.net.au) ("bye")
  1573. # [22:37] * Quits: weinig (n=weinig@17.203.15.152)
  1574. # [22:38] * Joins: weinig (n=weinig@17.203.15.152)
  1575. # [23:01] * Quits: ap (n=ap@195.239.126.12)
  1576. # [23:14] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  1577. # [23:15] <hallvors> does anyone know documentation for differences in capabilities in IE between an XMLHttpRequest object created with ActiveXObject() and a native XMLHttpRequest() object?
  1578. # [23:16] <hallvors> if that's hard to parse: it turns out that the object returned from "new XMLHttpRequest()" and "new ActiveXObject('MSXML2.XMLHTTP.3.0')" have different capabilities. I'd like to know if this is known/documented.
  1579. # [23:18] * Quits: csarven (i=nevrasc@univcomm-allison-gm606-37.Concordia.CA) (Read error: 60 (Operation timed out))
  1580. # [23:18] <gsnedders> hallvors: IIRC they return exactly the same thing )the native object is just a wrapper)
  1581. # [23:29] <Hixie> hm, burns is late with his trolls. he hasn't said anything since sunday.
  1582. # [23:29] <Hixie> maybe he can only troll on weekends now.
  1583. # [23:29] <Hixie> i wonder if he'll ever reply to http://lists.w3.org/Archives/Public/public-html/2008Nov/0161.html
  1584. # [23:30] <blooberry> hallvors: using the ActiveXObject method requests a specific instantiation of a particular object. I believe there were previous iterations of xmlhttp? So, it makes sense that there might be some differences depending on which ActiveXObject you are requesting to create. The question I would have is: is there a version string for ActiveXObject that has the same behavior as new XMLHttpRequest? That would probably indicate which ActiveXO
  1585. # [23:30] <blooberry> using as its default.
  1586. # [23:30] * Quits: weinig (n=weinig@17.203.15.152)
  1587. # [23:30] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.84 [Firefox 3.1b2pre/20081117020249]")
  1588. # [23:46] <Lachy> Hixie, apparently, according to the comments in the forum, a new version of Requiem 1.8.2 has been released.
  1589. # [23:47] <Lachy> I'm still waiting for my copy of freenet to update the download page for me before I can get it
  1590. # [23:49] * Philip` suggests using the web to download it instead
  1591. # [23:51] * Quits: smerp (n=smerp@66.192.95.199) ("Jesus Built My Workstation")
  1592. # [23:52] <Lachy> Philip`, I would, but I can't find it elsewhere on the web yet
  1593. # [23:52] * Quits: pergj (n=pergj@65.219.59.50) (Read error: 110 (Connection timed out))
  1594. # [23:55] * Joins: pergj (n=pergj@65.219.59.140)
  1595. # [23:56] * Joins: weinig (n=weinig@17.203.15.152)
  1596. # [23:57] <Philip`> Is there anything to stop some random person releasing a file on Freenet and claiming it's a new version of Requiem?
  1597. # [23:58] <takkaria> hashes?
  1598. # [23:59] <Lachy> they could, but only Brahms is able to update the official Requiem page with the links to the files
  1599. # Session Close: Wed Nov 19 00:00:00 2008

The end :)