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

Options:

  1. # Session Start: Wed Nov 19 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:00] <Lachy> so if you found a link to the file from elsewhere, you could be fooled into downloading the wrong file, but that's the same with anything.
  4. # [00:00] <hallvors> gsnedders, blooberry: I have a brand new test case where IE only supports xhr.open('SEARCH', ...) if the XHR object is created with the ActiveX call. Weird, and I have no idea why.
  5. # [00:09] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  6. # [00:09] <blooberry> hallvors: that is odd. Did you see if there are any other ActiveX strings that would work for XHR?
  7. # [00:11] <hallvors> since the next TC I wrote actually froze IE (IE8 beta2, that is) I haven't gotten much further yet, no :-p
  8. # [00:11] <Hixie> Lachy: i'm still on 1.7.x
  9. # [00:11] <Hixie> Lachy: but good to know :-)
  10. # [00:11] <Hixie> Lachy: any idea what it adds?
  11. # [00:12] <blooberry> hallvors: 8-}
  12. # [00:20] <hallvors> fun. tried all the identifiers from http://en.wikipedia.org/wiki/XMLHttpRequest
  13. # [00:20] <hallvors> they all work. only "new XMLHttpRequest()" makes it fail
  14. # [00:24] <Lachy> Hixie, I don't know yet. It probably adds windows support
  15. # [00:25] <Hixie> ah ok
  16. # [00:25] <Lachy> yeah, it does. My freenet node has updated now
  17. # [00:25] * Hixie finds his mac is crashing on loginwindow on startup now
  18. # [00:25] <Hixie> wtf
  19. # [00:25] <blooberry> hallvors: I would have expected ActiveXObject to be the more restrictive specification method as MS has had the most probs with that tech over the years.
  20. # [00:26] * Quits: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  21. # [00:30] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  22. # [00:30] <hallvors> If they have started limiting what HTTP verbs you're allowed to use it's pretty interesting. Especially since Outlook Web Access uses lots of funky verbs including SEARCH. The OWA team might not like IE8... :p
  23. # [00:31] * Joins: jwalden_ (n=waldo@corp-241.mountainview.mozilla.com)
  24. # [00:31] <takkaria> they'll be in IE7mode, I bet
  25. # [00:34] * Joins: csarven (n=csarven@modemcable150.182-202-24.mc.videotron.ca)
  26. # [00:34] * Quits: jwalden (n=waldo@guest-225.mountainview.mozilla.com) (Nick collision from services.)
  27. # [00:35] * Parts: billmason (n=bmason@ip41.unival.com)
  28. # [00:35] * jwalden_ is now known as jwalden
  29. # [00:36] * Quits: sverrej (n=sverrej@cm-84.208.153.202.getinternet.no) (Read error: 60 (Operation timed out))
  30. # [00:36] * Joins: sverrej (n=sverrej@cm-84.208.153.202.getinternet.no)
  31. # [00:42] * Joins: doublec (n=chris@202.0.36.64)
  32. # [00:43] * Joins: tantek (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
  33. # [00:46] * Quits: eric_carlson (n=ericc@17.203.15.222)
  34. # [00:48] * Quits: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) ("Leaving")
  35. # [00:50] * aroben is now known as aroben|away
  36. # [00:59] * Quits: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com) (Read error: 60 (Operation timed out))
  37. # [01:06] * Quits: jwalden (n=waldo@corp-241.mountainview.mozilla.com) ("->reboot")
  38. # [01:13] * Joins: jwalden (n=waldo@corp-241.mountainview.mozilla.com)
  39. # [01:41] * Joins: pergj_ (n=pergj@65.219.59.50)
  40. # [01:44] * Quits: dglazkov (n=dglazkov@nat/google/x-e1c22b6c74229501)
  41. # [01:45] <hallvors> where did TimBL speak about "change in philosophy" from "improving the web" to "letting it fester while describing it" as one of his concerns about HTML5? I'm writing a blog post and trying to find the source of that quote.. #-]
  42. # [01:47] <Philip`> hallvors: http://www.w3.org/2001/tag/2008/09/23-minutes ?
  43. # [01:47] <Philip`> (It doesn't seem clear whether that's his own opinion, or him reporting other people's apparent opinions)
  44. # [01:50] <hallvors> thanks!
  45. # [01:50] <hallvors> 2001 in the URL?! didn't realise it was such an ancient quote
  46. # [01:50] <Philip`> 2008 is in the URL too
  47. # [01:50] <ehird> TAG started 2001
  48. # [01:50] <ehird> talk was 2008
  49. # [01:50] <hallvors> right. cool URIs must confuse
  50. # [01:51] <hallvors> :p
  51. # [01:51] <ehird> indeed.
  52. # [01:51] <ehird> /1995/news for stuff happening in 2130 makes soo much sense
  53. # [01:51] <ehird> very durable :p
  54. # [01:51] <Hixie> are you mocking the web's architecture?
  55. # [01:52] <Hixie> careful, you might get in trouble!
  56. # [01:52] * ehird gets mauled.
  57. # [01:52] <ehird> By web owls.
  58. # [01:52] * Quits: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  59. # [01:53] <ehird> They're just like regular owls, except they sting you with cool URIs and... um... resource talons.
  60. # [01:57] * Quits: pergj (n=pergj@65.219.59.140) (Read error: 110 (Connection timed out))
  61. # [01:59] * Joins: olliej (n=oliver@219.89.238.104)
  62. # [02:02] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  63. # [02:12] <hallvors> URLs are just the UI of HTTP. As all UIs they are a pretty bad compromise between what a human can get used to and what a computer can understand.
  64. # [02:28] * Quits: hallvors (n=hallvord@cm-84.208.78.204.getinternet.no)
  65. # [02:36] <jwalden> "modularized"?
  66. # [02:36] <jwalden> sigh
  67. # [02:37] * Quits: webben (n=webben@nat/yahoo/x-f81d4c84c487c068) (Read error: 145 (Connection timed out))
  68. # [02:38] <jwalden> oh, it gets worse, they mention E4X
  69. # [02:39] <jwalden> apparently not seriously, tho, which is a relief
  70. # [02:42] <Philip`> Wasn't it just hsivonen_ who mentioned E4X?
  71. # [02:42] <jwalden> possibly, I don't know who any of these people are except the one obvious one and DanC
  72. # [02:47] * Joins: tantek_ (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
  73. # [02:48] * Quits: csarven (n=csarven@modemcable150.182-202-24.mc.videotron.ca) ("http://www.csarven.ca")
  74. # [02:48] * Joins: csarven (n=csarven@modemcable150.182-202-24.mc.videotron.ca)
  75. # [02:52] * Joins: psa (n=yomode@71.93.19.66)
  76. # [02:55] * Joins: aboodman3 (n=aboodman@69.36.227.131)
  77. # [03:00] * Quits: weinig (n=weinig@17.203.15.152)
  78. # [03:04] * Quits: tantek (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  79. # [03:08] * Quits: aboodman2 (n=aboodman@nat/google/x-465968b26009d2c2) (Read error: 110 (Connection timed out))
  80. # [03:14] * Quits: dave_levin (n=levin@72.14.227.1)
  81. # [03:15] * Quits: pergj_ (n=pergj@65.219.59.50) (Read error: 110 (Connection timed out))
  82. # [03:20] * Quits: aboodman3 (n=aboodman@69.36.227.131) (Read error: 110 (Connection timed out))
  83. # [03:24] * Quits: tantek_ (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
  84. # [03:29] * Joins: aboodman3 (n=aboodman@69.36.227.131)
  85. # [03:30] * aboodman3 is now known as aboodman2
  86. # [03:39] * aroben|away is now known as aroben
  87. # [03:44] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 113 (No route to host))
  88. # [03:45] * Joins: dave_levin (n=levin@98.203.247.78)
  89. # [03:45] * Quits: dave_levin (n=levin@98.203.247.78) (Client Quit)
  90. # [03:46] * Joins: dave_levin (n=levin@98.203.247.78)
  91. # [03:46] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  92. # [03:47] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  93. # [03:53] <MikeSmith> http://www.w3.org/QA/2008/06/shipbuilding.html#c169011
  94. # [03:54] <MikeSmith> Dmitry Turin: "Western world does not interested in implementation of progressive ideas, because Indian slaves have been executing job for Western world free of charge"... "Nobody allow me to kill his investments, even it's investment into frankly nonsense (you guessed, what term i implied)"... "P.S. >to produce standards that actually get implemented"
  95. # [03:57] <MikeSmith> I think I like the old mostly just quixotic and relatively conspiracy-theory-free Dmitry Turin better than this one
  96. # [03:57] <MikeSmith> but you do have to give him credit in that even when he thinks conspiracy theory, he thinks big and goes all the way
  97. # [03:58] * Parts: dave_levin (n=levin@98.203.247.78)
  98. # [03:58] <MikeSmith> e.g, the entire Western world vs. his ideas
  99. # [04:00] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  100. # [04:05] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net) (Read error: 113 (No route to host))
  101. # [04:05] * Quits: MikeSmith (n=MikeSmit@W182171.ppp.dion.ne.jp) ("sex break")
  102. # [04:06] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  103. # [04:06] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  104. # [04:12] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  105. # [04:16] * Quits: aboodman2 (n=aboodman@69.36.227.131) (Read error: 110 (Connection timed out))
  106. # [04:17] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  107. # [04:23] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  108. # [04:25] * Quits: olliej (n=oliver@219.89.238.104)
  109. # [04:26] * Quits: jwalden (n=waldo@corp-241.mountainview.mozilla.com) (Remote closed the connection)
  110. # [04:32] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  111. # [04:32] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  112. # [04:33] * dglazkov_ is now known as dglazkov
  113. # [04:34] * Quits: sicking (n=chatzill@corp-242.mountainview.mozilla.com) (Remote closed the connection)
  114. # [04:39] * Joins: sicking (n=chatzill@corp-242.mountainview.mozilla.com)
  115. # [04:44] * Joins: MikeSmith (n=MikeSmit@EM114-48-138-38.pool.e-mobile.ne.jp)
  116. # [04:45] * Joins: jwalden (n=waldo@c-67-180-39-55.hsd1.ca.comcast.net)
  117. # [04:53] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  118. # [05:06] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  119. # [05:11] * Quits: dimich (n=dimich@72.14.227.1)
  120. # [05:18] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 131 (Connection reset by peer))
  121. # [05:45] * Quits: dglazkov (n=dglazkov@72.14.224.1)
  122. # [05:45] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  123. # [05:46] * Quits: doublec (n=chris@202.0.36.64) ("Leaving")
  124. # [05:48] * Joins: dave_levin (n=levin@72.14.224.1)
  125. # [05:51] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  126. # [05:57] * Quits: roc (n=roc@202.0.36.64)
  127. # [06:13] * Joins: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  128. # [06:21] * Quits: MikeSmith (n=MikeSmit@EM114-48-138-38.pool.e-mobile.ne.jp) ("sex break")
  129. # [06:23] * Joins: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com)
  130. # [06:24] * Joins: heycam (n=cam@210-84-56-87.dyn.iinet.net.au)
  131. # [06:35] * Joins: MikeSmith (n=MikeSmit@dhcp-246-124.mag.keio.ac.jp)
  132. # [06:47] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  133. # [07:18] * Joins: sicking_ (n=chatzill@63.245.220.242)
  134. # [07:19] * Joins: hdh (n=hdh@58.187.60.23)
  135. # [07:19] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
  136. # [07:21] * Joins: epeus (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  137. # [07:22] * Joins: gavin (n=gavin@people.mozilla.com)
  138. # [07:29] * Joins: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net)
  139. # [07:35] * Quits: sicking (n=chatzill@corp-242.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
  140. # [07:46] * Joins: maikmerten (n=merten@129.217.26.195)
  141. # [08:35] * Quits: csarven (n=csarven@modemcable150.182-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  142. # [08:37] <Hixie> aw, all the threads died out
  143. # [08:38] * Joins: ap (n=ap@195.239.126.11)
  144. # [08:39] * Quits: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
  145. # [08:46] * Joins: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk)
  146. # [08:50] * Quits: aboodman2 (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
  147. # [08:50] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  148. # [08:59] <Hixie> i guess it makes sense that roy would stop responding after i showed an interest in listening to his feedback
  149. # [08:59] <Hixie> since that would break his world view of us being people who ignore his feedback
  150. # [09:10] * Joins: aaronlev (n=chatzill@e180226059.adsl.alicedsl.de)
  151. # [09:10] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  152. # [09:21] * Joins: Hish (n=chatzill@mail2.n-e-s.de)
  153. # [09:21] * Joins: pesl (n=retep@procurios.xs4all.nl)
  154. # [09:25] <Hixie> where's Philip`'s static copy of the whatwg issues list at again?
  155. # [09:31] * Quits: dimich (n=dimich@c-98-203-230-54.hsd1.wa.comcast.net)
  156. # [09:33] * Joins: olliej (n=oliver@219.89.238.104)
  157. # [09:38] * Joins: tthorsen (n=tommy@home.kvaleberg.no)
  158. # [09:44] * Quits: sverrej (n=sverrej@cm-84.208.153.202.getinternet.no) (No route to host)
  159. # [09:51] <Philip`> Hixie: http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/
  160. # [09:51] <Hixie> thanks
  161. # [10:01] * Quits: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk) (Read error: 110 (Connection timed out))
  162. # [10:03] * Quits: aaronlev (n=chatzill@e180226059.adsl.alicedsl.de) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  163. # [10:08] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  164. # [10:11] * Joins: aaronlev (n=chatzill@e180226059.adsl.alicedsl.de)
  165. # [10:31] * Joins: roc (n=roc@121-72-187-20.dsl.telstraclear.net)
  166. # [10:41] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  167. # [10:48] * Joins: webben (n=webben@nat/yahoo/x-7fd4b562695acef7)
  168. # [11:00] * Joins: ROBOd (n=robod@89.122.216.38)
  169. # [11:10] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  170. # [11:10] * Quits: MikeSmith (n=MikeSmit@dhcp-246-124.mag.keio.ac.jp) ("sex break")
  171. # [11:14] <hsivonen_> it feels weird that rickg's dated comments in nsIParser and friends are now over ten years old
  172. # [11:15] * Joins: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  173. # [11:15] <yecril71> If a script exhausts browser resources, an exception should be thrown.
  174. # [11:16] <yecril71> (unless the failing action is known to be discardable)
  175. # [11:19] <yecril71> We can define that the HTML token "red" really means "blue",
  176. # [11:19] <yecril71> but I am afraid this is going to cause many misunderstandings.
  177. # [11:22] <yecril71> rel="rev-made" is not very good.
  178. # [11:22] <hsivonen_> yecril71: consider what danbri said about changing author to creator in DC. it wasn't about changing the concept but about effective bikeshedding the English word
  179. # [11:22] <yecril71> rel="made-me" sounds much better.
  180. # [11:22] <yecril71> or rel="made-by".
  181. # [11:22] <Philip`> Where is rev=made defined?
  182. # [11:23] <yecril71> Lynx documentation.
  183. # [11:23] <Philip`> Is there something more like a spec where it's defined?
  184. # [11:24] <yecril71> The only problem with removing rev is that Lynx uses it.
  185. # [11:24] <hsivonen_> for all practical purposes, rev=made is an ancient Lynx-only feature
  186. # [11:25] <hsivonen_> yecril71: we've made IE-only UI-only stuff non-conforming, too.
  187. # [11:26] <yecril71> I thought it was sort a political decision, IE being the equivalent of Dr. No?
  188. # [11:27] <yecril71> Whereas Lynx, as it is used by disabled people, should be treated with some condescending?
  189. # [11:28] <Philip`> More disabled people use IE than any other browser, from what I've heard
  190. # [11:30] * Joins: hallvors (n=hallvord@cm-84.208.78.204.getinternet.no)
  191. # [11:31] <yecril71> There are various disabilities, perhaps IE is good for some of them?
  192. # [11:32] <yecril71> Using numbers in this context is rather dangerous.
  193. # [11:33] <yecril71> Most of the people are not disabled.
  194. # [11:35] <mookid> Hi fans
  195. # [11:35] <yecril71> Hi chief
  196. # [11:41] <mookid> well the email barrage dried up which is a shame!
  197. # [11:43] * Joins: ap_ (n=ap@195.239.126.12)
  198. # [11:43] <yecril71> Time to catch up with things
  199. # [11:46] <yecril71> a rel="in-reply-to" is nonsense.
  200. # [11:47] <yecril71> It can be used as LINK[rel="in-reply-to"] only, to describe this document.
  201. # [11:50] <yecril71> And that would mean THAT document is in reply to THIS document.
  202. # [11:52] <yecril71> In this sense, rel="made" and rev="made" have the same meaning.
  203. # [11:53] <yecril71> rel="made" means THAT made THIS
  204. # [11:53] <yecril71> and so does rev="made".
  205. # [11:53] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  206. # [11:54] <Hixie> i think you misunderstand how rev="" was meant to work
  207. # [11:54] <Hixie> but it's academic
  208. # [11:54] <Hixie> since rev="" is gone now
  209. # [11:57] <zcorpan> hsivonen_: here's a feature request that i tried to implement myself but gave up before having a proof of concept impl...
  210. # [11:57] <zcorpan> hsivonen_: have the messages inline with the source
  211. # [11:58] * Quits: ap (n=ap@195.239.126.11) (Read error: 110 (Connection timed out))
  212. # [11:58] <yecril71> I think we can all agree that LINK[rel="next"] means THAT is next to THIS.
  213. # [11:59] <yecril71> So LINK[rel="made"] means THAT made THIS, doesn’t it?
  214. # [11:59] <zcorpan> hsivonen_: so that you get e.g.
  215. # [11:59] <zcorpan> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> ↩
  216. # [11:59] <zcorpan> 1. Error: Almost standards mode doctype. Expected <!DOCTYPE html>.
  217. # [11:59] <zcorpan> <html>↩
  218. # [11:59] <zcorpan> <head>↩
  219. # [11:59] <zcorpan> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">↩
  220. # [11:59] <zcorpan> 2. Error: The internal character encoding declaration must be the first child of the head element.
  221. # [11:59] <zcorpan> etc
  222. # [12:00] <zcorpan> if there are multiple errors on the same line you have multiple messages for that line
  223. # [12:02] <zcorpan> i tried implementing it by walking unsortedOl and doing a regexp on the location para to get the line and then inserting the message into the line-minus-one-th child of the source ol
  224. # [12:02] <yecril71> I was just trying to figure out what LINK[rel="banana"] would mean.
  225. # [12:02] <yecril71> THAT is MY banana?
  226. # [12:02] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  227. # [12:03] <hsivonen_> zcorpan: I think that could be a UI improvement, yes.
  228. # [12:03] <hsivonen_> IIRC, PageValet had something along those lines a few years ago.
  229. # [12:05] <hsivonen_> zcorpan: btw, in case you're wondering about the slow reaction to your recent bug reports, it's because I'm trying to reach a particular calendar goal with HTML5 parsing in Gecko. I'll get back to Validator.nu bugs in due course.
  230. # [12:05] <zcorpan> hsivonen_: no worries
  231. # [12:06] <Hixie> yecril71: it means whatever we define it to mean, these keywords are opaque strings
  232. # [12:06] <Hixie> ok bed time
  233. # [12:06] <Hixie> nn
  234. # [12:06] <zcorpan> i'm used to Hixie's rate of response i.e. somewhere between immediately and a few years :)
  235. # [12:07] * Quits: olliej (n=oliver@219.89.238.104)
  236. # [12:08] <yecril71> But we cannot define rel="banana" to mean something unrelated to bananas.
  237. # [12:08] <hsivonen_> yecril71: yes, we can.
  238. # [12:08] <yecril71> But it would be confusing to the authors.
  239. # [12:08] <hsivonen_> yecril71: yes
  240. # [12:09] <yecril71> I think it is not an accident that the HEAD tag was not renamed QWERTY.
  241. # [12:09] <yecril71> Although QWERTY would be much easier to type.
  242. # [12:10] <hsivonen_> yecril71: there's value in names that make sense, yes.
  243. # [12:12] * zcorpan thinks head is easier to type than qwerty
  244. # [12:13] <hsivonen_> Hixie: do I understand correctly that it's possible for document.close() to cause previously document.written data to be discarded?
  245. # [12:14] * hsivonen_ tries it
  246. # [12:16] <zcorpan> hsivonen_: do you want me to file a bug about the feature request?
  247. # [12:16] <hsivonen_> zcorpan: preferably, yes
  248. # [12:16] <yecril71> To me, document.close() means that any subsequent document.write() rewrites the document.
  249. # [12:17] <hsivonen_> yecril71: yes, but as far as I can tell, document.close() closes the stream, but the spec says it puts an explicit EOF at insertion point, which seems wrong.
  250. # [12:17] <yecril71> The previous content is discarded only at document.write().
  251. # [12:17] <hsivonen_> consider
  252. # [12:17] <hsivonen_> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3Edocument.write(%22%3Cscript%3Edocument.write(%27a%27)%3Bdocument.close()%3B%3C\%2Fscript%3EEND%22)%3B%3C%2Fscript%3E
  253. # [12:19] <yecril71> I am unable to evaluate that in Internet Explorer.
  254. # [12:19] <hsivonen_> I'm starting Windows now, but Firefox, Opera and Safari all agree
  255. # [12:19] <yecril71> Takes 94% CPU.
  256. # [12:20] <Hixie> hsivonen_: oh it should probably insert it at the end of the stream
  257. # [12:20] <hsivonen_> Hixie: right. I'll send email.
  258. # [12:20] <zcorpan> hsivonen_: filed. fyi i got the internal error message again (worked fine the last few times)
  259. # [12:20] <Hixie> hsivonen_: didn't think of testing nested document.close() in document.write(), but i'm sure the web does it somewhere :-)
  260. # [12:20] <hsivonen_> zcorpan: thanks. (I still have no clue about the error.)
  261. # [12:20] * hsivonen_ is now known as hsivonen
  262. # [12:21] * Hixie hacked the xcode demo npapi plugin today to output the parameters passed to the plugin
  263. # [12:21] <Hixie> mac only, sadly
  264. # [12:21] <Hixie> but should help spec out what safari and firefox do for <embed> a bit better
  265. # [12:21] <zcorpan> Hixie: that would be useful
  266. # [12:22] <Hixie> for some reason it crashes when i use <object> in firefox
  267. # [12:22] <Hixie> (not in safari)
  268. # [12:22] <Hixie> no idea how to debug that
  269. # [12:22] <hsivonen> the IE8 XSS filter is really annoying with the live dom viewer
  270. # [12:22] <Hixie> and i dunno how to make opera accept a plugin
  271. # [12:23] <Hixie> it doesn't seem to use the plugins in the Internet Plugins directory
  272. # [12:24] <hsivonen> yay. it indeed freezes IE8 beta2
  273. # [12:25] <Hixie> how odd
  274. # [12:25] <Hixie> i wonder why
  275. # [12:26] * Quits: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  276. # [12:26] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  277. # [12:27] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  278. # [12:44] <hsivonen> I guess I disagree with Dr. Hoffmann about CURIEs
  279. # [12:49] * Joins: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  280. # [12:51] * Quits: heycam (n=cam@210-84-56-87.dyn.iinet.net.au) ("bye")
  281. # [12:57] <hallvors> Hixie: add something relevant to plugin path in opera6.ini
  282. # [12:59] <zcorpan> Hixie: it's supposed to look in /Library/Internet Plug-Ins
  283. # [12:59] <hallvors> well.. that's on Windows, I don't really know on Mac. Sorry.
  284. # [13:20] <Philip`> hsivonen: Hixie could modify the Live DOM Viewer to add a header to disable IE8's XSS filter
  285. # [13:24] <hallvors> yes, I suggested that on IRC a while ago. the header is X-XSS-Protection: 0
  286. # [13:26] <hsivonen> http://twitter.com/drawohara/statuses/1012168434
  287. # [13:27] <hsivonen> is "the shite" a praise while "shite" isn't?
  288. # [13:27] * Joins: yecril71 (n=giecrilj@piekna-gts.2a.pl)
  289. # [13:27] <BenMillard> hsivonen, it can be
  290. # [13:28] <Philip`> hallvors: http://www.google.com/search?q=site:krijnhoetmer.nl+x-xss-protection suggests it was only me that suggested it on IRC around here :-)
  291. # [13:28] <hsivonen> BenMillard: ok. tweeted spec feedback could be less ambiguous :-)
  292. # [13:31] <takkaria> I think that twitter is missing a "the", but yeah, seems like praise
  293. # [13:32] <hsivonen> takkaria: I thought it was missing "are"
  294. # [13:35] * Joins: aaronlev_ (n=chatzill@e180226059.adsl.alicedsl.de)
  295. # [13:35] <Philip`> http://www.urbandictionary.com/define.php?term=the+shit is seemingly the intended meaning, not http://www.urbandictionary.com/define.php?term=the+shite
  296. # [13:35] * Quits: nessy (n=nessy@124-171-15-183.dyn.iinet.net.au) ("This computer has gone to sleep")
  297. # [13:36] * Quits: aaronlev (n=chatzill@e180226059.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  298. # [13:36] * aaronlev_ is now known as aaronlev
  299. # [13:37] <yecril71> I believe that keywords like rel="author" should be left in English.
  300. # [13:37] <yecril71> They are not meant to be directly visible to the human reader.
  301. # [13:38] <BenMillard> Philip`, looks more like vandalism to me.
  302. # [13:39] <BenMillard> (especially considering the extremely small number of votes)
  303. # [13:42] <Philip`> Hmph, and I thought Urban Dictionary was a trustworthy source :-(
  304. # [13:42] <takkaria> hsivonen: uh,yeah,you're right
  305. # [13:44] <Dashiva> Mr. Last Week seems to be on the ball for once
  306. # [13:45] <Philip`> Hmm, the OED doesn't seem to have the positive definition at all - it just has the dirty ones, and notes "Not now in decent use."
  307. # [13:45] * hsivonen notes that the W3C is funded by its corporate masters
  308. # [13:45] * Quits: webben (n=webben@nat/yahoo/x-7fd4b562695acef7) (Read error: 110 (Connection timed out))
  309. # [13:45] <Philip`> Dashiva: Like one of those people at the circus who does clever balancing tricks but often falls off?
  310. # [13:46] <hsivonen> http://www.w3.org/2008/07/ogws-cfp
  311. # [13:46] <Dashiva> Philip`: Yes, and much entertainment is had by all
  312. # [13:48] * Parts: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  313. # [13:49] <hallvors> Philip`: http://krijnhoetmer.nl/irc-logs/whatwg/20081008#l-608 :)
  314. # [13:50] <Philip`> hallvors: Oh, right :-)
  315. # [13:50] <Philip`> Maybe I should have read the logs I was pointing at
  316. # [13:58] * Joins: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp)
  317. # [14:01] * Quits: maikmerten (n=merten@129.217.26.195) (Client Quit)
  318. # [14:04] * Joins: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl)
  319. # [14:08] * Joins: hdh0 (n=hdh@58.187.62.96)
  320. # [14:10] <zcorpan> hsivonen: i tried my bookmarklet on http://html5.validator.nu/?doc=http%3A%2F%2Fgoogle.se&showsource=yes and it looks really nice... except for "<body bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b alink=#ff0000 onload="sf();if(document.images)new Image().src='/images/nav_logo3.png'" topmargin=3 marginheight=3>"
  321. # [14:10] <zcorpan> but i'm not sure that's worth optimizing
  322. # [14:12] <hsivonen> zcorpan: I don't follow. Which bookmarklet?
  323. # [14:12] <zcorpan> hsivonen: sorry, in the bug. http://bugzilla.validator.nu/show_bug.cgi?id=325
  324. # [14:16] <hsivonen> zcorpan: cool! I think it need more styling to distinguish messages and source quotes.
  325. # [14:16] <zcorpan> hsivonen: yeah
  326. # [14:17] <zcorpan> hsivonen: perhaps insert the <li> instead
  327. # [14:18] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  328. # [14:20] <hsivonen> I wonder if were feasible to make the source text take 50% of available width and make the messages float into the other 50% of available width and draw a line from the error highlight to the error message CSS box
  329. # [14:21] * Joins: virtuelv (n=virtuelv@213.236.208.247)
  330. # [14:22] <zcorpan> interesting idea... not sure it would be better though :)
  331. # [14:22] * Quits: hdh (n=hdh@58.187.60.23) (Read error: 110 (Connection timed out))
  332. # [14:23] <hsivonen> Hixie: what do you suggest for block annotations inserted into inline content?
  333. # [14:23] <hsivonen> in terms of content model conformance
  334. # [14:23] <hsivonen> I think there's a use case here :-)
  335. # [14:25] <yecril71> If you want to indicate a representation, you can use A[type="application/pdf"].
  336. # [14:25] <yecril71> There is no need to introduce A[accept].
  337. # [14:28] <yecril71> Developers can rig their browsers with all extensions they consider valuable.
  338. # [14:28] <mookid> erm
  339. # [14:28] <mookid> no.
  340. # [14:28] <mookid> maybe if your web app serves a couple of ted in ashed companies
  341. # [14:28] <mookid> ted in a shed*
  342. # [14:29] <mookid> designing enterprise level web applications you need standards
  343. # [14:29] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  344. # [14:29] <mookid> not to mention development frameworks
  345. # [14:30] <yecril71> The standard, as it is, reflects what developers are unwilling to do.
  346. # [14:30] <mookid> type doesn't perform that function btw
  347. # [14:30] <yecril71> Why not?
  348. # [14:30] <mookid> ..?
  349. # [14:30] <zcorpan> hsivonen: you just have to split the elements (<b>s and <code>s) in the parent chain until the current element is <li> and then insert a new <ol> there
  350. # [14:31] <hsivonen> zcorpan: ok
  351. # [14:31] <mookid> yecril71: did you read that email I just sent out?
  352. # [14:31] <yecril71> Why isn’t the type attribute good for the purpose?
  353. # [14:31] <yecril71> I am just reading it.
  354. # [14:33] <yecril71> "Getting involved" is not that easy.
  355. # [14:34] * Joins: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  356. # [14:34] <yecril71> I would consider myself happy if I could get involved.
  357. # [14:34] <yecril71> And you surely cannot get involved in everything.
  358. # [14:34] <yecril71> Not because you do not have enough time, because of the trade secrets.
  359. # [14:36] <mookid> well no but the only reason I can find not to do this is "it's too much work"
  360. # [14:36] <yecril71> HTML is not hypermedia, HMML is :-)
  361. # [14:36] <mookid> whatever :P
  362. # [14:37] <mookid> u get the point =)
  363. # [14:37] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  364. # [14:37] <mookid> a PDF is not the same thing as an HTML document.
  365. # [14:37] <yecril71> The problem is that it does not help that you are willing to help.
  366. # [14:38] <mookid> well I don't mind not being able to do the work provided someone else does it
  367. # [14:38] <hsivonen> mookid: PDF, ODF, OOXML and .doc can have hyperlinks to HTTP resources. Do you classify them as hypermedia formats?
  368. # [14:38] <mookid> I still ahvent' been given a good reason why this would not be beneficial
  369. # [14:39] <mookid> they will be eventually they aren't used for that currently
  370. # [14:39] <mookid> hsivonen: ^
  371. # [14:39] <yecril71> It seems nobody is going to work on it.
  372. # [14:39] <mookid> oh great.
  373. # [14:39] <mookid> well at least we have video tags!
  374. # [14:40] <hsivonen> mookid: you have been given reasons why what you are suggesting is bad. Presumably you are classifying the reasons as not "good" reasons.
  375. # [14:40] <mookid> no I havent at all
  376. # [14:40] <mookid> what are those reasons?
  377. # [14:40] <hsivonen> see the logs from yesterday
  378. # [14:40] <mookid> I read them
  379. # [14:41] <jcranmer> mookid: can you name one drawback of your feature?
  380. # [14:41] <mookid> if you look at the conversations I'm having on the mailling list.. I'm constantly repeating myself and referring back to stuff I've already said - just explained differently because peopel aren't comprehending what I'm saying
  381. # [14:41] <yecril71> Nobody is going to free Tibet, or Tuva.
  382. # [14:42] <yecril71> Or cease cutting the rainforest.
  383. # [14:42] <yecril71> There are more dire things to be worried about.
  384. # [14:42] <mookid> my skulls tougher than alot of brick walsl
  385. # [14:42] <jcranmer> I'll take that as a `no'
  386. # [14:42] <mookid> actually there arent - better interoperability of internet applications is paramount to the human race
  387. # [14:43] <mookid> -_-
  388. # [14:43] <hsivonen> mookid: have you considered the possibility that conneg might be a hindrance to interop?
  389. # [14:43] <jcranmer> why do people think that new features come without costs?
  390. # [14:43] <mookid> ITS NOT A NEW FEATURE
  391. # [14:43] <mookid> it's part of the protocol
  392. # [14:43] <mookid> jesus.
  393. # [14:44] <Dashiva> And browsers support it
  394. # [14:44] <hsivonen> mookid: you are suggesting that something be added. ergo, new feature.
  395. # [14:44] <mookid> no they don;t.. javacsript virtual machines do
  396. # [14:44] <jcranmer> mookid: you're adding a feature to HTML
  397. # [14:44] <mookid> I'm "adding" something that should already be there
  398. # [14:44] <jcranmer> you're still adding
  399. # [14:44] <mookid> oh great
  400. # [14:44] <mookid> ok well I guess when the slaves all came along asking for freedom
  401. # [14:44] <mookid> we should've been like
  402. # [14:44] <mookid> you know what
  403. # [14:44] <mookid> I'm busy right now
  404. # [14:45] <mookid> BYE
  405. # [14:45] <yecril71> We shall overcome, some day.
  406. # [14:45] <mookid> Why would I want to free you anyway?? I make lots of money from cheap labour.
  407. # [14:46] <yecril71> That’s my boy.
  408. # [14:46] <mookid> that's a "rational" defense against freeing slaves
  409. # [14:46] <mookid> is it not?
  410. # [14:46] <yecril71> Of course it is.
  411. # [14:46] <mookid> perspective.
  412. # [14:46] * Joins: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk)
  413. # [14:46] <yecril71> You are on the ridge of being plonked.
  414. # [14:46] <mookid> translate..!
  415. # [14:47] <yecril71> killfiled.
  416. # [14:47] <Dashiva> HTTP headers do not have human rights
  417. # [14:47] <Dashiva> Oddly enough
  418. # [14:47] <mookid> really?
  419. # [14:47] <hsivonen> mookid: are you implying that using the Accept header is a moral or human right issue?
  420. # [14:47] <mookid> no it was an analogy
  421. # [14:47] <yecril71> HTTP headers have headerly rights.
  422. # [14:48] <mookid> you know.. the kind of thing you use when you're battling ignorance -_-
  423. # [14:48] <Dashiva> Analogies are like statistics, 87% of them are made up on the spot.
  424. # [14:48] <mookid> yeah it was mostly a joke anyway relax
  425. # [14:49] <mookid> so.. about the problems.. what were they again?
  426. # [14:49] <Philip`> Dashiva: I won't trust your statistics unless you make up a standard deviation too
  427. # [14:49] <hsivonen> mookid: http://krijnhoetmer.nl/irc-logs/whatwg/20081118#l-822
  428. # [14:50] <mookid> oh dear oh dear
  429. # [14:50] <mookid> you see a URI - and your immediate reaction is that it needs to go through a browser
  430. # [14:50] <yecril71> My mediaeval English is not good enough
  431. # [14:50] <Dashiva> Philip`: Maybe that's what I want you to think
  432. # [14:51] <yecril71> but the weapon is called epée in French.
  433. # [14:51] <mookid> There is no pair there at all - if I want to get a resource.. I put the URI into the appropriate UA
  434. # [14:51] <mookid> there's no pairing there at all
  435. # [14:52] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  436. # [14:52] <yecril71> OK, it is rapier in English.
  437. # [14:53] <mookid> this is my point - you have your subjective opinion on what a URI should do
  438. # [14:53] <hsivonen> mookid: and you don't?
  439. # [14:53] <mookid> and your projecting it onto developers by restricting the capabilites of browsers
  440. # [14:53] <mookid> I don't know which is 'better' - I just know I want to make good use of HTTP
  441. # [14:53] * Joins: aaronlev_ (n=chatzill@f051115131.adsl.alicedsl.de)
  442. # [14:54] <mookid> I can't do that in a brwoser unless you support it
  443. # [14:54] <mookid> that's why I suggested it as optional
  444. # [14:54] <Dashiva> You want to make the internet worse for everyone else
  445. # [14:54] <mookid> fuck off
  446. # [14:54] <yecril71> The video tag is not an evidence of hypermedialness.
  447. # [14:54] <mookid> excuse my language
  448. # [14:54] <yecril71> It is evidence for compositeness.
  449. # [14:55] <yecril71> Are you suffering from Turette’s?
  450. # [14:55] <mookid> every time this discussion gets interesting it goes quiet..
  451. # [14:55] <yecril71> PDF can embed video in exactly the same way.
  452. # [14:56] * Philip` sees that Martin McEvoy chooses to interpret the statistics to say that only 0.09% of pages use rev=stylesheet, instead of to say that of the pages that use rev and don't use rev=made (which is redundant with rel=author), 57% use it for rev=stylesheet
  453. # [14:56] <mookid> hsivonen: so...
  454. # [14:57] <mookid> I don't know exactly what a URI should do.. but I'm sure that restricting client capabilities to use HTTP will lead it down one way when there is another available
  455. # [14:57] <mookid> which is why I dont consider "well that's the way its done" an acceptable response
  456. # [14:58] <mookid> and neither should you.
  457. # [14:59] <Dashiva> Have you produced an answer for "Why should the page author control what my user agent wants to accept on my behalf?" yet?
  458. # [14:59] <yecril71> The client is free to use HTTP as it sees fit, within the framework of the HTTP specification.
  459. # [15:00] <mookid> Dashiva: what? how is that any different from specifying the content-type in the URI ?
  460. # [15:00] <Dashiva> mookid: Because that's just a URI, my browser can still Accept: whatever it wants
  461. # [15:00] <mookid> how is saying <a href="foo.pdf">>link</a> not doing that?
  462. # [15:00] <mookid> you don't understand Accept then
  463. # [15:00] <mookid> Accept is an indicator
  464. # [15:01] <mookid> it's not a fixed contract
  465. # [15:01] * Joins: webben (n=webben@nat/yahoo/x-a5d1de62edf271dc)
  466. # [15:01] <mookid> the server can return whatever content-type it wants
  467. # [15:01] <yecril71> If you specify the content type in the URL, it is there.
  468. # [15:01] <yecril71> Otherwise, it is not there.
  469. # [15:01] <yecril71> That is the difference.
  470. # [15:01] <mookid> er, ok
  471. # [15:01] <mookid> :D
  472. # [15:01] <Dashiva> mookid: Accept is a header the user agent controls. The URI is something the server controls. They should stick to their own. It's simple, isn't it?
  473. # [15:02] <mookid> no.. you misunderstand the purpose of accept
  474. # [15:02] <mookid> Accept does nothing at the moment in browsers
  475. # [15:02] <mookid> it's just a catchall essentially
  476. # [15:02] <mookid> it may aswell not be there
  477. # [15:02] <yecril71> Why is it a problem for HTML?
  478. # [15:02] <Dashiva> Okay, that shows how much you know
  479. # [15:03] <mookid> because HTML is how the browser traverses HTTP
  480. # [15:03] <yecril71> The browser does not traverse HTTP at all.
  481. # [15:03] <mookid> you know what I mean - dont be pedantic
  482. # [15:04] <mookid> traverses URIs over HTTP
  483. # [15:04] <yecril71> My guess is that the browser uses HTTP to get data.
  484. # [15:04] <mookid> it's the way that brwosers do HTTP
  485. # [15:04] <yecril71> It does not traverse URIs.
  486. # [15:04] <mookid> yes it does - what is a browser for if it's not for movign around URIs ?
  487. # [15:05] <yecril71> The browser is for surfing the Web.
  488. # [15:05] <yecril71> (or browsing, if you prefer).
  489. # [15:05] <mookid> lay off the crack
  490. # [15:05] <Dashiva> mookid: How about you get a packet sniffer and look at what Accept headers browsers actually send
  491. # [15:06] <yecril71> (Actually, Microsoft’s documentation nowhere says what Internet Explorer is for).
  492. # [15:06] <yecril71> (It only says how cute it is.)
  493. # [15:06] <mookid> they send a long string of preferences.. and then a */* at the end..
  494. # [15:06] <mookid> so it really makes no differences
  495. # [15:06] <mookid> particularly when, by all of your own admission, it doesnt make a difference because each URI should only serve one content-type
  496. # [15:07] <yecril71> Why is this a problem for HTML?
  497. # [15:07] <Dashiva> Sure, but it lets hardliners like you do it still
  498. # [15:07] <Dashiva> So everyone can be happy
  499. # [15:07] <mookid> what?
  500. # [15:07] <mookid> I'm not 'hard lining' I'm doing the opposite
  501. # [15:08] <Dashiva> You're going on and on about a feature we already have
  502. # [15:08] <mookid> the future we already have?
  503. # [15:08] <mookid> pwahahaha
  504. # [15:08] <Dashiva> For no reason but theoretical purity
  505. # [15:08] <mookid> theoretical purity?
  506. # [15:08] <mookid> your a joke.
  507. # [15:08] <mookid> if that's literally the only criticism you have
  508. # [15:08] <mookid> you're seriously scraping the bottom of the barrel
  509. # [15:10] <jcranmer> Philip`: anyone can use the same stastics to support their case
  510. # [15:10] <yecril71> HTTP is a standard protocol for transmitting HTML documents.
  511. # [15:10] * hallvors mangles Opera's support for window.setTimeout() if and only if it's called on nytimes.com from the NYTD.require() method.
  512. # [15:10] <mookid> you're trolling yecril71 :)
  513. # [15:10] <yecril71> Not the other way round.
  514. # [15:10] <mookid> HTTP has nothing to do with HTML
  515. # [15:10] <mookid> what about
  516. # [15:10] <yecril71> I am replying to your letter.
  517. # [15:10] <mookid> RSS
  518. # [15:11] <mookid> Atom
  519. # [15:11] <mookid> xml
  520. # [15:11] <mookid> pdf
  521. # [15:11] <yecril71> They are document formats, IIRC.
  522. # [15:11] <hsivonen> hallvors: how do you undo a patch like that when the site fixes itself?
  523. # [15:11] <Dashiva> browserjs, probably
  524. # [15:11] <hsivonen> hallvors: or how do site owners test their fix?
  525. # [15:11] <mookid> hsivonen: why did you not continue that discussion before?
  526. # [15:12] <hsivonen> mookid: I have work to do
  527. # [15:12] <mookid> oooh
  528. # [15:12] <mookid> i see
  529. # [15:12] <jcranmer> Philip`: yet my reaction was the same as yours upon seeing those states
  530. # [15:12] <jcranmer> s/te/t/
  531. # [15:12] <jcranmer> "rev=stylesheet is by far the most used rev link"
  532. # [15:13] * Joins: pergj_ (n=pergj@dhcp206-59-244-238.ssb.sjc.wayport.net)
  533. # [15:14] <yecril71> HTTP is not limited to HTML, but if you want to expose HTTP, you rather choose HTTP to do the job.
  534. # [15:14] * Quits: aaronlev (n=chatzill@e180226059.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  535. # [15:14] <yecril71> If you want to expose HTML, you choose HTTP.
  536. # [15:14] <Philip`> jcranmer: No it's not - rev=made is the most used rev link
  537. # [15:14] <krijnh> I send all my pages to my customers as email attachments
  538. # [15:15] <hallvors> hsivonen: undoing it is as simple as releasing a new browser.js update without that code. Getting site owners to test with opera:config#Browser%20JavaScript set to 0 is somewhat trickier, I admit.. :-o
  539. # [15:15] <hsivonen> hallvors: ok
  540. # [15:16] <jcranmer> Philip`: must have missed that, then
  541. # [15:16] <yecril71> I presume the customers publish krijnh’s pages themselves?
  542. # [15:17] <krijnh> No, they email me, "Hi, I want info about your company" and then I send them back an HTML page with that info
  543. # [15:17] <krijnh> Fuck HTTP
  544. # [15:18] <yecril71> That is rather peculiar, I would say.
  545. # [15:19] <jcranmer> yecril71: needless to say, people send HTML email a fair amount
  546. # [15:19] <yecril71> Sending is not exposing.
  547. # [15:20] <yecril71> All right, in today’s world it is, but it is another story :-(
  548. # [15:21] <yecril71> HTML does not support content negotiation at all, in URIs or not in URIs.
  549. # [15:22] <yecril71> Except maybe for A[type].
  550. # [15:22] <yecril71> User agents can, and perhaps should, support content negotiation.
  551. # [15:22] <yecril71> But that has nothing to do with HTML.
  552. # [15:23] <Philip`> krijnh: That sounds like Richard Stallman's approach
  553. # [15:24] <yecril71> HTML, as a markup language, does not make use of URIs, it only contains them here and there.
  554. # [15:24] <yecril71> Indeed, being a language, it does not make use of anything.
  555. # [15:26] <yecril71> Actually, SVG tiger is untimately smaller than PNG tiger.
  556. # [15:28] <yecril71> ultimately
  557. # [15:29] <yecril71> You can have multiple e-mail addresses in rev="made
  558. # [15:29] <Philip`> Not if you resize the PNG to be really small
  559. # [15:30] <yecril71> SVG is ultimately smaller.
  560. # [15:30] <Philip`> yecril71: How do you put multiple email addresses in it?
  561. # [15:30] <ehird> but is it AWESOMELY smaller?!
  562. # [15:30] <Philip`> yecril71: I bet I can make a 1x1-pixel PNG of the tiger that's smaller than the SVG version
  563. # [15:31] <yecril71> mailto:a1@example.com;a2@example.com
  564. # [15:31] <yecril71> But it is not an equivalent representation any more.
  565. # [15:33] * Joins: virtuelv_ (n=virtuelv@pat-tdc.opera.com)
  566. # [15:35] <Philip`> Quite a few people just seem to put their names in the href attribute
  567. # [15:38] <Philip`> yecril71: If a PNG is ever equivalent to an SVG, where is the threshold at which a resized n*n version of the PNG is no longer equivalent to the SVG?
  568. # [15:39] <yecril71> There are various measures.
  569. # [15:39] <yecril71> Quantitative: the spectrum of the histogram.
  570. # [15:39] <yecril71> Qualitative, if B/W:
  571. # [15:40] <yecril71> Graph isomorphism.
  572. # [15:40] <yecril71> The threshold depends on how complicated the image is.
  573. # [15:41] <mookid> if they represent the same image it's the same resource -_-
  574. # [15:41] <yecril71> Fractals cannot be represented as PNG at all.
  575. # [15:42] <Philip`> "Lachy[...] knows more about HTML5 than almost anyone else which is why he's the right guy to write the authoring guide." - hmm, that sounds to me like a reason why he shouldn't write it, because he won't understand HTML5 from the perspective of a typical ignorant developer :-)
  576. # [15:43] <Philip`> mookid: If I have a PNG image and a thumbnail version of it, those are two representations of the same resource?
  577. # [15:44] <Philip`> If so, does HTTP provide any way to request the desired representation from the same URI?
  578. # [15:44] <Lachy> Philip`, where's that quote from?
  579. # [15:44] * Lachy was an ignorant developer once, so I'm more than qualified :-)
  580. # [15:45] <Philip`> Lachy: http://www.w3.org/mid/49241573.8080003@dean.org.nz
  581. # [15:45] <Lachy> ok
  582. # [15:45] <yecril71> The content type can contain image resolution as an option
  583. # [15:45] * Quits: virtuelv (n=virtuelv@213.236.208.247) (Read error: 113 (No route to host))
  584. # [15:47] <Philip`> Ah, so I can do "Accept: image/png;size=little;q=1"? I suppose that sounds vaguely reasonable
  585. # [15:48] <yecril71> I cannot give you the details, check it up with the registry.
  586. # [15:48] <yecril71> The resolution should be explicit IIRC.
  587. # [15:49] * Joins: danbri_ (n=danbri@ip565f6edb.direct-adsl.nl)
  588. # [15:51] <mookid> Philip`: a thumbnail is a seperate resource right
  589. # [15:51] * Joins: danbri__ (n=danbri@ip565f6edb.direct-adsl.nl)
  590. # [15:52] <mookid> example.com/dog/thumbnail
  591. # [15:53] <Philip`> mookid: Hmm, I don't quite see what makes it a separate resource, since it seems to be representing the same image
  592. # [15:53] <mookid> it's a seperate image - it's a thumbnail of the real image
  593. # [15:54] <Philip`> But a JPEG and a PNG are different representations of the same image (if and only if they decode to the same number of pixels)?
  594. # [15:55] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  595. # [15:55] * Philip` isn't sure where the distinction lies
  596. # [15:55] <mookid> why would they be a different size?
  597. # [15:55] <mookid> well the distinction lies in what the entity is..
  598. # [15:55] <jcranmer> but JPEG is lossy and PNG is lossless
  599. # [15:55] <mookid> a thumbnail isn't the image.. that's why it's a thumbnail of the image..
  600. # [15:56] <mookid> yeah - they're different representation of the same image
  601. # [15:56] <Philip`> mookid: One might be a low-resolution lossy JPEG, and the other a high-resolution lossless PNG
  602. # [15:57] <mookid> what's your point?
  603. # [15:57] <Philip`> (so people might decide which to download based on the speed of their internet connection, because otherwise they're basically the same image)
  604. # [15:57] <mookid> ..?
  605. # [15:58] * Quits: danbri (n=danbri@unaffiliated/danbri) (Read error: 110 (Connection timed out))
  606. # [15:58] * Quits: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  607. # [15:59] <mookid> Sorry, I dont understand the point you're trying to make dude
  608. # [15:59] <Philip`> mookid: My point is to try to understand why if I have a low-resolution lossy JPEG (which could act as a thumbnail) and a high-resolution lossless PNG, you seem to be saying they are different resources; but if I have equally-sized JPEG and PNGs, they're just different representations of the same resource
  609. # [16:00] <mookid> That's a design descision obviously
  610. # [16:00] <mookid> there's nothign stopping you from resizing the image
  611. # [16:00] <Philip`> I'm not attempting to prove anything, I just want to get a better understanding of what a resource is, since it seems a bit vague at the moment
  612. # [16:00] <mookid> and specifying Accept jpeg
  613. # [16:00] <mookid> for your thumbnails..
  614. # [16:00] <mookid> that's application design though right?!
  615. # [16:01] <mookid> well resource is supposed to be vague - that's the poitn I'm trying to get across - you need to be able to accuotn for everyone's interpretation
  616. # [16:02] <mookid> some people think resources are tied to a singl representation for each URI
  617. # [16:02] <mookid> which is fine.. but some people don't and that is the reason Accept exists
  618. # [16:02] * Philip` doesn't like things being vague :-(
  619. # [16:02] <mookid> vague is the wrong word..
  620. # [16:03] <mookid> abstract is better
  621. # [16:03] <Philip`> I wouldn't mind if people had different specific technical interpretations of what a "resource" is, as long as they could each define it, and then we could give them all different names to make it clearer and then it wouldn't be confusing
  622. # [16:03] * Joins: Mustafa51 (n=mustafa@122.164.161.140)
  623. # [16:04] <mookid> it is defined in fielding's disseratation - there's plenty ofpapers written abuot it
  624. # [16:06] * Parts: blooberry (n=brian@c-76-126-199-19.hsd1.ca.comcast.net)
  625. # [16:06] <yecril71> Web authors are not going to read that.
  626. # [16:07] <yecril71> You have to come up with something short to recount and easy to grasp.
  627. # [16:07] <mookid> do yuo have to say things?
  628. # [16:07] <mookid> why dont you not say things..
  629. # [16:07] <mookid> try that out
  630. # [16:07] * Quits: danbri_ (n=danbri@unaffiliated/danbri) (Connection timed out)
  631. # [16:07] <Philip`> "a resource R is a temporally varying membership function M_R(t), which for time t maps to a set of entities, or values, which are equivalent." clears everything up ;-)
  632. # [16:08] <mookid> :P
  633. # [16:08] <mookid> that's explained better in th enext paragrpah by way of explaining the benefits
  634. # [16:08] * ap_ is now known as ap
  635. # [16:09] * Philip` wonders why M_R is defined and then seemingly never referred to again
  636. # [16:10] <Philip`> Maybe my concern is that it seems inadequate to use media type as the way to select a representation, since the media type is only meant to be identifying the data format of a representation and you might have multiple distinct representations of the same resource with the same data format
  637. # [16:11] <mookid> how would that work?
  638. # [16:11] <mookid> wtf was that? o.O
  639. # [16:12] <mookid> how would that work?
  640. # [16:13] <Philip`> I could represent my hypertext document as text/html with uppercase tag names, or as text/html with lowercase tag names, and they're distinct representations (since a representation is a sequence of bytes) with the same data format
  641. # [16:13] <mookid> page/uppercase + page/lowercase
  642. # [16:13] <mookid> seperate formats
  643. # [16:13] <mookid> formats
  644. # [16:13] <mookid> lol
  645. # [16:13] <mookid> seperate resoruces
  646. # [16:13] <mookid> not formats
  647. # [16:13] * Quits: ap (n=ap@195.239.126.12)
  648. # [16:14] <yecril71> page/uppercase is not registered
  649. # [16:14] <Philip`> But they're the same resource, just with different representations, and it's not nice if I have to pretend they're different resources to hack around HTTP's assumption that URI+media-type is adequate identification
  650. # [16:15] <Philip`> yecril71: I think page/uppercase is intended as a URI, not a media type
  651. # [16:15] <yecril71> you would have to register an option for text/html
  652. # [16:16] <Philip`> That sounds like an awful lot of work, and also impossible
  653. # [16:16] <yecril71> but what if you want every other letter to be capitalized?
  654. # [16:16] <Philip`> because the IETF is not going to listen to me saying "please register text/html;uppercase=yeah"
  655. # [16:16] <yecril71> are x-options allowed?
  656. # [16:16] <yecril71> It depends whether they deem it is important.
  657. # [16:17] <yecril71> In this particular case, it probably is not.
  658. # [16:17] <yecril71> And I would rather say "flavor=uppercase".
  659. # [16:19] * Joins: famicom (i=famicom@5ED2FF2D.cable.ziggo.nl)
  660. # [16:19] <Philip`> The media type is the wrong place for that information anyway, since it's not part of the data format - the data format is still just HTML
  661. # [16:20] <yecril71> I can imagine it can be essential for somebody to have it like that.
  662. # [16:21] * Joins: ap (n=ap@195.239.126.10)
  663. # [16:21] <yecril71> As a more real-world example, consider "linewidth=80" versus "indented=pretty".
  664. # [16:21] <Philip`> The aforementioned dissertation doesn't seem to say anything about how you only content-negotiate based on the data format, so I guess if you're using HTTP you should do "X-Accept-Uppercase-Tags: please" or something
  665. # [16:21] <mookid> are they the same resrouce though - it would have a different include for the css
  666. # [16:22] <Philip`> in which case simply adding "Accept" to HTML wouldn't be sufficient to do proper content negotiation, since that's restricted to negotiating the data format :-)
  667. # [16:23] <yecril71> I think all those things belong to the data format as options.
  668. # [16:23] <mookid> right - it's GUI stuff
  669. # [16:23] <mookid> you can do that with css and javascript
  670. # [16:23] * Joins: csarven (n=csarven@modemcable106.33-81-70.mc.videotron.ca)
  671. # [16:23] <mookid> that's design stuff again
  672. # [16:25] <yecril71> Do what with css and javascript?
  673. # [16:25] <yecril71> I can do everything with JavaScript because it is Turing-complete.
  674. # [16:25] <yecril71> And I am the king of gorillas.
  675. # [16:26] <mookid> this whole uppercase of the same page stuf that's apparently created a massive flaw in RESTful architecture
  676. # [16:26] <mookid> -_-
  677. # [16:26] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  678. # [16:27] <mookid> either way - some data is different between the two resources whether it's the css include or the ASCII values
  679. # [16:28] <mookid> how you approach that is a design descision - I shouldn't be the person to say one way is better than the other
  680. # [16:28] <mookid> the same way as I shouldn't be the person to say that using URIs is better one way or the other
  681. # [16:29] * Joins: aroben (n=aroben@c-71-58-97-175.hsd1.pa.comcast.net)
  682. # [16:29] <mookid> but neither should anyone else - we just need to support the standarsd (like HTTP) and let developers mak those descisions
  683. # [16:30] <mookid> that's the most pragmatic approach
  684. # [16:30] <mookid> Philip`: did some of the latest email make more sense - I only ask because you seem more intereted in my opinion now :p
  685. # [16:32] <yecril71> I am sorry to say most of id did not make sense.
  686. # [16:32] <yecril71> most of it
  687. # [16:33] <mookid> feel free to respond on tehmailing list
  688. # [16:33] <mookid> :)
  689. # [16:33] <yecril71> The problem is, I am sort of banned.
  690. # [16:33] <mookid> I can understand why
  691. # [16:33] * Joins: billmason (n=bmason@ip41.unival.com)
  692. # [16:34] <yecril71> Good for you.
  693. # [16:34] <mookid> yes it is.
  694. # [16:34] * Quits: pergj_ (n=pergj@dhcp206-59-244-238.ssb.sjc.wayport.net) (Read error: 113 (No route to host))
  695. # [16:35] <Philip`> mookid: The ASCII values are an artifact of the representation, not of the underlying conceptual resource - if I write <html> or <HTML> then it gets parsed by exactly the same parsing algorithm into exactly the same DOM, and the only difference is the bytes sent over the wire
  696. # [16:36] <Philip`> (I'm not uppercasing the textual content of the document, only the tag names)
  697. # [16:37] <Philip`> (which is a slightly pointless thing to do, but I'm sure there exist more plausible real-world cases for something like this :-p )
  698. # [16:37] <yecril71> Like linewidth=80 for example.
  699. # [16:38] <Philip`> mookid: I don't remember the latest email saying much that hadn't been said before; I'm just procrastinating by thinking out loud about some of this stuff :-)
  700. # [16:40] <Philip`> Also it's comforting to know that a PhD dissertation doesn't have to actually make sense
  701. # [16:42] <jmb> suits me :)
  702. # [16:42] <yecril71> Why is it comforting?
  703. # [16:42] * Quits: tthorsen (n=tommy@home.kvaleberg.no) ("Leaving")
  704. # [16:42] <jcranmer> who is it that wrote that nonsensical PhD
  705. # [16:42] <jcranmer> ?
  706. # [16:42] * Quits: virtuelv_ (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  707. # [16:43] <Philip`> jcranmer: Do you mean Roy Fielding's dissertation?
  708. # [16:43] <yecril71> It is rather depressing to me.
  709. # [16:43] <Philip`> jcranmer: If so, Roy Fielding wrote it
  710. # [16:44] <Philip`> yecril71: Because I need to write one, and so I'm happier if I think the bar is lowered :-)
  711. # [16:44] <yecril71> It is depressing because I know I am not shameless enough to follow that path :-(
  712. # [16:45] * Joins: maikmerten (n=merten@129.217.26.195)
  713. # [16:45] * Philip` has been working for a year and still doesn't quite know what his dissertation is going to be on, but never mind minor problems like that
  714. # [16:46] <mookid> well I'd be interested to hear these real world cases - and also how that relates to content type negotiation
  715. # [16:47] <jcranmer> ah
  716. # [16:48] <jcranmer> Bogdanov
  717. # [16:48] <jmb> Philip`: if it helps, it took me somewhere between 18 & 21 months to work out exactly what I was doing
  718. # [16:49] * Philip` notes that he is being mostly unfair in thinking that Roy Fielding's dissertation doesn't make sense, since he hasn't read it in much detail, but it does seem mostly like vague descriptions and post-hoc rationalisations, which isn't great, though it's kind of unavoidable because you can't set up two wildly popular world-wide network systems and evaluate the differences so you just have to guess
  719. # [16:50] * yecril71 has been working for half a year to learn that the unjustified assumptions his master’s thesis was based on actually can be defended
  720. # [16:52] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  721. # [16:52] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  722. # [16:52] * jgraham moans about people discussing PhDs here
  723. # [16:54] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  724. # [16:54] <Philip`> mookid: I think the not-quite-real-world cases still demonstrate that there is seemingly a disconnect between the abstract REST theory (where a resource has multiple representations and clients can negotiate which one they get) and practical suggestions for adding <a href accept="media-type"> (which is much more limited)
  725. # [16:55] <Philip`> so a good solution to the content negotiation issue should do much more than simply Accept
  726. # [16:56] <Philip`> and would have to allow arbitrary X-... HTTP headers, because that's the only mechanism that lets you properly implement content negotiation
  727. # [16:58] <Philip`> Anyway, real PhD dissertations should just be full of maths rather than woolly words
  728. # [16:58] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  729. # [17:00] * jgraham suspects that depends somewhat on your thesis topic
  730. # [17:00] * Philip` is actually trying to avoid the maths as much as possible, because it's scary
  731. # [17:00] <mookid> Philip`: The accept header would be one component of that
  732. # [17:01] <mookid> why would it not make sense to at least provide the mechanism for that even if it is 'incomplete'
  733. # [17:02] <mookid> beyond that you are getting into additions to the HTTP spec
  734. # [17:02] <Philip`> How come nobody has commented yet on the <link rev="D. Bailey Management" ...> and <link rev="YouTube" ...> and <link rev="text/css" ...> and so on? Those are far more fun than simply mixing rev and rel
  735. # [17:03] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Client Quit)
  736. # [17:03] <Philip`> mookid: HTTP already explicitly allows extension header fields for server-driven content negotiation
  737. # [17:04] <Philip`> so it wouldn't need additions
  738. # [17:04] * Quits: maikmerten (n=merten@129.217.26.195) (Remote closed the connection)
  739. # [17:04] <mookid> right - but that's for use in special cases
  740. # [17:04] <mookid> Accept is a standard
  741. # [17:04] <mookid> specific standard
  742. # [17:04] <mookid> I suppose you could go as far as to provide a header attribute instead
  743. # [17:05] <Philip`> There are four other specific standard non-extension header fields that it mentions for negotiation
  744. # [17:05] * Joins: dbaron (n=dbaron@c-71-204-144-136.hsd1.ca.comcast.net)
  745. # [17:05] <mookid> content-encoding?
  746. # [17:05] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  747. # [17:05] <mookid> user-agent ?
  748. # [17:06] <Philip`> Accept-{Charset,Encoding,Language}, User-Agent
  749. # [17:06] <mookid> user-agent I'd say is pretty irrelevant for obvious reasons
  750. # [17:07] <mookid> but sure these could also be accounted for
  751. # [17:07] <Philip`> If the problem is that you want to expose control over HTTP content negotiation to HTML pages, then Accept by itself is not a solution to that problem
  752. # [17:07] <mookid> well it's the most useful
  753. # [17:07] <mookid> by far
  754. # [17:08] <mookid> multiple content-types is the most common variation on resource representation
  755. # [17:08] <mookid> I take your point though, maybe it makes sense to ammend my proposal to include all of these
  756. # [17:08] * Quits: myakura (n=myakura@p4200-ipbf2306marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  757. # [17:09] <mookid> or even just a header attribute
  758. # [17:09] <mookid> this is more like it, though thanks for your input :)
  759. # [17:10] * Philip` is just trying to make the proposed feature more and more complex, so it's easier to kill it later for being too bloated ;-)
  760. # [17:10] <mookid> haha I did suspect ;P
  761. # [17:10] <mookid> is there no way we can work at this to make it feasible?
  762. # [17:11] <mookid> who can I work through the nitty-gritty with ?
  763. # [17:12] <mookid> I don't think it has to be that bloated necessarily, HTTP isn't a really bloated protocol
  764. # [17:12] <mookid> it's certianly no SOAP.
  765. # [17:13] * Joins: eric_carlson_ (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  766. # [17:16] <hsivonen> http://lists.w3.org/Archives/Public/www-html/2006Feb/0069.html
  767. # [17:16] <hsivonen> last paragraph in particular
  768. # [17:17] <hsivonen> and http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/009732.html
  769. # [17:18] <jgraham> mookid: Are you still looking for a way to specify http accept on a link? It seems to me that that, apart from any theoretical issues has significant compatibility issues since it would cause new browsers to return different documents to old browsers
  770. # [17:19] <Philip`> mookid: Given that you don't seem too concerned about supporting e.g. Accept-Charset, I assume you agree that "it is a feature of HTTP, therefore it must be exposed via HTML" is not a convincing argument, because sometimes nobody cares enough about that feature of HTTP to be worth the effort
  771. # [17:19] <mookid> but you're assuming nobody cares becasue noone has the ability to
  772. # [17:19] <mookid> I addressed this
  773. # [17:20] <mookid> that's an unwinnable argument purely on the basis that it's not practical *at the moment*
  774. # [17:20] <mookid> that's the reason I've brought this up
  775. # [17:20] <mookid> to change it so it is feasible..
  776. # [17:20] <Philip`> mookid: But you seem to care about Accept and not about Accept-Charset, even though you can't control either via HTML
  777. # [17:20] * Quits: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Read error: 110 (Connection timed out))
  778. # [17:20] <mookid> in a way which doesn't effect existing implementations
  779. # [17:20] <mookid> right and I've said I'm happy to loko at including that aswell
  780. # [17:20] <mookid> content-type is by far the most common cocnern
  781. # [17:21] <jgraham> mookid: Is this directed at me? I don't understand how one could implement the feature so that it didn't break existing implementations
  782. # [17:21] <mookid> if that's going to make the difference then I am more than happy to include them in my proposal
  783. # [17:21] <hsivonen> mookid: here's the thing is short: If you care about which representation you are linking to, the choice of representation isn't indifferent to you and you need to address a particular representation. We already have an addressing mechanism: URL.
  784. # [17:21] <mookid> jgraham: becaue it's an option attribute
  785. # [17:21] <jgraham> fwiw I also agree with hsivonen
  786. # [17:21] <hsivonen> mookid: so whenever you care about linking to a particular representation, you really have two resources
  787. # [17:21] <mookid> THATS ONE APPROACH
  788. # [17:22] <mookid> I know
  789. # [17:22] <mookid> you can use
  790. # [17:22] <mookid> URLs
  791. # [17:22] <mookid> to do that
  792. # [17:22] <Philip`> mookid: So when looking at something like Accept-Charset, we should consider the possible costs (of language complexity and implementation effort and everything else) and the possible benefits (like what it would enable people to do) in order to decide whether it's worthwhile?
  793. # [17:22] <hsivonen> mookid: if you had only one resource, you by definition wouldn't have to care about linking to a particular representation
  794. # [17:22] <mookid> what?
  795. # [17:22] <mookid> what is this 'link' you talk abuot
  796. # [17:22] <mookid> it's a request
  797. # [17:22] <hsivonen> (aside: it may follow that with this definition, the set of resources with multiple representations is the empty set. If so, so be it.)
  798. # [17:22] <mookid> and a request is more than just GET (URI)
  799. # [17:23] <mookid> thre are headers
  800. # [17:23] <mookid> for a reason
  801. # [17:23] <jgraham> mookid: ? So how does that change the fact that if I do <a href="foo" accept="application/pdf"> a new browser will return a PDF and an old one will not?
  802. # [17:23] <mookid> in my application
  803. # [17:23] <mookid> that's a design descision
  804. # [17:23] <mookid> old applications will continue to work fine
  805. # [17:23] <mookid> with new browsers
  806. # [17:23] <hsivonen> mookid: link is the <a> element with your proposed attribute
  807. # [17:23] <mookid> jgraham: your response to that is..?
  808. # [17:24] <jgraham> You mean you are happy if different users get different representations of the resource?
  809. # [17:24] <mookid> yes - they're just representations
  810. # [17:24] <jgraham> Are your users also happy with that?
  811. # [17:24] <jgraham> I guess not
  812. # [17:24] <mookid> of course I am
  813. # [17:24] <mookid> it's a diffrent way of using URIs
  814. # [17:24] <mookid> which you clearly dont *think* is the 'right' way
  815. # [17:24] <hsivonen> mookid: well then you don't need to specify the accept header in your <a> element!
  816. # [17:25] <mookid> it's not 'right' it's just a way
  817. # [17:25] <mookid> hsivonen: yeah you do
  818. # [17:25] <mookid> of course you do
  819. # [17:25] <jgraham> I would be extremely confused as an end user if clicking the same link consistently returned an HTML document in one browser and a PDF in another
  820. # [17:25] <hsivonen> mookid: you just said you're happy even without it!
  821. # [17:25] <mookid> It's an application design issue..
  822. # [17:25] <jgraham> Indeed I would assume that the browser that returned the PDF was broken
  823. # [17:26] <mookid> I'm happy that a user would have to either know the UA that was most appropriate
  824. # [17:26] <mookid> and/or the html version of that resource could link their up to date browser
  825. # [17:26] <mookid> to all the representations
  826. # [17:26] <mookid> aswell as provide it's own representation
  827. # [17:26] <mookid> that's an application design descision
  828. # [17:26] <mookid> microsoft office talks HTTP now
  829. # [17:27] <Philip`> jgraham: I think you'd actually blame Adobe for having a broken Acrobat plugin in that case
  830. # [17:27] <Philip`> because they're the easiest target for any PDF-related complaints
  831. # [17:27] <jgraham> I am not a design expert but having a single UI element do different things based on some unspecified external variable is, I expect, never a good idea
  832. # [17:27] * hsivonen starts to think "that's an application design descision" is some kind of architect cop-out
  833. # [17:28] <mookid> it's not a single UI element..
  834. # [17:28] <jgraham> It's a single link
  835. # [17:28] <mookid> how many users use multiple browsers?
  836. # [17:28] <jgraham> Almost all, hopefully
  837. # [17:29] <mookid> If HTML5 did implement that - up to date browsers would understand the markup so that's not a fair point
  838. # [17:29] <mookid> what?
  839. # [17:29] <jgraham> Browsers change with time
  840. # [17:29] <jgraham> Few people still use NS4
  841. # [17:29] <mookid> yeah.. that's why I'd want it in the HTTP5 spec
  842. # [17:29] <Philip`> It's more of a concern when multiple users, each with a different single browser, communicate and expect web sites to work the same for everyone
  843. # [17:29] <mookid> well up to date browsers taht were HTTP5 compliant would understand the marup for the accept header
  844. # [17:29] <mookid> so I'd be willing to accept that older browsers wouldn't work and insist that my users upgrade
  845. # [17:30] <mookid> that's my descision as a developer
  846. # [17:30] <Philip`> (Do you mean HTML5, not HTTP5?)
  847. # [17:30] <mookid> HTLM
  848. # [17:30] <mookid> yeah
  849. # [17:30] <mookid> my bad ;)
  850. # [17:30] <mookid> what's wrong with that approach - it's just a different way of using URIs I dont see what the big deal is
  851. # [17:30] <mookid> and it's not like it stops you from continuing to use URIs for conneg
  852. # [17:31] <jgraham> Yeah so a user used to one behaviour in an old browser would be surprised if their new browser did something different with a familiar application. This would possibly be enough to convince them that the new browser was broken and that they should not upgrade
  853. # [17:31] <mookid> what
  854. # [17:31] <hsivonen> mookid: over here we don't just make stuff up for choice and vive la difference
  855. # [17:31] <mookid> if a link that says 'pdf version of reoprt' returns a pdf?
  856. # [17:31] <mookid> if you don't indicate that a certain link does something
  857. # [17:31] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  858. # [17:31] <mookid> that's a GUI insufficiecy
  859. # [17:32] <mookid> hsivonen: I'm not making anything up - HTTP conneg exists. deal with it.
  860. # [17:32] <mookid> hsivonen: you're opinionated and you're shrouding it in psuedo-logic
  861. # [17:32] <mookid> just admit you want conneg in URIs
  862. # [17:32] <hsivonen> mookid: I'm dealing with the consequences right now
  863. # [17:32] <jgraham> I really don't understand this. You seem to be imaganing that there is actually a single canonical version of the resource e.g. a PDF
  864. # [17:33] <jgraham> If that is the case, just link to is
  865. # [17:33] <jgraham> s/is/it/
  866. # [17:33] <mookid> what?
  867. # [17:33] <mookid> that doesnt make sense
  868. # [17:33] <mookid> I'm suggesting there's lots of representations
  869. # [17:33] <mookid> of a resource
  870. # [17:33] <mookid> one URI has many content types to return
  871. # [17:34] <mookid> and we need a way of letting browsers negotiate that URI on the fly
  872. # [17:34] <mookid> a PDF reader, rightly so, already has it's Accept headers fixed
  873. # [17:34] <jgraham> So how can you write "pdf version of report" if it might return HTML or plain text or Word?
  874. # [17:34] <mookid> because that's all it accepts
  875. # [17:34] * Joins: pergj_ (n=pergj@65.219.59.140)
  876. # [17:34] <mookid> it's just data
  877. # [17:34] <hsivonen> http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx
  878. # [17:34] <mookid> fick.
  879. # [17:34] <mookid> dick*
  880. # [17:35] <mookid> passive aggresive is what defensive peopel with no rationale do
  881. # [17:35] <jgraham> Heh
  882. # [17:35] <mookid> grow a pair hsivonen
  883. # [17:35] * jgraham has met hsivonen
  884. # [17:36] <jgraham> That is not a good description :)
  885. # [17:36] * Philip` thinks the 0x27 in the URL is a bit weird
  886. # [17:36] <mookid> jgraham: you look at web applications differenet to me
  887. # [17:36] * Quits: aaronlev_ (n=chatzill@f051115131.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  888. # [17:36] <mookid> I see a pdf as the same thing as an html document - just a different format
  889. # [17:37] <jgraham> mookid: I think mos users see them as different, even if they have the same prose content
  890. # [17:37] <mookid> so if I PUT the pdf resource back to the URI it's the same as if I PUT the html or the word doc format back
  891. # [17:37] <mookid> it changes the resource
  892. # [17:37] <mookid> users dont care
  893. # [17:37] <mookid> they do what they're told
  894. # [17:37] <mookid> particularly with html
  895. # [17:37] <mookid> they dont look at the markup
  896. # [17:37] <mookid> or the status bar
  897. # [17:37] <Philip`> Evidence suggests people don't actually do what they're told :-)
  898. # [17:37] <mookid> no - they like to do it their way
  899. # [17:38] <takkaria> well, no. pdfs load adobe acrobat into the browser and make it slow and draggy, and give it an extra set of menu bars. html doesn't. most people understand the stuff you do in web browsers != PDF
  900. # [17:38] <mookid> if you couple content-type to a URI you restrict them
  901. # [17:38] <jgraham> mookid: I don't claim that they care about the markup or about the status bar. They care about the results of their actions though
  902. # [17:38] <yecril71> PUT is not enough to make a resource fork.
  903. # [17:38] <mookid> how will they notice any differnet if the conneg is in the URI or whether it's HTTP then?
  904. # [17:38] <yecril71> Some server magic is needed.
  905. # [17:39] <mookid> like JAX-RS ? -_-
  906. # [17:39] <yecril71> Like vi .htaccess
  907. # [17:39] <mookid> it's not magic that's how modern web apps are being designed
  908. # [17:39] <jgraham> I think the core concept of content negoiation is user-hostile
  909. # [17:39] <mookid> htacces..
  910. # [17:39] <yecril71> whatever
  911. # [17:39] <mookid> is that a joke?
  912. # [17:39] <jgraham> Or, at least there are very few occasions where I think it is reasonable
  913. # [17:39] <yecril71> How do you configure Apache to do content negotiation?
  914. # [17:40] <mookid> hahaha
  915. # [17:40] <mookid> that says it all
  916. # [17:40] <jgraham> e.g. serving XHTML vs HTML is often OK
  917. # [17:40] <jgraham> Serving PDF or HTML is not
  918. # [17:40] <mookid> do any of you actually develop enterprise applications?
  919. # [17:40] <mookid> -_-
  920. # [17:40] <jgraham> because users interact with those representations very differently
  921. # [17:40] * takkaria concludes the Language spec thread on public-html is now entirely bikeshedding
  922. # [17:41] <jgraham> mookid: Fortunatley not :)
  923. # [17:41] * hsivonen used to develop enterprise apps but doesn't anymore
  924. # [17:41] <mookid> maybe that's why you dont see this from my perspective
  925. # [17:41] <Philip`> yecril71: It's not a thing for static content that's all handled by Apache; it's for complex dynamic systems written in an Enterprise language like Visual Basic
  926. # [17:41] <mookid> you're seeing html and PDF as seperate
  927. # [17:41] * smedero likes his bike shed painted purple
  928. # [17:41] * jgraham noticed that after three days away public-html had almost entirely meta discussion and whatwg almost entirely technical discussion
  929. # [17:41] <takkaria> how has enterprise programming got anything to do with how users see html vs pdf?
  930. # [17:41] <mookid> I see HTML and PDF documents at one URI beign generated from the same data store < IMPORTANT
  931. # [17:42] <mookid> and updated to the same store aswell
  932. # [17:42] <mookid> generated.. on the fly..
  933. # [17:42] <yecril71> Really? So even Apache does not support declarative content negotiation?
  934. # [17:42] <jgraham> mookid: Right but do users care about which representation they get?
  935. # [17:43] <mookid> well if they do they'll use the UA that's appropriate
  936. # [17:43] <yecril71> Then we should probably wait until it does.
  937. # [17:43] <mookid> I can write a content negotating app in JAX-RS right now
  938. # [17:43] <mookid> I just can't get a brwoser to use it properly
  939. # [17:43] <jgraham> mookid: So you expect me to load my PDF viewer to get a PDF version of a resource?
  940. # [17:44] <yecril71> If you cannot do it without writing server-side code, you cannot require it.
  941. # [17:44] <mookid> yecril71: you dont know what you're tlaking about
  942. # [17:44] <Philip`> yecril71: You can just use mod_rewrite if you want to redirect using .htaccess depending on the request headers
  943. # [17:44] <mookid> jgraham: yes, I dont see the big deal with that
  944. # [17:45] <yecril71> Right. However, I cannot do it with PUT.
  945. # [17:45] <yecril71> I have to use another server-side technique to create the fork.
  946. # [17:45] <jgraham> mookid: Ah, I think we are getting closer to the fundamental disagreement here
  947. # [17:45] <mookid> yes!
  948. # [17:45] <mookid> It's design level
  949. # [17:45] <Philip`> yecril71: Not to static files via Apache, which is why this is more relevant for more dynamic systems, where you're updating databases and generating content from them
  950. # [17:46] <mookid> YES
  951. # [17:46] <mookid> thank you Philip`
  952. # [17:46] <yecril71> But mookid said he can PUT.
  953. # [17:46] <jgraham> My PDF viewer doesn't even seem to open URIs
  954. # [17:46] <yecril71> Hie cannot.
  955. # [17:46] <Philip`> I don't think I have any icons on my computer to launch a PDF viewer :-(
  956. # [17:46] <mookid> well then update your PDF viewer then
  957. # [17:47] <jgraham> I believe I have the latest avaliable version
  958. # [17:47] <mookid> or browse to my html pages which will give you the HTML version and link yuo to the other representations using the brand new Accept attribute
  959. # [17:47] <mookid> the fact that the UA's dont support it yet doesnt mean they wont
  960. # [17:47] <mookid> it's all moving that way
  961. # [17:47] <mookid> I should know..
  962. # [17:47] <mookid> o.O
  963. # [17:48] <mookid> MS office does HTTP
  964. # [17:48] <jgraham> mookid: The point that I was trying to make earlier is that UAs not supporting it today may wel mean that they won't becauseany browser that adds support will change the behaviour of existing applications, so discouraging users from upgrading
  965. # [17:49] <Philip`> jgraham: You should get a better operating system / desktop environment - KDE automatically lets you load URLs into programs like KPDF :-)
  966. # [17:49] <mookid> you moved off 3.5 Philip` ?
  967. # [17:49] <Philip`> mookid: No
  968. # [17:49] <mookid> me neither :>
  969. # [17:49] <Philip`> (Well, I have 4.1 installed but only use it when testing Konqueror)
  970. # [17:49] <yecril71> And a HTTP-compatible file system like HFS that supports forks
  971. # [17:50] <yecril71> HFS+ (HFS supports only two)
  972. # [17:50] <Philip`> yecril71: The filesystem is irrelevant - you write code that sits behind the URLs to do whatever magic it wants to do
  973. # [17:51] * Quits: takkaria (n=takkaria@isparp.co.uk) (Read error: 60 (Operation timed out))
  974. # [17:51] <yecril71> If I have to write code, I defect.
  975. # [17:51] <yecril71> I need a declarative interface for maintenance.
  976. # [17:52] <ehird> uh-oh mookid is still blabbing on about that conneg?
  977. # [17:52] <ehird> :P
  978. # [17:52] <mookid> jgraham: I dont understand the point your making, explain please
  979. # [17:52] <mookid> :)
  980. # [17:52] * Joins: takkaria (n=takkaria@isparp.co.uk)
  981. # [17:52] <mookid> it's important stuff
  982. # [17:53] <Philip`> yecril71: If you don't want to write code, this feature is not for you :-)
  983. # [17:53] <mookid> jgraham: you see incompatability between the two methods that isn't there
  984. # [17:54] <mookid> UAs that are not browsers should be setting their Accept headers appropriately
  985. # [17:54] <mookid> so if you specify the conneg in the URI or you don't it shouldn't matter
  986. # [17:54] <yecril71> If it is not supported declaratively server-side, it is not mature enough.
  987. # [17:54] <mookid> yecril71: yes it is
  988. # [17:55] <mookid> becasue you dont' know how to do it doesnt mean it's not possible
  989. # [17:55] <yecril71> I never said it is not possible.
  990. # [17:55] <mookid> well then stop talking.
  991. # [17:55] <mookid> 'not supported' = not possible
  992. # [17:55] <yecril71> I said it is immature.
  993. # [17:55] <mookid> immature
  994. # [17:55] <mookid> just stop.
  995. # [17:55] <mookid> stop please.
  996. # [17:56] <mookid> when in hole and all that
  997. # [17:56] <mookid> why did you say you got banned again?
  998. # [17:56] <mookid> =)
  999. # [17:56] <yecril71> I did not say I got banned again.
  1000. # [17:57] <mookid> turn of phrase
  1001. # [17:57] <yecril71> I just got banned, indefinitely.
  1002. # [17:57] <mookid> I'm tempted to put you on ignore
  1003. # [17:57] <mookid> I can't though I'm a liberal
  1004. # [17:57] <mookid> damn my awesomeness
  1005. # [17:57] <yecril71> Sweet temptations...
  1006. # [17:57] <takkaria> putting people on ignore is something you do, not something you talk about. :)
  1007. # [17:58] <jgraham> mookid: In browser A I click a link and get a HTML version of a resource with a link to a PDF version. In newer browser B that supports <a accept=> I get a PDF version. I depended on the HTML version. From my point of view browser B is broken. I stick with browser A.
  1008. # [17:58] <jgraham> Hence browser B cannot gain marketshare without dropping support for <a accept>
  1009. # [17:58] <mookid> right.. that's technical innovation
  1010. # [17:58] <mookid> that happens all the time
  1011. # [17:59] <mookid> so blu-ray should never have happened
  1012. # [17:59] <mookid> because the discs dont work in my dvd player?
  1013. # [17:59] * Joins: dglazkov (n=dglazkov@nat/google/x-fdbb25f990c6023d)
  1014. # [17:59] <yecril71> Blue ray disks hold more data.
  1015. # [18:00] <yecril71> That is an advantage.
  1016. # [18:00] <yecril71> But there are innovations that gain acceptance, and there are others that do not.
  1017. # [18:00] <jgraham> It's more like playing DVDs in your bluray players and discovering that they suddenly play the remake of psyco rather than the hitchcock original
  1018. # [18:01] <mookid> not really those are two seperate resources
  1019. # [18:01] <mookid> actually it's more like putting a blue ray disc in a dvd player and getting dvd quality
  1020. # [18:01] <mookid> dissapointing but hey.. you're an idiot
  1021. # [18:01] <mookid> :)
  1022. # [18:02] <yecril71> I have always thought I am an idiot.
  1023. # [18:02] <jgraham> They have the same script, same shots, just different versions of them
  1024. # [18:02] <yecril71> So now there are two of us...
  1025. # [18:02] <yecril71> :)
  1026. # [18:04] <mookid> I wasnt actually calling him an idiot
  1027. # [18:05] <mookid> I was calling the hypothetical person putting a blu ray disc in a dvd player an idiot
  1028. # [18:07] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  1029. # [18:08] * Quits: ehird (n=ehird@eso-std.org) (Remote closed the connection)
  1030. # [18:08] <mookid> jgraham: yeah exactly - so you put the 'blu ray disc' into your cd player and it just plays the audio
  1031. # [18:09] <mookid> with someone describing the scene aswell
  1032. # [18:09] <mookid> so your cd player representation doesnt lose to much data
  1033. # [18:10] * Joins: ehird (n=ehird@eso-std.org)
  1034. # [18:10] <takkaria> no, but you still want to be able to differentiate between the cd/dvd/blu-ray versions
  1035. # [18:10] <mookid> you want a seperate disc for each?
  1036. # [18:10] <mookid> rather than one you can stick into all the players?
  1037. # [18:11] <mookid> you're wierd.
  1038. # [18:11] <yecril71> Meaning, having a blue-ray disk and a blue-ray player, you would rather prefer it to play CD audio?
  1039. # [18:11] <takkaria> I might do, yeah
  1040. # [18:11] <yecril71> For what reason?
  1041. # [18:11] <takkaria> you know what directors are like, the DVD release will be closer to the cinema release than the blu-ray
  1042. # [18:11] <mookid> yeah *MAYBE*
  1043. # [18:12] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  1044. # [18:12] <mookid> you're confusing yourself
  1045. # [18:12] <mookid> -_-
  1046. # [18:12] <takkaria> no, I'm just not taking this all as seriously as you are. :)
  1047. # [18:12] <mookid> cmon admit - that analogy just killed you :P
  1048. # [18:13] <takkaria> see, I think that your argument works fine given your assumptions
  1049. # [18:13] <takkaria> I just don't think your assumptions are realistic
  1050. # [18:13] <mookid> why - because that's not how it works at the moment?
  1051. # [18:14] <mookid> no sh*t!
  1052. # [18:15] <takkaria> no, because people sometimes want PDFs and sometimes want HTML, and being able to specify between them is quite useful
  1053. # [18:15] <mookid> which you can do..
  1054. # [18:15] <mookid> you just dont get it :/
  1055. # [18:15] * Quits: dglazkov (n=dglazkov@nat/google/x-fdbb25f990c6023d)
  1056. # [18:16] <takkaria> I'm sorry you think that
  1057. # [18:16] <mookid> specifying between them is conneg
  1058. # [18:16] <mookid> HTTP has conneg
  1059. # [18:16] * danbri__ is now known as danbri
  1060. # [18:16] <mookid> that's what Accept is for
  1061. # [18:16] <mookid> if you can't understand that
  1062. # [18:16] <mookid> what m I supposed to do abuot that:?
  1063. # [18:16] <takkaria> no, I get that :) but to the user, that's all behind-the-scenes stuff
  1064. # [18:17] <takkaria> if you want to paste someone a link to the PDF version of something, you go "copy link location" and paste it to them in an IM window
  1065. # [18:17] <takkaria> or in an email, whatever
  1066. # [18:17] <takkaria> and as soon as you do that, you lose the invisible metadata hidden in the HTML
  1067. # [18:17] <mookid> I appreciate that.. then it's down to how the user wants to use the system
  1068. # [18:18] <mookid> that's a design descision
  1069. # [18:18] <mookid> you're not comfortable with that.. fair enough
  1070. # [18:18] <yecril71> It would work if the negotiated content were an explicit REDIRECT
  1071. # [18:18] <mookid> that's possible aswell
  1072. # [18:18] <mookid> that's what the location header is for
  1073. # [18:18] * Quits: pesl (n=retep@procurios.xs4all.nl) (Read error: 54 (Connection reset by peer))
  1074. # [18:19] <mookid> if that was even a requirement
  1075. # [18:19] * Joins: dglazkov (n=dglazkov@nat/google/x-0b8e133625b97ea9)
  1076. # [18:19] <mookid> which it isnt given my methodology
  1077. # [18:19] <mookid> look - it's not about being right
  1078. # [18:19] <mookid> I really dont want to say 'my way is better than yours'
  1079. # [18:19] <mookid> it's just different - and legitimately so.. HTTP has a conneg mechanism that I want to use
  1080. # [18:19] <mookid> it's not for fun..
  1081. # [18:19] <yecril71> What about the type attribute?
  1082. # [18:20] <yecril71> Why is it not enough to say type="application/pdf">
  1083. # [18:20] <yecril71> ?
  1084. # [18:22] <mookid> that attribute is standard across all referencing tags and specifically tied to the Accept header is it?
  1085. # [18:23] <yecril71> I think the A tag is enough.
  1086. # [18:23] <mookid> well you would because you dont know what you're talking abuot
  1087. # [18:24] <yecril71> Your example contained an A.
  1088. # [18:24] * Quits: dave_levin (n=levin@72.14.224.1)
  1089. # [18:24] <mookid> 'enough'
  1090. # [18:24] <mookid> ^compute. understand.
  1091. # [18:25] <yecril71> Compute what?
  1092. # [18:25] <mookid> look at what you wrote.. and then my response.
  1093. # [18:25] <mookid> I was referring to your use of the word enough
  1094. # [18:25] <yecril71> And what does it have to do with computing?
  1095. # [18:26] <yecril71> Besides, in order to explain things, you have to talk to people who do not know what you are talking about.
  1096. # [18:27] <yecril71> That is quite natural, and you should be prepared to explain things to them.
  1097. # [18:27] <mookid> compentent people, yeah
  1098. # [18:27] <yecril71> Making fun of them will not help you to make your case.
  1099. # [18:27] <mookid> I gave you the benefit of the doubt about 24 hours ago
  1100. # [18:27] <mookid> you only have yourself to blame
  1101. # [18:28] <mookid> it wore thing.
  1102. # [18:28] <mookid> thin^
  1103. # [18:28] <mookid> there is no hope
  1104. # [18:28] <yecril71> And everything ends in Armageddon.
  1105. # [18:28] <mookid> decapitate yourself
  1106. # [18:28] <yecril71> But what does it have to do with accept attribute wannabe?
  1107. # [18:29] <mookid> ok he's on ignore now
  1108. # [18:29] <yecril71> Encouraging people to commit suicide is a criminal offense.
  1109. # [18:29] <mookid> takkaria: do you take the point that it's a design descision or not?
  1110. # [18:30] <yecril71> At least in my country.
  1111. # [18:32] * Joins: pergj__ (n=pergj@65.219.59.140)
  1112. # [18:34] <mookid> Philip`: can you wade in on the mailing list about this?
  1113. # [18:35] <mookid> it seems more solid if we do it on there
  1114. # [18:35] <takkaria> mookid: a design decision? not really. invisible metadata in cases like this is bad for users
  1115. # [18:35] <mookid> in your opinion
  1116. # [18:36] <mookid> that's ok I'm comfortable with that
  1117. # [18:36] <takkaria> sure, it is a design decision to be hostile to users, but I don't generally think that's something HTML5 should allow in as much as it can stop it
  1118. # [18:36] <mookid> if I get context menu when I right click a URI that lets me decide what UA to open it with
  1119. # [18:36] <mookid> that would be super cool
  1120. # [18:37] <mookid> people associate HTTP with browsers too much
  1121. # [18:37] <mookid> takkaria: that's my problem with this - it's not your place to stop it
  1122. # [18:37] <mookid> it's part of the HTTP protocol
  1123. # [18:38] <takkaria> I think HTML5 in excellent place to stop things which are bad for users
  1124. # [18:38] <takkaria> if not HTML5, then where?
  1125. # [18:38] <mookid> within the scope of web interfaces
  1126. # [18:38] <mookid> not 'how web developers use HTTP'
  1127. # [18:39] <mookid> well nowhere - if anywhere in HTTP
  1128. # [18:39] <mookid> since that's the protocol
  1129. # [18:39] <mookid> we're tlakign about here
  1130. # [18:39] <mookid> if you werent supposed to be able to do it with HTTP
  1131. # [18:39] <mookid> HTTP wouldnt allow it
  1132. # [18:39] <mookid> infact, they actively encourage it
  1133. # [18:39] <mookid> by providing protocol level conneg
  1134. # [18:40] <takkaria> just because HTTP provides something doesn't mean it's necessarily good for users
  1135. # [18:40] <mookid> who are you to decide that?
  1136. # [18:40] <takkaria> a user? :)
  1137. # [18:40] <mookid> well that's probably the most acurate thing you've said all day
  1138. # [18:41] <mookid> why don't you see HTML as somethign to liberate developers ratehr than restrict them
  1139. # [18:41] <takkaria> actually, I talked to people about the impact of drug policy on crime earlier today, that was about as accurate as what I said about. :)
  1140. # [18:41] <mookid> legalise maaaaaan
  1141. # [18:41] <takkaria> why do you see HTML as something to do things users don't want? :)
  1142. # [18:42] <mookid> english please
  1143. # [18:42] <takkaria> well, you say that HTML is something to liberate developers
  1144. # [18:42] <takkaria> I think it should be focusing more on what is helpful to users
  1145. # [18:42] <mookid> lol
  1146. # [18:42] * Quits: epeus (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  1147. # [18:42] <mookid> users dont use html
  1148. # [18:42] <mookid> html is given to them by developers
  1149. # [18:42] <takkaria> sure they do. what else do I use when I browse the web?
  1150. # [18:42] <mookid> it's just markup
  1151. # [18:43] <mookid> you use a web browser
  1152. # [18:43] <takkaria> if developers can't do things that aren't good for users, that's a good thing as far as I'm concerned, as a user
  1153. # [18:43] <mookid> who are you to decide what developers should and shouldnt be doing?
  1154. # [18:43] <takkaria> a user. :)
  1155. # [18:43] <mookid> that's not a good answer
  1156. # [18:43] <mookid> I know you think it is, it's not
  1157. # [18:44] <takkaria> well, I have as much say in the matter as anyone else, really
  1158. # [18:44] <mookid> it's pretty arrogant to assume you have a better grasp than other people and that they can't possibly work it out when you can
  1159. # [18:44] <mookid> I just dont understand that perspectife
  1160. # [18:44] <mookid> at all
  1161. # [18:44] <takkaria> I don't think I said that
  1162. # [18:44] <mookid> it's written between the ilines
  1163. # [18:44] <takkaria> I just said that as a user, I'd rather developers didn't have the ability to do things that I don't want them to do
  1164. # [18:45] <takkaria> like hiding invisible metadata that makes URL copy and pasting difficult
  1165. # [18:45] <mookid> right.. and that's your rational for not allowing HTML to provision better control of HTTP conneg?
  1166. # [18:45] <takkaria> yup
  1167. # [18:45] <mookid> that's YOUR perspective
  1168. # [18:45] <takkaria> and yours is yours. :)
  1169. # [18:45] <mookid> how do you know that's right?
  1170. # [18:45] <mookid> yes.. and I'm saying
  1171. # [18:45] <mookid> I dont know definitively what's better
  1172. # [18:46] <mookid> I just know that the most appropriate situation is where we can coexist
  1173. # [18:46] <mookid> which an optional attribute provides
  1174. # [18:46] <takkaria> I'd like to note that the design principles for the HTML WG (http://www.w3.org/html/wg/html5/principles/#priority-of-constituencies) mention: "n case of conflict, consider users over authors over implementors over specifiers over theoretical purity"
  1175. # [18:46] <takkaria> so I'd guess that the WG's official position is pretty much in line with mine
  1176. # [18:47] <mookid> so you create a conflict and then accuse me of rocking the boat and confusing users with change
  1177. # [18:47] <mookid> that sounds like the lazy-boy manifesto right there
  1178. # [18:47] <takkaria> I don't think I'm creating a conflict at all
  1179. # [18:47] <mookid> congratulaitons you lot completely fooled me
  1180. # [18:47] <takkaria> your proposal would make URL copy and pasting, a very common activity, harder
  1181. # [18:47] <mookid> glad you're at the helm of HTML
  1182. # [18:47] <mookid> no it wouldnt
  1183. # [18:47] <takkaria> it would, because there'd be invisible metadata that wouldn't get copy-pasted
  1184. # [18:48] <mookid> what is invisible?
  1185. # [18:48] <takkaria> and the conflict is between you wanting to make it harder and users wanting it to work
  1186. # [18:48] <takkaria> the accept="" attribute
  1187. # [18:48] <mookid> the URI indicates where the resource is..
  1188. # [18:48] <mookid> it's done it's job
  1189. # [18:48] <mookid> the content negotiation is down to the UA yoru using and the context you are requesting from
  1190. # [18:48] <mookid> the fact that you dont see it that way
  1191. # [18:48] <takkaria> if someone copy and pastes the link from <a type="application/pdf" href="blah">, then they will lose the fact it was intended to PDF
  1192. # [18:49] <mookid> I KNOW THAT
  1193. # [18:49] <mookid> that's not complicated.
  1194. # [18:49] <takkaria> aye. and that is what the invisible metadata is
  1195. # [18:49] <takkaria> and invisible metadata is harmful to users, especially in this case
  1196. # [18:49] <Philip`> mookid: I'd rather not wade in since I don't think I have anything valuable to contribute and I'd just get my socks wet
  1197. # [18:49] <mookid> a URI indicates a resource
  1198. # [18:49] * aroben is now known as aroben|away
  1199. # [18:49] <Philip`> A URI indicates what the developer thinks is a resource, which may not be what the user thinks is a resource
  1200. # [18:49] <mookid> yeah sure
  1201. # [18:49] <mookid> bbl
  1202. # [18:50] * Quits: pergj_ (n=pergj@65.219.59.140) (Read error: 110 (Connection timed out))
  1203. # [18:50] <Philip`> (so users might want a way to distinguish what they consider separate resources, even if the developer thought they were one resource and put them at the same URI)
  1204. # [18:50] <yecril71> By the way, there are mouses that do not have the right button.
  1205. # [18:51] <yecril71> Because they have only one button.
  1206. # [18:52] <yecril71> OTOH, it is the same thing with METHOD=POST.
  1207. # [18:53] <yecril71> Imagine METHOD=POST returning content that is inaccessible otherwise.
  1208. # [18:53] <yecril71> And you cannot put the URL into the clipboard.
  1209. # [18:54] * Joins: maikmerten (n=maikmert@L85b3.l.pppool.de)
  1210. # [18:57] * Joins: sverrej (n=sverrej@cm-84.208.153.202.getinternet.no)
  1211. # [19:01] <Philip`> POST is non-idempotent so there's a good reason to not let people arbitrarily copy around strings that let them accidentally repeat POST requests
  1212. # [19:01] <Philip`> but that reason doesn't apply when you're simply GETting (content-negotiated) files
  1213. # [19:07] * Joins: ap_ (n=ap@195.239.126.12)
  1214. # [19:07] * Quits: ap (n=ap@195.239.126.10)
  1215. # [19:07] * ap_ is now known as ap
  1216. # [19:08] * Joins: dave_levin (n=levin@72.14.227.1)
  1217. # [19:09] <yecril71> The problem with hsivonen’s script is caused by the DOM viewer code.
  1218. # [19:10] <yecril71> The content rendered separately does not cause Internet Explorer to hang.
  1219. # [19:10] * Joins: dimich (n=dimich@72.14.227.1)
  1220. # [19:11] <Philip`> Oh, that's a useful observation - I think I saw a bug exactly like that at some point in the past...
  1221. # [19:11] <Philip`> https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=366200
  1222. # [19:13] * Joins: ojan (n=ojan@nat/google/x-6ef02f0afa4e0e39)
  1223. # [19:15] <yecril71> It is not a big problem given that inline frames are not strictly conforming.
  1224. # [19:16] <yecril71> My experience shows it is safer to use window.open
  1225. # [19:16] <yecril71> Which is nonconforming as well, but it works better at least.
  1226. # [19:16] <Philip`> iframes are perfectly conforming in HTML5
  1227. # [19:17] <Philip`> and any browsers shouldn't crash or freeze on any input, regardless of conformingness
  1228. # [19:17] <Philip`> s/any/anyway/
  1229. # [19:17] <yecril71> Of course.
  1230. # [19:17] * Joins: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com)
  1231. # [19:17] <yecril71> Hovewer, HTML5 is not implemented.
  1232. # [21:18] * Disconnected
  1233. # Session Close: Thu Nov 20 00:00:00 2008

The end :)