/irc-logs / w3c / #html-wg / 2011-01-25 / end

Options:

  1. # Session Start: Tue Jan 25 00:00:00 2011
  2. # Session Ident: #html-wg
  3. # [00:03] * Joins: homata_ (homata_@58.158.182.50)
  4. # [00:05] * Quits: aroben_ (aroben@17.203.12.32) (Ping timeout)
  5. # [00:16] * Joins: MikeSmith_ (MikeSmith@114.48.79.89)
  6. # [00:18] * Quits: MikeSmith (MikeSmith@111.188.19.120) (Ping timeout)
  7. # [00:18] * MikeSmith_ is now known as MikeSmith
  8. # [00:18] * Joins: aroben (aroben@17.246.17.144)
  9. # [00:31] * Quits: anne (annevk@83.85.115.123) (Quit: anne)
  10. # [00:37] * Quits: myakura (myakura@122.26.253.32) (Client exited)
  11. # [00:37] * Joins: homata (homata@58.158.182.50)
  12. # [00:38] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
  13. # [00:54] * Joins: kennyluck (kennyluck@128.30.52.169)
  14. # [00:54] * Quits: aroben (aroben@17.246.17.144) (Ping timeout)
  15. # [01:12] * Quits: plh (plh@128.30.52.28) (Quit: always accept cookies)
  16. # [01:18] <CIA-1> html-spec: ianh@340c8d12-0b0e-0410-8428-c7bf67bfef74 * db56ccba2fa2 r5804 / (index complete.html source):
  17. # [01:18] <CIA-1> html-spec: [e] (0) reference update
  18. # [01:18] <CIA-1> html-spec: Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=11620
  19. # [01:18] <pimpbot> 11620: contributor, P3, RESOLVED FIXED, Update to http://tools.ietf.org/html/draft-ietf-websec-origin, ed. A. Barth
  20. # [01:33] * Quits: tH (Rob@86.26.244.233) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
  21. # [01:42] <pimpbot> changes: hixie: reference update (whatwg r5805) <http://lists.w3.org/Archives/Public/public-html-diffs/2011Jan/0142.html>
  22. # [01:42] <pimpbot> bugmail: "[Bug 11620] Update to http://tools.ietf.org/html/draft-ietf-websec-origin, ed. A. Barth" (2 messages in thread) <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0851.html>
  23. # [01:49] * Joins: aroben (aroben@173.200.178.70)
  24. # [01:55] * Joins: homata_ (homata@58.158.182.50)
  25. # [01:56] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  26. # [02:25] * Quits: homata_ (homata@58.158.182.50) (Ping timeout)
  27. # [02:25] * Joins: homata (homata@58.158.182.50)
  28. # [03:00] * Joins: aroben_ (aroben@173.200.187.194)
  29. # [03:01] * Quits: aroben (aroben@173.200.178.70) (Ping timeout)
  30. # [03:09] * Joins: Lachy (Lachlan@84.215.59.50)
  31. # [03:24] * Joins: aroben (aroben@173.200.187.194)
  32. # [03:25] * Quits: aroben_ (aroben@173.200.187.194) (Ping timeout)
  33. # [03:27] * Quits: Dashiva (noone@84.72.44.31) (Ping timeout)
  34. # [03:33] * Joins: Dashiva (noone@84.72.44.31)
  35. # [03:56] * Joins: davidb (davidb@174.91.43.139)
  36. # [04:00] * Quits: davidb (davidb@174.91.43.139) (Quit: davidb)
  37. # [04:01] * Joins: davidb (davidb@174.91.43.139)
  38. # [04:03] * Quits: mjs (mjs@17.246.19.230) (Quit: mjs)
  39. # [04:11] * Joins: mjs (mjs@17.244.7.16)
  40. # [04:13] <pimpbot> changes: sam: Record change proposal for issue 142 <http://lists.w3.org/Archives/Public/public-html-diffs/2011Jan/0143.html>
  41. # [04:13] <pimpbot> bugmail: [Bug 11838] In Gecko, Opera, and IE, the "name" property on Window is replaceable <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0853.html> ** [Bug 11839] window.opener needs to be writable, not readonly (as it is in Gecko, Chrome, IE) <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0852.html>
  42. # [04:14] * Joins: mjs_ (mjs@67.218.109.171)
  43. # [04:14] * Quits: mjs (mjs@17.244.7.16) (Ping timeout)
  44. # [04:14] * mjs_ is now known as mjs
  45. # [04:22] * Quits: davidb (davidb@174.91.43.139) (Ping timeout)
  46. # [04:43] * Quits: gavin__ (gavin@99.226.207.11) (Ping timeout)
  47. # [04:43] <pimpbot> bugmail: [Bug 11856] New: what happens when nothing happens in the getData() algorithm? <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0854.html>
  48. # [04:48] * Joins: gavin__ (gavin@99.226.207.11)
  49. # [04:59] <pimpbot> planet: Tantek: W3C Updates HTML5 Logo Messaging FAQ, Open To More Suggestions <http://tantek.com/2011/024/b1/w3c-updates-html5-logo-messaging-faq>
  50. # [05:02] * Quits: mjs (mjs@67.218.109.171) (Quit: mjs)
  51. # [05:12] * Joins: mjs (mjs@24.6.209.6)
  52. # [05:43] * Joins: homata_ (homata@58.158.182.50)
  53. # [05:45] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  54. # [06:17] * Joins: MikeSmith_ (MikeSmith@111.188.81.170)
  55. # [06:19] * Quits: MikeSmith (MikeSmith@114.48.79.89) (Ping timeout)
  56. # [06:19] * MikeSmith_ is now known as MikeSmith
  57. # [08:33] * Disconnected
  58. # [08:34] * Attempting to rejoin channel #html-wg
  59. # [08:34] * Rejoined channel #html-wg
  60. # [09:03] * Quits: gavin__ (gavin@99.226.207.11) (Ping timeout)
  61. # [09:06] * Joins: tH (Rob@86.26.244.233)
  62. # [09:08] * Joins: gavin__ (gavin@99.226.207.11)
  63. # [09:30] * Quits: arronei (arronei@131.107.0.85) (Ping timeout)
  64. # [09:35] * Joins: arronei (arronei@131.107.0.69)
  65. # [09:40] * Quits: mjs (mjs@24.6.209.6) (Quit: mjs)
  66. # [09:51] * Joins: mjs (mjs@24.6.209.6)
  67. # [10:07] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  68. # [10:10] * Quits: Dashiva (noone@84.72.44.31) (Ping timeout)
  69. # [10:14] <pimpbot> bugmail: [Bug 11858] New: fix title in ORIGIN reference <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0857.html>
  70. # [10:15] * Joins: Dashiva (noone@84.72.44.31)
  71. # [10:21] * Joins: homata (homata@58.158.182.50)
  72. # [10:56] * Quits: Lachy (Lachlan@84.215.59.50) (Quit: Leaving)
  73. # [11:15] * Joins: homata_ (homata@58.158.182.50)
  74. # [11:15] <pimpbot> bugmail: [Bug 11860] New: It might be interesting to allow an application to register itself as a (HTTP) proxy for an unknown scheme. <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0858.html>
  75. # [11:17] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  76. # [11:31] * Joins: Lachy (Lachlan@213.236.208.22)
  77. # [12:01] <pimpbot> planet: Jeremy Keith: Three questions <http://adactio.com/journal/4316/>
  78. # [12:14] * Joins: kennyluck (kennyluck@128.30.52.169)
  79. # [12:17] * Joins: MikeSmith_ (MikeSmith@114.48.191.247)
  80. # [12:19] * Quits: MikeSmith (MikeSmith@111.188.81.170) (Ping timeout)
  81. # [12:19] * MikeSmith_ is now known as MikeSmith
  82. # [12:23] * Joins: anne (annevk@24.132.106.179)
  83. # [12:44] * Joins: Martijnc (Martijnc@91.176.93.127)
  84. # [12:45] * Joins: Martijnc_ (Martijnc@91.176.93.127)
  85. # [12:45] * Quits: Martijnc (Martijnc@91.176.93.127) (Connection reset by peer)
  86. # [12:45] * Martijnc_ is now known as Martijnc
  87. # [12:57] * Quits: gavin__ (gavin@99.226.207.11) (Ping timeout)
  88. # [13:02] * Joins: myakura (myakura@122.26.253.32)
  89. # [13:02] * Joins: gavin__ (gavin@99.226.207.11)
  90. # [13:06] * Quits: homata_ (homata@58.158.182.50) (Quit: Leaving...)
  91. # [13:07] * Joins: ArtB (ArtB@192.100.124.218)
  92. # [13:15] <pimpbot> bugmail: [Bug 11620] Update to http://tools.ietf.org/html/draft-ietf-websec-origin, ed. A. Barth <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0859.html>
  93. # [13:55] * Joins: plh (plh@128.30.52.28)
  94. # [14:15] <pimpbot> bugmail: [Bug 11731] Replace <hgroup> element with a <subhead> element used as the child of the <hx> element <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0862.html> ** [Bug 11861] Need to say to spin the event loop until all sync sections have run before running a new script to make resourse selection algorithm predictable. See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027878.html <http://lists.w3.org/Arch
  95. # [14:30] * Joins: lgombos (Laszlo@192.100.104.17)
  96. # [14:45] <pimpbot> bugmail: [Bug 11861] Need to say to spin the event loop until all sync sections have run before running a new script to make resourse selection algorithm predictable. See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027878.html <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0863.html>
  97. # [15:05] * Joins: miketaylr (miketaylr@206.217.92.186)
  98. # [15:16] <pimpbot> bugmail: [Bug 11846] Hello, I read in the specifics that the <tt> tag was erased, probably due to the fact it is not short for a semantic label but is related to the graphical rendering. I think it is the only way to correctly markup an inline code, such as <pre> and <code> t <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0864.html>
  99. # [15:44] <MikeSmith> issue-120?
  100. # [15:44] * trackbot getting information on ISSUE-120
  101. # [15:44] <trackbot> ISSUE-120 -- Use of prefixes is too complicated for a Web technology -- open
  102. # [15:44] <trackbot> http://www.w3.org/html/wg/tracker/issues/120
  103. # [15:44] <pimpbot> Title: ISSUE-120: Use of prefixes is too complicated for a Web technology - HTML Weekly Tracker (at www.w3.org)
  104. # [15:54] * Quits: MikeSmith (MikeSmith@114.48.191.247) (Ping timeout)
  105. # [15:55] * Joins: MikeSmith (MikeSmith@114.48.191.247)
  106. # [16:00] * Joins: Norm (ndw@96.32.124.29)
  107. # [16:16] <pimpbot> changes: mike: fixed link for first issue-120 CP <http://lists.w3.org/Archives/Public/public-html-diffs/2011Jan/0144.html>
  108. # [16:46] <pimpbot> bugmail: [Bug 11832] More exhaustive definition of itemValue needed <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0865.html>
  109. # [16:58] * Joins: rubys (rubys@98.27.48.117)
  110. # [16:59] <rubys> hsivonen: ping?
  111. # [16:59] * Joins: kliehm (kliehm@80.146.185.162)
  112. # [17:01] <anne> hsivonen, he just left
  113. # [17:01] <rubys> ah. ok. In any case, for when he gets back:
  114. # [17:02] <rubys> "closed without prejudice" means "can be reopened by providing a change proposal". So there is no need to volunteer to create a change proposal.
  115. # [17:04] * Joins: Marco_Ranon (chatzilla@195.99.188.20)
  116. # [17:16] <pimpbot> changes: sam: Issue 126 ccp <http://lists.w3.org/Archives/Public/public-html-diffs/2011Jan/0145.html>
  117. # [17:16] <pimpbot> bugmail: [Bug 7670] Use of prefixes is too complicated for a Web technology <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0866.html>
  118. # [17:19] * Joins: SmoothPorcupine (smooth@207.224.112.146)
  119. # [17:22] <SmoothPorcupine> So I was ranting the other day about the effects of an optional argument, talking about the hell it'll cause, and what a better alternative would be.
  120. # [17:23] <SmoothPorcupine> And one of my friends suggested I actually submit the idea.
  121. # [17:23] <SmoothPorcupine> Try to improve things instead of just hate them.
  122. # [17:24] <SmoothPorcupine> Of course, on principle, he is right, I should at least give it a shot.
  123. # [17:24] <SmoothPorcupine> Which is why I am here now.
  124. # [17:27] <SmoothPorcupine> Actually this was weeks ago. The truth is I didn't expect it was even worth ten minutes of my time bothering, nobody would bother listening and taking me seriously.
  125. # [17:28] <MikeSmith> that's surprising
  126. # [17:28] <MikeSmith> your IRC nick suggests you expect to be taken very seriously
  127. # [17:28] <SmoothPorcupine> But maybe I'm being too highly critical.
  128. # [17:29] <SmoothPorcupine> My nick or my words suggest that? :P
  129. # [17:29] <Philip> Which optional argument are you thinking of?
  130. # [17:31] <SmoothPorcupine> Well, before I get to the actual suggestion, I'd like to establish the proper environment. I still have my doubts about bothering with this at all.
  131. # [17:31] <Philip> Assuming it's in the HTML5 spec, the easiest way to get the editor to respond to suggestions is via the bug-reporting form at the top of the spec
  132. # [17:32] <Philip> (All bugs get responded to, eventually)
  133. # [17:33] <anne> SmoothPorcupine, besides what Philip said, this is IRC, no need to establish anything :)
  134. # [17:33] <SmoothPorcupine> One common reaction to an alternative is to provide all kinds of flaws with it, while basically ignoring the fact that the original idea has the same flaws.
  135. # [17:33] <Philip> (though if you suggest it here (or preferably #whatwg on Freenode) then people might say they agree/disagree and it can be resolved quicker)
  136. # [17:33] <SmoothPorcupine> Like, "OMG hydrogen is explosive!" so is gasoline.
  137. # [17:34] <SmoothPorcupine> Sure, different levels of explosives, but the principle is the same.
  138. # [17:35] <SmoothPorcupine> Well this isn't exactly an improper place to simply voice a suggestion is it?
  139. # [17:36] <Philip> If a proposal solves a problem and doesn't cause serious new problems of its own (e.g. breaking compatibility) it'll probably be taken seriously :-)
  140. # [17:36] <SmoothPorcupine> I'm sure you guys are aware of that there are people who easily reject ideas, for reasons like, "Who the hell are you?"
  141. # [17:37] <SmoothPorcupine> I figure the more people I'm directly speaking to, the worse my odds of being taken seriously.
  142. # [17:37] <SmoothPorcupine> "In-crwod" dynamics and stuff.
  143. # [17:37] <SmoothPorcupine> crowd*
  144. # [17:38] <Philip> Most changes are made in response to bug reports via the spec's bug-reporting form which are usually entirely anonymous
  145. # [17:38] <SmoothPorcupine> Like on wikipedia. A known Wikipedian can do things a newbie such as myself cannot, and this is purely by social contructs, not digitally improsed permissions.
  146. # [17:38] <Philip> so it doesn't matter who made the report
  147. # [17:39] <SmoothPorcupine> Well, that's what I'm saying. Often that /does/ matter.
  148. # [17:39] <SmoothPorcupine> There are petty people in the world. It's sometimes hard to escape them.
  149. # [17:40] <SmoothPorcupine> Ideally, I end up convincing one of you to make a bug report, or do the proper thing, and get this ball rolling.
  150. # [17:40] <anne> Rambling on might also make you seem less serious ;)
  151. # [17:41] <SmoothPorcupine> I'm just (probably excessively) cautious. :P
  152. # [17:42] <Philip> You can file a bug report yourself and it'll be equally as anonymous as if one of us files it :-)
  153. # [17:42] <SmoothPorcupine> So anyway, `in optional DOMString url`.
  154. # [17:42] <Philip> In what function?
  155. # [17:42] <SmoothPorcupine> interface History {
  156. # [17:43] <SmoothPorcupine> pushState and replaceState
  157. # [17:44] <SmoothPorcupine> Are wa majority in agreement that this is a dirty hack?
  158. # [17:44] <SmoothPorcupine> a*
  159. # [17:44] <Philip> What's the problem with it?
  160. # [17:46] <SmoothPorcupine> Well I'm sure you can think of a few right off the bat.
  161. # [17:46] <pimpbot> bugmail: [Bug 10066] replace section 3.2.6 with the alternative spec text provided (ARIA) <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0870.html> ** [Bug 11798] It has been brought to my attention by some browser vendors that browsers don't actually implement accessibility API annotations exactly the way the ARIA spec says to; instead, they have default mappings from HTML directly to the accessibility APIs that t <http://lists.
  162. # [17:47] <anne> SmoothPorcupine, it would be better if you were explicit and not assume :)
  163. # [17:47] <anne> You were really elaborate so far, no need to stop now
  164. # [17:48] <SmoothPorcupine> Well, from my naive viewpoint of not being familiar with any of you, can you not see how that may come off as the "critical of alternative but not the original" dynamic I described?
  165. # [17:49] <SmoothPorcupine> I'm sure that's not what you meant by it, but that it can be seen that way from my perspective.
  166. # [17:49] <Philip> You haven't even described the alternative yet
  167. # [17:49] <SmoothPorcupine> Yes, but you haven't been convinced an alternative is a good idea. ;D
  168. # [17:49] <Philip> You haven't tried convincing us yet :-)
  169. # [17:49] <SmoothPorcupine> yet.*
  170. # [17:50] <Philip> The problems aren't blatantly obvious (the spec wouldn't say what it says if they were) so you need to explain what they are
  171. # [17:50] <MikeSmith> SmoothPorcupine: you've convinced me already
  172. # [17:51] <SmoothPorcupine> Well this is the intent with my question. Are we in agreement that chaning the URL manually is really kind of a dirty hack to make the URLs cleaner?
  173. # [17:51] <SmoothPorcupine> changing*
  174. # [17:51] <Philip> Oh, so your problem is with the ability to change the URL rather than with the parameter being optional?
  175. # [17:51] <SmoothPorcupine> Yes.
  176. # [17:52] * Joins: aroben (aroben@17.203.12.32)
  177. # [17:53] <Philip> As I understand it, the reason for the feature is that good web applications ought to have good URLs (so you can bookmark them, copy-and-paste them, etc, and get back to the same state you're currently in)
  178. # [17:53] <SmoothPorcupine> In my view, this or more a dirty hack than using #query URLs like Facebook for example.
  179. # [17:53] <Philip> but they want to be all AJAXy and not load a whole new page every time the state changes
  180. # [17:53] <SmoothPorcupine> Er, #fragment.
  181. # [17:53] <SmoothPorcupine> Yeah.
  182. # [17:54] <Philip> so instead they do the AJAXy updates and then quietly replace the URL
  183. # [17:54] <anne> I think #fragment is way dirtier than this.
  184. # [17:55] <Philip> Using #fragment is the dirty hack that this is supposed to replace, I think - fragments are for referring to parts of a page, not for storing complex hierarchical state data (which is what the URL path is much better at)
  185. # [17:55] <SmoothPorcupine> It makes uglier URLs, of course, but consider the effects.
  186. # [17:56] <Philip> (e.g. you couldn't copy-and-paste a #fragment URL into curl or wget to get a static representation of the data)
  187. # [17:56] <SmoothPorcupine> Specifically, consider the effects of someone wishing to make not a good web application, but one that frustrates people.
  188. # [17:57] <SmoothPorcupine> They already do this with #fragment hacking, this allows them to do it with /path hacking.
  189. # [17:57] <Philip> What could they do that's more frustrating than what they can currently do?
  190. # [17:58] <Philip> (The spec intentionally prevents them from e.g. spoofing the domain name through this mechanism)
  191. # [17:59] <Philip> (I'm not trying to dismiss your thoughts, just trying to understand them better :-) )
  192. # [18:00] <SmoothPorcupine> Well, suffice to say there are some anti-hotlinkers that redirect to a new URL instead of just 403'ing. And suffice to say there are URLs on the internet you don't want to be tricked into viewing.
  193. # [18:01] <SmoothPorcupine> Someone can give users grief by making illegitimate /paths.
  194. # [18:01] * Quits: mjs (mjs@24.6.209.6) (Quit: mjs)
  195. # [18:02] <anne> You really have to elaborate that scenario. I don't see it.
  196. # [18:02] <SmoothPorcupine> You click a link, AJAX happens, URL changes, bookmark URL or something, later click it, "HAHAHAHA I DON'T LIKE DEEP LINKING YOU'VE GOT THE WRONG URL! Courtesy of HTML5!"
  197. # [18:02] <pimpbot> planet: Mike Robinson: Go offline with application cache <http://feedproxy.google.com/~r/html5doctor/~3/oiV-2fG2zbw/>
  198. # [18:04] <SmoothPorcupine> I guess I could have described this as a bug as opposed to a nefarious person.
  199. # [18:04] <SmoothPorcupine> New avenue for bugs: Oops I changed to the wrong URL.
  200. # [18:04] <SmoothPorcupine> Er, /path.
  201. # [18:05] <Philip> If a site wants to prevent deep linking, they could make /foo.html immediately redirect to /foo.html?session=wlxhjghljh which expires after 24 hours and displays rude messages to users with old links, so it doesn't seem significantly different if they use replaceState() instead
  202. # [18:05] <anne> How is that different from I redirected to the wrong path I put display:none on the <body> element or any of the other numerous problems people can create?
  203. # [18:05] * Quits: Marco_Ranon (chatzilla@195.99.188.20) (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
  204. # [18:05] * Quits: kliehm (kliehm@80.146.185.162) (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
  205. # [18:06] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  206. # [18:07] <SmoothPorcupine> /paths must be aligned properly by way of code. This code is not guaranteed to work.
  207. # [18:07] <SmoothPorcupine> Just another way for people to mess up.
  208. # [18:07] <SmoothPorcupine> And this is something you really don't want to mess up.
  209. # [18:08] <Philip> Bugs are certainly possible - it seems easy to push state URLs that won't actually work if you try using them, if you don't design and test it carefully
  210. # [18:08] <SmoothPorcupine> Not a strong argument, but the bug is there.
  211. # [18:08] <Philip> But if the alternative is doing pretty much the same with #fragment URLs instead, I think you'd be just as likely to get the same bugs there
  212. # [18:10] <SmoothPorcupine> Anyway, that's why I think /path rewriting is worse than #fragment rewriting. It creates the term "Path falsifying."
  213. # [18:10] <SmoothPorcupine> Ah, my alternative isn't to simply use #fragment instead of in optional DOMString url.
  214. # [18:11] * Joins: kliehm (kliehm@80.146.185.162)
  215. # [18:11] * Joins: mjs (mjs@67.218.110.134)
  216. # [18:11] <SmoothPorcupine> The goal of this is to have cleaner URLs without reloading the entire interface, yes?
  217. # [18:12] <Philip> Yes, if I understand it correctly
  218. # [18:12] <SmoothPorcupine> The goal is to be able to change URLs while retransmitting as little data as possible.
  219. # [18:12] * Parts: rubys (rubys@98.27.48.117)
  220. # [18:13] <SmoothPorcupine> To, in effect, only load the actual document data, not the web application.
  221. # [18:14] <SmoothPorcupine> Basically, this is about separation of content and application, is it not?
  222. # [18:15] <SmoothPorcupine> Hehe, bonus points to anyone who can guess my alternative just from that.
  223. # [18:16] <anne> You want some kind of templating and special kind of requests?
  224. # [18:16] <Philip> It might not actually be loading any document data - it could be an application that e.g. browses a local database, showing a single record and next/prev links which just replace the currently-shown record
  225. # [18:16] <pimpbot> bugmail: [Bug 11864] New: section "12 IANA considerations 12.1 text/html" suggests: "This registration is for community review and will be submitted to ...registration with IANA." I understand from this that it it intended to replace RFC 2854. If so I have a problem with the stat <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0872.html> ** [Bug 11863] New: Should the text say something explicitly about successive br elements, common
  226. # [18:17] * Joins: MikeSmith_ (MikeSmith@114.48.83.40)
  227. # [18:17] <Philip> and which wants nice URLs like /record/123/edit and /record/124/edit etc so you can bookmark ones
  228. # [18:18] <SmoothPorcupine> anne, templating yes, special /requests/, no.
  229. # [18:18] <SmoothPorcupine> Philip, that's called caching.
  230. # [18:19] * Quits: MikeSmith (MikeSmith@114.48.191.247) (Ping timeout)
  231. # [18:19] * MikeSmith_ is now known as MikeSmith
  232. # [18:19] <Philip> The idea is to not involve any network traffic at all when you click the next/prev links, even if it's to a record you've not seen before
  233. # [18:19] * Quits: kliehm (kliehm@80.146.185.162) (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
  234. # [18:19] <Philip> (since the raw data is already available in the local database)
  235. # [18:20] <Philip> so I'm not sure that caching helps
  236. # [18:20] <SmoothPorcupine> Yes. A cache is a local DB.
  237. # [18:21] * webr3 wonders if this is a meeting, or a general conversation
  238. # [18:21] <SmoothPorcupine> I'm not sure how you can avoid network traffic when attempting to view a record you do not possess.
  239. # [18:21] <Philip> webr3: The latter
  240. # [18:23] <webr3> cool, may be worth noting: http://www.w3.org/2001/tag/2011/01/HashInURI-20110115
  241. # [18:23] <pimpbot> Title: Repurposing the Hash Sign for the New Web (at www.w3.org)
  242. # [18:24] <Philip> SmoothPorcupine: In this example you do possess the record, because when you first visit the site it downloads all the data and caches it in the local database (but doesn't do any HTTP caching of anything) and then shows you a single record (whose ID is determined from the URL)
  243. # [18:25] <Philip> and when you click 'next' it wants to show a new record (based on the data it's already downloaded) and also wants to replace the URL (to contain the new record ID) but doesn't need any further network traffic
  244. # [18:26] <Philip> I think that's straightforward using pushState; I don't know what your alternative proposal is so I don't know if it works with that too
  245. # [18:26] <MikeSmith> webr3: it's a kind of spontaneous "meeting of the minds"
  246. # [18:26] <MikeSmith> like when Einstein met Groucho Marx
  247. # [18:29] <SmoothPorcupine> Philip, so if I understand this, you are, in effect, loading an entire series of pages by viewing any one of them.
  248. # [18:29] <SmoothPorcupine> Because you download the DB, you can render every page.
  249. # [18:30] <Philip> Yes - it always downloads all the data needed to construct all the pages, then displays one page at a time (with the displayed page and the URL always staying in sync)
  250. # [18:30] <Philip> and doesn't do any more network traffic after the initial download
  251. # [18:30] <SmoothPorcupine> When accessing any /record/123/edit URL you download the entire DB and the application that renders it.
  252. # [18:31] <Philip> Yes (unless you access that URL via clicking 'next' from /record/122/edit in which case it already has all the data and simply updates the input elements)
  253. # [18:31] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
  254. # [18:32] <SmoothPorcupine> I think that's more of an after-feature than the goal we were intially trying to achieve.
  255. # [18:32] <SmoothPorcupine> Initially, we were trying to avoid loading the application parts when not necessary.
  256. # [18:34] <SmoothPorcupine> And the model of data requires different /paths to retrive the data.
  257. # [18:34] <anne> I'ts not necessarily about avoiding loading data
  258. # [18:35] <anne> It's about creating a more seamless experience while still having bookmarkable state
  259. # [18:35] <Philip> Maybe a more realistic example is Gmail, which doesn't download all the mail data but often seems to download and cache the inbox contents in advance, so you click 'inbox' and it changes the URL to https://mail.google.com/mail/#inbox and immediately shows the inbox without any further network traffic
  260. # [18:35] <pimpbot> Title: Gmail: Email from Google (at mail.google.com)
  261. # [18:35] <anne> E.g. sorting a table which can be done entirely client-side could still be a reason to change the URL
  262. # [18:35] <SmoothPorcupine> When your data model is what you describe, you have a "document" (DB) /records, and you ought to identify parts of that document with #fragments.
  263. # [18:35] <anne> So that when the user copies the URL and gives it to someone else that person will look at the same table.
  264. # [18:36] <anne> Even if that other user has script disabled or something like that...
  265. # [18:36] * Joins: miketaylr (miketaylr@206.217.92.186)
  266. # [18:36] <anne> That does not work with #fragment
  267. # [18:36] <anne> And #fragment is meant to highlight a specific location
  268. # [18:37] <SmoothPorcupine> Yes, that is the purpose isn't it?
  269. # [18:40] * Quits: SmoothPorcupine (smooth@207.224.112.146) (Ping timeout)
  270. # [18:46] <pimpbot> bugmail: [Bug 11864] section "12 IANA considerations 12.1 text/html" suggests: "This registration is for community review and will be submitted to ...registration with IANA." I understand from this that it it intended to replace RFC 2854. If so I have a problem with the stat <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0873.html>
  271. # [18:47] * Quits: Norm (ndw@96.32.124.29) (Ping timeout)
  272. # [18:50] * Quits: ArtB (ArtB@192.100.124.218) (Quit: Leaving.)
  273. # [18:58] <webr3> the problem, as I see it, is that there are two application states, and only one way to reference them, increasingly a URL identifies a web application (client side app, interactive document), and that application itself has it's own state and view, which may or may not correspond to a particular view of certain network resource
  274. # [18:59] <webr3> the only thing one can currently leverage, is localStorage - but then you can't share application state, or fragment identifiers, which are icnreasingly used for several purposes ranging from segements of documents, to media fragments, to application state changes
  275. # [19:00] <webr3> however, there isn't much point in globally naming something that's only locally available, such as a view of a particular data set in cached memory - this is where people step on fragments to get the history / state change registered, but don't really need it / are using the wrong method
  276. # [19:01] * webr3 summarizes so as to understand the issue
  277. # [19:02] <webr3> offset, one could "share" the local application state and data by serializing it and storing it at a web accessible address, then the fragment would become a global name - so perhaps it is the correct approach
  278. # [19:08] * Quits: mjs (mjs@67.218.110.134) (Quit: mjs)
  279. # [19:18] * Joins: mjs (mjs@17.244.9.57)
  280. # [19:41] * Quits: myakura (myakura@122.26.253.32) (Client exited)
  281. # [19:48] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
  282. # [19:48] * Joins: miketaylr (miketaylr@206.217.92.186)
  283. # [20:28] * Quits: anne (annevk@24.132.106.179) (Quit: anne)
  284. # [20:30] * Joins: Lachy (Lachlan@84.215.59.50)
  285. # [20:57] * Joins: J_Voracek (irchon@166.205.137.31)
  286. # [20:57] * Quits: J_Voracek (irchon@166.205.137.31) (Client exited)
  287. # [20:58] * Joins: Stevef (chatzilla@94.174.12.122)
  288. # [21:04] * Quits: mjs (mjs@17.244.9.57) (Quit: mjs)
  289. # [21:11] * Joins: aroben_ (aroben@17.246.18.162)
  290. # [21:12] * Joins: mjs (mjs@17.246.18.39)
  291. # [21:13] * Quits: aroben (aroben@17.203.12.32) (Ping timeout)
  292. # [21:13] * Joins: aroben__ (aroben@17.203.12.32)
  293. # [21:15] * Quits: aroben_ (aroben@17.246.18.162) (Ping timeout)
  294. # [21:56] * Joins: miketayl_r (miketaylr@206.217.92.186)
  295. # [21:57] * Quits: Stevef (chatzilla@94.174.12.122) (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630])
  296. # [21:59] * Quits: miketaylr (miketaylr@206.217.92.186) (Ping timeout)
  297. # [22:17] * Quits: Lachy (Lachlan@84.215.59.50) (Quit: Leaving)
  298. # [22:18] * Joins: Lachy (Lachlan@84.215.59.50)
  299. # [22:24] * Quits: webr3 (nathan@86.133.147.138) (Ping timeout)
  300. # [22:29] * Joins: webr3 (nathan@217.42.204.134)
  301. # [22:30] * Quits: miketayl_r (miketaylr@206.217.92.186) (Client exited)
  302. # [22:30] * Joins: miketaylr (miketaylr@206.217.92.186)
  303. # [22:46] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
  304. # [22:57] * Quits: Martijnc (Martijnc@91.176.93.127) (Quit: Martijnc)
  305. # [23:17] <pimpbot> bugmail: [Bug 11869] New: This section will be moved to a more appropriate location in due course; it is here currently to keep it near the device element to allow reviewers to look at it. <http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0874.html>
  306. # [23:32] * Joins: myakura (myakura@122.26.253.32)
  307. # [23:46] * Joins: aroben_ (aroben@17.203.12.32)
  308. # [23:48] * Quits: aroben__ (aroben@17.203.12.32) (Ping timeout)
  309. # Session Close: Wed Jan 26 00:00:00 2011

The end :)