/irc-logs / w3c / #webapps / 2008-10-07 / end

Options:

  1. # Session Start: Tue Oct 07 00:00:00 2008
  2. # Session Ident: #webapps
  3. # [00:04] * Joins: mjs (mjs@17.244.18.166)
  4. # [00:12] * Joins: mjs_ (mjs@17.203.14.139)
  5. # [00:13] * Quits: mjs (mjs@17.244.18.166) (Ping timeout)
  6. # [00:49] * Quits: marcos (marcos@87.196.26.118) (Quit: marcos)
  7. # [01:03] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  8. # [01:07] * Quits: aroben (aroben@68.81.234.95) (Connection reset by peer)
  9. # [01:24] * Joins: hober (ted@206.212.254.2)
  10. # [01:29] * Joins: marcos (marcos@87.196.26.118)
  11. # [01:34] * Quits: marcos (marcos@87.196.26.118) (Quit: marcos)
  12. # [02:08] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  13. # [02:15] * Quits: mjs_ (mjs@17.203.14.139) (Ping timeout)
  14. # [03:26] * Joins: harry (kcome@58.213.195.51)
  15. # [03:39] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  16. # [03:41] * Joins: mjs (mjs@17.203.14.139)
  17. # [04:37] * Quits: mjs (mjs@17.203.14.139) (Quit: mjs)
  18. # [06:14] * Joins: harryl (kcome@121.229.69.165)
  19. # [06:16] * Quits: harry (kcome@58.213.195.51) (Ping timeout)
  20. # [06:17] * Joins: mjs (mjs@69.181.43.20)
  21. # [06:28] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  22. # [07:46] * Quits: mjs (mjs@69.181.43.20) (Ping timeout)
  23. # [07:51] * Joins: mjs (mjs@69.181.43.20)
  24. # [08:11] * Joins: mjs_ (mjs@69.181.43.20)
  25. # [08:11] * Quits: mjs (mjs@69.181.43.20) (Connection reset by peer)
  26. # [08:20] * Quits: arve (arve@80.202.65.163) (Quit: Leaving)
  27. # [08:44] * Quits: mjs_ (mjs@69.181.43.20) (Quit: mjs_)
  28. # [09:43] * Joins: mjs (mjs@69.181.43.20)
  29. # [09:47] * Joins: arve (arve@213.236.208.22)
  30. # [11:11] * Joins: tlr (tlr@128.30.52.30)
  31. # [11:13] * Joins: marcos (marcos@87.196.62.159)
  32. # [12:13] <smaug> Why FileDialog must dispatch any events?
  33. # [12:13] * Quits: harryl (kcome@121.229.69.165) (Ping timeout)
  34. # [12:13] <smaug> hmm
  35. # [12:13] <anne> I don't like FileDialog
  36. # [12:14] <smaug> I guess that depends on whether open() is blocking
  37. # [12:14] * anne thinks it should be on HTMLInputElement
  38. # [12:15] <smaug> scripts should not be able to call fd.open() without permission
  39. # [12:35] <arve> I don't like it much that interface names are going to clash with File I/O
  40. # [12:41] * Joins: ArtB (ce846302@128.30.52.43)
  41. # [12:51] <arve> Repeating for Art:
  42. # [12:51] <arve> I don't like it much that interface names are going to clash with File I/O
  43. # [12:52] <arve> and I think actually developing File I/O is a more viable way
  44. # [12:53] <arve> the spec also lacks a stream interface
  45. # [12:54] <arve> I really don't want to load a 12MB image if I want the exif data for it
  46. # [12:59] <marcos> arve, agreed
  47. # [13:16] <anne> smaug, indeed, that's why it sucks for the Web
  48. # [13:18] <arve> counterproposal: drop file upload, find an editor for file I/O and find an integration point with HTML5 file upload controls
  49. # [13:19] <arve> I'd really like to see support for <input type="folder">
  50. # [13:20] * tlr is now known as tlr-bbiab
  51. # [13:36] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  52. # [13:36] * Joins: arve (arve@213.236.208.22)
  53. # [13:38] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  54. # [13:50] * Joins: arve (arve@213.236.208.22)
  55. # [13:51] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  56. # [13:57] * Joins: shepazu (schepers@128.30.52.30)
  57. # [13:57] * Quits: arve (arve@213.236.208.22) (Client exited)
  58. # [13:58] * Joins: arve (arve@213.236.208.22)
  59. # [14:04] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  60. # [14:09] * tlr-bbiab is now known as tlr
  61. # [14:16] * Quits: anne (annevk@213.236.208.22) (Client exited)
  62. # [14:16] * Joins: anne (annevk@213.236.208.22)
  63. # [14:30] * ArtB starts to catch up ...
  64. # [14:31] <ArtB> Arve, do you have a pointer to the File I/O spec?
  65. # [14:31] <ArtB> I seem to recall it was proposed to the Web API WG and not WebApps
  66. # [14:33] <arve> http://dev.w3.org/2006/webapi/fileio/fileIO.htm
  67. # [14:34] <arve> see also http://lists.w3.org/Archives/Public/public-webapi/2008May/0065.html
  68. # [14:34] <ArtB> thanks, Arve
  69. # [14:35] <arve> and http://lists.w3.org/Archives/Public/public-webapi/2008May/0304.html
  70. # [14:37] <ArtB> did the Web API WG ever have any type of CfC to work on the File I/O spec?
  71. # [14:38] <arve> don't think so, you'd have to ask chaals
  72. # [14:48] * Joins: harryl (kcome@121.229.69.165)
  73. # [14:50] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  74. # [15:13] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  75. # [15:22] * Joins: shepazu (schepers@128.30.52.30)
  76. # [15:22] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  77. # [15:44] * Quits: harryl (kcome@121.229.69.165) (Ping timeout)
  78. # [15:46] * Quits: anne (annevk@213.236.208.22) (Client exited)
  79. # [15:46] * Joins: anne (annevk@213.236.208.22)
  80. # [15:49] * Quits: anne (annevk@213.236.208.22) (Ping timeout)
  81. # [15:53] <smaug> arve: what would <input type="folder"> do? Upload all the files in the folder?
  82. # [15:55] * Joins: anne (annevk@213.236.208.22)
  83. # [15:58] * Quits: tlr (tlr@128.30.52.30) (Ping timeout)
  84. # [16:00] * Joins: aroben (aroben@68.81.234.95)
  85. # [16:01] * Joins: tlr (tlr@128.30.52.30)
  86. # [16:05] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  87. # [16:07] * Joins: harryl (kcome@222.94.60.217)
  88. # [16:11] <arve> smaug: no clear thought as of yet, but something like that
  89. # [16:14] <anne> how is it better from just selecting all files in the folder?
  90. # [16:16] <MikeSmith> anne: so how are we going to resolve the issue that was raised by the XHTML WG regarding XHR normatively referencing HTML5?
  91. # [16:18] <arve> anne: there is some implied behavior wrt subfolders
  92. # [16:26] <anne> MikeSmith, I thought it was raised by the Forms WG, anyway, we can reply saying that it's sort of required?
  93. # [16:27] <MikeSmith> so that means we will not be able to take XHR to Rec until the HTML5 spec is at least at PR
  94. # [16:28] <anne> well, a) yes, b) someone moves those parts of HTML5 separately to REC solving that "issue", or c) we mark those parts that depend on HTML5 non-normative once we have XHR fully implemented and move on
  95. # [16:33] <MikeSmith> anne: I see
  96. # [16:34] <anne> I'm open to better suggestions
  97. # [16:45] <MikeSmith> anne: this is actually not a issue unique to XHR .. we have other specs that are referencing parts of HTML5 (or should be).. so we have a general issue of needing to decide how to deal with it
  98. # [16:47] <MikeSmith> I would think "b) someone moves those parts of HTML5 separately to REC" is likely the only practical solution
  99. # [16:49] <anne> all three are equally practical in my opinion, just depends on what you want to do
  100. # [16:50] <anne> actually, b) is probably the least practical, as so far we haven't been able to find people to edit specs
  101. # [16:50] <anne> let alone port maintain bits currently part of HTML5
  102. # [17:23] <MikeSmith> ArtB: I don't think it's likely that we can get the FileUpload spec published before the moratorium
  103. # [17:34] * Parts: anne (annevk@213.236.208.22)
  104. # [17:38] <ArtB> MikeSmith, bummer on FileUpload
  105. # [17:39] <ArtB> MikeSmith, one or more of the Widgets specs has a dependency on HTML5
  106. # [17:39] <MikeSmith> yeah
  107. # [17:39] <ArtB> We talked about doing a C&P [marcos to verify]
  108. # [17:40] <ArtB> Not ideal :-(
  109. # [17:40] <ArtB> how much of XHR overlaps with HTM5?
  110. # [17:40] <marcos> yep, copy paste :D
  111. # [17:42] <MikeSmith> XHR doesn't overlap, it just has some very specific dependencies on parts of the HTML5 spec
  112. # [17:43] <ArtB> sorry "overlap" was a poor choice of words
  113. # [17:43] <MikeSmith> the Content-Type header thing is one of them
  114. # [17:43] <MikeSmith> also the definitions of Window object and Document
  115. # [17:44] <MikeSmith> and then the list of stuff in 2.2
  116. # [17:44] <MikeSmith> http://dev.w3.org/2006/webapi/XMLHttpRequest/#terminology
  117. # [18:10] * Joins: annevk_win32 (d5ecd016@67.207.141.120)
  118. # [18:10] <annevk_win32> event loop is likely to become another dependency
  119. # [19:33] * Quits: ArtB (ce846302@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  120. # [19:36] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
  121. # [19:47] * Quits: annevk_win32 (d5ecd016@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
  122. # [19:57] * Quits: harryl (kcome@222.94.60.217) (Ping timeout)
  123. # [20:36] <Hixie> MikeSmith: there is a d) option too. change w3c process to handle specs having multiple stability levels like html5 does.
  124. # [22:10] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  125. # [22:12] * marcos likes option d!
  126. # [22:21] <marcos> makes sense for a spec the size of HTML5... though you are kinda screwed if a stable bit depends on an unstable bit.
  127. # [22:21] <smaug> Hixie: how do you specify the "stability level" of some part of HTML5 ?
  128. # [22:21] <marcos> It's not like saying, "you can move into this house, but the plumbing for the toilet is not yet in place"?
  129. # [22:31] * Quits: tlr (tlr@128.30.52.30) (Quit: this day seems to be done with me)
  130. # [22:50] <Hixie> smaug: see the whatwg version of the spec -- it has little markers in the margins
  131. # [22:53] <smaug> Hixie: but who decides those levels?
  132. # [22:55] <smaug> or how
  133. # [22:55] <Hixie> for whatwg, me, based on what i know the stability of the spec to be
  134. # [22:56] <Hixie> for w3c specs, one would imagine that the same mechanism that decides spc stability would be used
  135. # [22:58] <smaug> ok
  136. # [23:25] * Quits: mjs (mjs@69.181.43.20) (Quit: mjs)
  137. # [23:46] * Joins: mjs (mjs@69.181.43.20)
  138. # [23:46] * Quits: mjs (mjs@69.181.43.20) (Connection reset by peer)
  139. # [23:47] * Joins: mjs (mjs@69.181.43.20)
  140. # [23:52] * Quits: mjs (mjs@69.181.43.20) (Quit: mjs)
  141. # Session Close: Wed Oct 08 00:00:00 2008

The end :)