/irc-logs / freenode / #whatwg / 2010-01-09 / end

Options:

  1. # Session Start: Sat Jan 09 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:01] * Quits: smaug_ (n=chatzill@cs181150024.pp.htv.fi) ("ChatZilla 0.9.86 [Firefox 3.7a1pre/20091230113157]")
  4. # [00:01] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  5. # [00:08] * Quits: virtuelv (n=virtuelv@162.179.251.212.customer.cdi.no) (Read error: 110 (Connection timed out))
  6. # [00:09] * Joins: erlehmann (n=erlehman@82.113.106.6)
  7. # [00:10] * Joins: Lachy (n=Lachlan@85.196.122.246)
  8. # [00:15] * Quits: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  9. # [00:21] * Quits: cpharmston (n=Adium@office.threespot.com) ("Leaving.")
  10. # [00:24] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) ("ChatZilla 0.9.86 [Firefox 3.5.7/20100106054634]")
  11. # [00:29] * Quits: danbri (n=danbri@unaffiliated/danbri) (Remote closed the connection)
  12. # [00:49] * Parts: bfulgham (n=brent@wsip-72-215-191-226.sb.sd.cox.net)
  13. # [00:56] <othermaciej> is dev.w3.org still horked?
  14. # [01:01] <Hixie> i just sent out the FPWD request i meant to send out last night for 2dcontext
  15. # [01:01] <Hixie> i threw in the other drafts while i was at it
  16. # [01:02] <Hixie> dev.w3.org seems to work ok except for some reason there's a bit of a delay sometimes
  17. # [01:02] <Hixie> e.g. http://dev.w3.org/html5/spec/Overview.html doesn't reflect what's in CVS
  18. # [01:06] * Joins: JonathanNeal (n=Jonathan@rrcs-76-79-114-213.west.biz.rr.com)
  19. # [01:06] <othermaciej> is the intro useful as a spec by itself? it doesn't seem to include anything normative, and the link to the modules probably isn't suitable for the TR page
  20. # [01:06] <JonathanNeal> Hello hello. :D
  21. # [01:06] * Joins: cpharmston (n=Adium@68.48.43.198)
  22. # [01:07] <JonathanNeal> Anyone here using WYSIWYG editors and HTML5?
  23. # [01:07] <Hixie> othermaciej: the TR version of that page links to the /TR/ page instead
  24. # [01:07] <Hixie> whether it's useful or not is another question
  25. # [01:07] <Hixie> i wasn't sure where to put the intro material though
  26. # [01:07] <Hixie> so i figured that made the most sense
  27. # [01:08] * Quits: cpharmston (n=Adium@68.48.43.198) (Remote closed the connection)
  28. # [01:08] <Hixie> personally i think the whole splitting spec thing is a waste of time and woul rather we went back to complete.html, but i'm trying to find solutions that work for the htmlwg members
  29. # [01:09] * Joins: cpharmston (n=Adium@68.48.43.198)
  30. # [01:10] <othermaciej> indeed, I see you have made a solomonic effort
  31. # [01:10] <othermaciej> the intro seems to relate most to either the core or vocabulary specs, not really sure which
  32. # [01:14] <othermaciej> core vs. vocabulary ended up kind of a wacky split, since core defines parts of the vocabulary
  33. # [01:14] <JonathanNeal> I just wanted to know the name of one WYSIWYG editor that supports new HTML5 elements. CKEditor moves them around like ragdolls and TinyMCE seems to replace them with other elements.
  34. # [01:16] <zcorpan__> JonathanNeal: why would you want to handle the new elements with wysiwyg rather than in handwritten templates?
  35. # [01:16] <cardona507> hixie - hello - am working on some graphics for <meter> and I am wondering if user agents will always show it as a small bar with part of it colored in similar to the usenet example that is live in the spec? Or will it sometimes be rendered as a clock other times a thermometer other times a bar etc depending on the situation?
  36. # [01:16] <JonathanNeal> zcorpan__, there may be instances where I want to create my own section or articles within one inside the wysiwyg
  37. # [01:17] * Joins: JvA (n=no@h-62-33.A163.priv.bahnhof.se)
  38. # [01:20] <zcorpan__> JonathanNeal: for section, you can use implied section by just using a heading. for article.. why would you want to have a nested article in wysiwyg?
  39. # [01:21] <JonathanNeal> zcorpan__, while I don't mind getting into those details, they detract from the fact that all new html5 elements fail in the most well known wysiwyg editors and I was wondering if that was a limitation of the browser or the wysiwyg.
  40. # [01:23] * Quits: dave_levin (n=dave_lev@74.125.59.73)
  41. # [01:23] <zcorpan__> ok. my guess is that the wysiwyg could support them even though they're not known elements in the browser
  42. # [01:24] <zcorpan__> and even if they're known elements in the browser, they'd still fail in existing editors
  43. # [01:25] <JonathanNeal> ok. i checked a few months ago and no one had tried html5 in a wysiwyg then either.
  44. # [01:25] <zcorpan__> maybe you could try implementing it yourself :)
  45. # [01:26] <JonathanNeal> I did, a few months ago.
  46. # [01:26] <zcorpan__> oh cool
  47. # [01:26] <JonathanNeal> I created various work-arounds that worked enough for us to push to our new site.
  48. # [01:26] <JonathanNeal> Problem is our product is kinda like a cms.
  49. # [01:26] <JonathanNeal> So when they hear our new site is HTML5, they think they can just make HTML5 sites with our product.
  50. # [01:27] <JonathanNeal> And all the support questions are coming to me because I did it, but I'm saying "I hacked the thing up to the point where it works because it ignores the elements in the wysiwyg, because it still does not support them" --- that made me think of pinging this chan again :D
  51. # [01:28] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  52. # [01:29] <zcorpan__> maybe you could file requests for proper html5 support in popular editors
  53. # [01:29] * Quits: cpharmston (n=Adium@68.48.43.198) (SendQ exceeded)
  54. # [01:30] * Joins: cpharmston (n=Adium@68.48.43.198)
  55. # [01:31] <JonathanNeal> Yea, I've seen it and seen it ignored, but I'll make some noise.
  56. # [01:32] * Quits: cpharmston (n=Adium@68.48.43.198) (Read error: 60 (Operation timed out))
  57. # [01:43] * Quits: dglazkov (n=dglazkov@nat/google/x-ppldytoygdjcemtn)
  58. # [01:47] * ojan is now known as ojan_away
  59. # [01:49] * Quits: zcorpan__ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  60. # [01:54] * Quits: JvA (n=no@h-62-33.A163.priv.bahnhof.se)
  61. # [01:59] <cardona507> any feedback on this for <meter> http://img46.imageshack.us/img46/3571/whatwgmeterex101.png ?
  62. # [02:00] <cardona507> I am also creating a thermometer
  63. # [02:00] <Hixie> nice
  64. # [02:01] <Hixie> uh the number of notches on that dial makes no sense :-)
  65. # [02:01] <Hixie> you have four in the first bit and three for the rest :-)
  66. # [02:01] <Hixie> should be four each time if it's a decimal dial
  67. # [02:01] <cardona507> doh :) hehe
  68. # [02:01] <cardona507> yeah - that was the intention :)
  69. # [02:01] <cardona507> hehe - i'll fix that real quick
  70. # [02:01] <Hixie> :-)
  71. # [02:10] * Quits: nattokirai (n=nattokir@y224241.dynamic.ppp.asahi-net.or.jp)
  72. # [02:15] <Hixie> ok <details> is back
  73. # [02:16] <cardona507> ok - I fixed the notches on the dial - http://img132.imageshack.us/img132/3571/whatwgmeterex101.png
  74. # [02:18] <Hixie> nice
  75. # [02:20] <cardona507> thanks
  76. # [02:20] <daedb> Nice to see <details> back... there is still hope :)
  77. # [02:20] <Hixie> this is #whatwg, so technically <details> never left :-P
  78. # [02:20] <Hixie> it only briefly was out of the w3c version of the spec
  79. # [02:20] <Hixie> never left the whatwg one
  80. # [02:22] <daedb> True, but I want both versions to be nice, not just the Whatwg one ;-p
  81. # [02:22] <Hixie> well with the splits and stuff the w3c one is no longer nice :-(
  82. # [02:24] <daedb> I don't understand the split out "core" spec... it doesn't contain the elements and syntax sections? I don't get how those are not part of the core of the language...
  83. # [02:26] <Hixie> see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8365 for the reasoning
  84. # [02:26] <Hixie> i agree that it doesn't make much sense, i'm just trying to address the bugs that are filed according to the htmlwg process
  85. # [02:26] <othermaciej> I understand some of the motivation for the split but I'm not sure it ended up sensible
  86. # [02:27] <cardona507> so the new elements aren't in the "core" spec?
  87. # [02:27] <othermaciej> none of the elements are in the "core" spec (although a few attributes are)
  88. # [02:28] <cardona507> gotcha
  89. # [02:28] <cardona507> alot of specs
  90. # [02:29] <othermaciej> also, while I don't personally care much how many different documents there area, the resulting broken cross-references make some things hard to follow
  91. # [02:29] <Hixie> the attributes in the "core" spec are there because shelley didn't want "hidden" in the vocabulary spec, and it seemed the others were thematically related so i figured i should move them all together
  92. # [02:33] * Quits: othermaciej (n=mjs@17.246.19.227)
  93. # [02:41] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) ("ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  94. # [02:42] * Joins: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  95. # [02:44] <cardona507> How about this for <meter> http://img262.imageshack.us/img262/434/whatwgmeterex201.png ?
  96. # [02:45] <cardona507> hehe - expect the C would say 50 at the bottom :)
  97. # [02:46] <cardona507> like this http://img23.imageshack.us/img23/434/whatwgmeterex201.png
  98. # [02:51] <Hixie> interesting, though i'm not sure a browser would ever be that specific, since it doesn't really know it's a temperature gauge from the markup...
  99. # [02:51] <Hixie> maybe that would be better as an xbl2 example
  100. # [02:52] <Hixie> (as a <meter> binding)
  101. # [02:53] <cardona507> what examples can you image a browser implementing?
  102. # [02:54] <cardona507> for example the one from the spec that talks about a tooltip appearing that says "23 seconds" - should I create that as a digital clock face?
  103. # [02:54] * ojan_away is now known as ojan
  104. # [02:54] <cardona507> and have a mouse pointer and tooltip of course
  105. # [02:58] <Hixie> i think gauges are more likely to be generic things like simple bars
  106. # [03:00] <Hixie> mac os x has some built-in indicators that might give some inspiration
  107. # [03:00] <Hixie> gotta go cook dinner, bbiab
  108. # [03:01] * Quits: fupp (n=User@mg038a.studby.ntnu.no) (niven.freenode.net irc.freenode.net)
  109. # [03:02] * Joins: fupp (n=User@mg038a.studby.ntnu.no)
  110. # [03:09] * Quits: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Read error: 110 (Connection timed out))
  111. # [03:14] * Quits: JonathanNeal (n=Jonathan@rrcs-76-79-114-213.west.biz.rr.com) (Read error: 60 (Operation timed out))
  112. # [03:20] * Joins: tyoshino (n=tyoshino@220.109.219.244)
  113. # [03:24] * Quits: erlehmann (n=erlehman@82.113.106.6) ("Ex-Chat")
  114. # [03:25] <cardona507> web applications 1.0 - wow
  115. # [03:29] <cardona507> the kitchen sink - heh
  116. # [03:50] * Philip` wonders if it's possible to have a kitchen sink, or if instead it would float
  117. # [03:51] <cardona507> thats a question for #css :)
  118. # [03:55] * Joins: JonathanNeal (n=Jonathan@76-219-69-134.lightspeed.breaca.sbcglobal.net)
  119. # [04:15] * Joins: cying (n=cying@adsl-75-41-112-162.dsl.pltn13.sbcglobal.net)
  120. # [04:18] * Quits: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net) (Read error: 113 (No route to host))
  121. # [04:22] * Quits: ap (n=ap@17.246.19.5)
  122. # [04:25] * Quits: jwalden (n=waldo@71.147.38.186) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.1.6/20091216142458]")
  123. # [04:30] * Quits: ttepasse (n=ttepas--@ip-95-222-120-117.unitymediagroup.de) ("404")
  124. # [04:40] * Quits: cying (n=cying@adsl-75-41-112-162.dsl.pltn13.sbcglobal.net) (Connection timed out)
  125. # [04:45] * Quits: JonathanNeal (n=Jonathan@76-219-69-134.lightspeed.breaca.sbcglobal.net) (Read error: 110 (Connection timed out))
  126. # [04:46] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  127. # [04:46] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  128. # [05:04] * Quits: ojan (n=ojan@72.14.229.81)
  129. # [05:06] * Joins: JonathanNeal (n=Jonathan@adsl-75-51-65-4.dsl.lsan03.sbcglobal.net)
  130. # [05:17] * Quits: Heimidal (n=heimidal@unaffiliated/heimidal) (Remote closed the connection)
  131. # [05:24] * Joins: cpharmston (n=Adium@68.48.43.198)
  132. # [05:42] * Joins: cohitre (n=cohitre@c-98-237-252-207.hsd1.wa.comcast.net)
  133. # [05:42] * Parts: cohitre (n=cohitre@c-98-237-252-207.hsd1.wa.comcast.net)
  134. # [05:44] * Quits: JonathanNeal (n=Jonathan@adsl-75-51-65-4.dsl.lsan03.sbcglobal.net) (Read error: 110 (Connection timed out))
  135. # [05:48] * Quits: cedricv (n=cedric@112.199.182.134) (Read error: 54 (Connection reset by peer))
  136. # [05:49] * Quits: cpharmston (n=Adium@68.48.43.198) (SendQ exceeded)
  137. # [05:51] * Joins: cpharmston (n=Adium@68.48.43.198)
  138. # [05:51] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  139. # [05:55] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  140. # [05:56] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  141. # [05:59] * Quits: cpharmston (n=Adium@68.48.43.198) (Read error: 104 (Connection reset by peer))
  142. # [05:59] * Joins: cpharmston (n=Adium@68.48.43.198)
  143. # [06:05] * Joins: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  144. # [06:05] * Quits: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net) (Remote closed the connection)
  145. # [06:19] * Quits: cpharmston (n=Adium@68.48.43.198) (SendQ exceeded)
  146. # [06:25] * Joins: chuck_ (n=cpharmst@68.48.43.198)
  147. # [06:44] * Quits: chuck_ (n=cpharmst@68.48.43.198) (Read error: 110 (Connection timed out))
  148. # [06:44] * Quits: karlcow (n=karl@nerval.la-grange.net) (Remote closed the connection)
  149. # [07:01] * Quits: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Read error: 110 (Connection timed out))
  150. # [07:02] * Joins: dimich_ (n=dimich@98.125.242.107)
  151. # [07:20] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
  152. # [07:20] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  153. # [07:32] * Joins: Heimidal (n=heimidal@unaffiliated/heimidal)
  154. # [07:45] <Lachy> Hixie, these new spec splits seem crazy. WTF?
  155. # [07:46] <Lachy> can't we come up with a way to keep everything in the same spec, but perhaps more cleanly divided into Core and Vocabulary sections, and have that distinction clearly reflected in the ordering of sections and splitting of the multi-page doc.
  156. # [07:55] * Joins: nattokirai (n=nattokir@y224241.dynamic.ppp.asahi-net.or.jp)
  157. # [08:06] <Lachy> Hixie, "the attributes in the "core" spec are there because shelley didn't want "hidden" in the vocabulary spec..." - that's the most illogical and irrational justification ever.
  158. # [08:06] <Lachy> So just because Shelley wants something, you do it now? WTF?!
  159. # [08:10] * Joins: yutak_home (n=kee@N038037.ppp.dion.ne.jp)
  160. # [08:33] <hsivonen> at least it looks like the <details> removal didn't last for long
  161. # [08:52] * Quits: yutak_home (n=kee@N038037.ppp.dion.ne.jp) ("Ex-Chat")
  162. # [08:55] * Dashiva ponders if gauge could be used by simply aliasing all the common misspellings to be the same element
  163. # [08:56] <Hixie> heh
  164. # [08:56] <Hixie> not an impossible idea
  165. # [08:56] <Hixie> doesn't work for xml though
  166. # [08:56] <Hixie> or createElement()
  167. # [08:59] <Dashiva> XML assumes competent authors in the first place, surely competent enough to use spell checking. createElement is problematic, though :)
  168. # [09:00] <Hixie> dude i can't spell gauge to save my life
  169. # [09:00] <Hixie> i typo it 9 times out of 10
  170. # [09:00] <Lachy> no, let's not repeat the same mistake with <image>
  171. # [09:00] <Hixie> it's not like i don't know how to spell it
  172. # [09:00] <Hixie> i just always get it wrong
  173. # [09:01] <Hixie> and if "<script langauje=''>" is anything to go by, i am by far not the exception
  174. # [09:02] <Dashiva> That's an invisible and harmless typo, though
  175. # [09:02] <Hixie> the problem isn't people not catching it
  176. # [09:02] <Hixie> the problem is people wasting time making the mistake in the first place
  177. # [09:03] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  178. # [09:05] <hsivonen> I find it weird that people find gauge hard to spell
  179. # [09:06] <Hixie> i find it easy to spell, hard to type
  180. # [09:06] <hsivonen> probably because I think of it by pronouncing it in Finnish in my mind, which makes the spelling unambiguous
  181. # [09:06] <hsivonen> oh
  182. # [09:09] <Dashiva> Features defined in a very large
  183. # [09:09] <Dashiva> spec, like SVG 1.2 Tiny
  184. # [09:09] <Dashiva> If Tiny is "very large", what is the full SVG spec? :)
  185. # [09:10] <Hixie> tiny is almost as large as html5
  186. # [09:19] <hsivonen> should Tiny be split?!? ;-)
  187. # [09:20] <Hixie> imho no, though "full" should be dropped :-)
  188. # [09:22] <hsivonen> I think aspects of Tiny (xml:id, XML Events, textArea) should be dropped, too
  189. # [09:23] <Hixie> yes
  190. # [09:36] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  191. # [09:37] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  192. # [10:06] <Hixie> can anyone figure out a succint way of presenting http://www.whatwg.org/specs/diagram.html ?
  193. # [10:09] <Dashiva> How about just listing each one (not WA 1.0), and then having a note "There's also a combined view of all the active specs <WA 1.0>"
  194. # [10:13] <Hixie> that doesn't really handle the HTML part (click the button), nor the Web SQL bit (at the bottom)
  195. # [10:16] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  196. # [10:18] * Hixie ponders taking out the Web Apps 1.0 column in lachy's table, and replacing it with a single link below
  197. # [10:18] <Hixie> i don't know that we want to encourage that view
  198. # [10:20] <Hixie> Lachy: any opinion?
  199. # [10:20] <Lachy> Hixie, why not?
  200. # [10:21] <Lachy> that version of the spec is the best
  201. # [10:21] <Lachy> also, I think presenting that diagram as a simple tree structure is easiest:
  202. # [10:21] <Lachy> WHATWG Work
  203. # [10:21] <Lachy> +- Web Applications 1.0
  204. # [10:21] <Lachy> | |
  205. # [10:21] <Lachy> | +- WHATWG HTML
  206. # [10:21] <Lachy> | | |
  207. # [10:21] <Lachy> | | +- HTML5 (W3C)
  208. # [10:21] <Lachy> | | +- Microdata
  209. # [10:21] <Lachy> | | +- 2D Context
  210. # [10:21] <Lachy> | | +- HTML Device
  211. # [10:21] <Lachy> | |
  212. # [10:21] <Lachy> | +- Web Workers
  213. # [10:21] <Lachy> | +- Web Storage
  214. # [10:21] <Lachy> | +- Web Sockets API
  215. # [10:21] <Lachy> | +- Web Sockets Protocol
  216. # [10:21] <Lachy> | +- Server-sent Events
  217. # [10:21] <Lachy> |
  218. # [10:21] <Lachy> + Web SQL Database
  219. # [10:22] <Lachy> Or maybe you could do it as a venn-diagram or something
  220. # [10:22] <Hixie> venn diagram would be a bitch to maintain
  221. # [10:22] <Hixie> as i'm sure we'll be seeing more splits in the near future
  222. # [10:22] <Lachy> NOOOOOOO!!!!
  223. # [10:23] <Lachy> Seriously, no more spec splits. Please.
  224. # [10:23] <Lachy> splitting specs makes it difficult to figure out where to look to find something specific.
  225. # [10:24] <Hixie> i'm not planning any in particular, it just seems likely to happen given that we've had one issue resolved and it's resulted in a split
  226. # [10:24] <Lachy> e.g. Today, when looking through the proposed core and vocab splits, it took me a while to figure out where the Parsing section would be, since I intuitively thought it would be in Core
  227. # [10:25] <Lachy> I thought Vocab would be basically section 4, plus other elements and attributes scattered throughout a few other sections
  228. # [10:26] <Lachy> anyway, what's your reason for not wanting to encourage the Web Apps 1.0 spec?
  229. # [10:27] <Hixie> dunno, hadn't really thought about it
  230. # [10:27] <Hixie> i figured it was just something i liked and maybe 2 or 3 other people and everyone else hated it
  231. # [10:27] <Hixie> certainly it's unpopular in w3c circles
  232. # [10:29] <Lachy> within W3C circles, just about everything in HTML5 is unpopular with some groups of people.
  233. # [10:30] <Hixie> man i hate wiki syntax
  234. # [10:30] <Lachy> initially I hated the complete version, cause the annotation script really killed my browser. But since blocking that script, it works just fine and I use it all the time
  235. # [10:30] <Lachy> I think it might possible to use regular HTML syntax for tables in mediawiki
  236. # [10:30] <Lachy> so feel free to change it if you like
  237. # [10:33] <Hixie> it's more that it is presentational
  238. # [10:34] <Hixie> (the markup, not the table)
  239. # [10:34] * Joins: gavin__ (n=gavin@people.mozilla.com)
  240. # [10:34] * Joins: ROBOd (n=robod@89.122.216.38)
  241. # [10:37] <Lachy> my problem with wiki markup is that it uses an odd mix of HTML and custom non-intuitive syntax
  242. # [10:39] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 104 (Connection reset by peer))
  243. # [10:39] <Dashiva> It is
  244. # [10:40] <Dashiva> But it would be even worse if every single part of HTML was reinvented in wiki markup, IMO
  245. # [10:40] <Hixie> i just don't understand the need for a new language in the first place
  246. # [10:42] <Lachy> probably because people find editing HTML to be quite verbose, and the limited editing facilities provided by a textarea in a web page aren't really ideal
  247. # [10:43] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
  248. # [10:44] <Hixie> Lachy: what do you think of http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F now?
  249. # [10:44] <Hixie> i tried to make it tidier
  250. # [10:46] * Joins: Maurice` (i=copyman@5ED548D4.cable.ziggo.nl)
  251. # [10:46] <Dashiva> If you explained Web Applications 1.0 outside the table, you could instead make the WA column "Location in WA 1.0", and the WHATWG specs column would be less wide and bulky
  252. # [10:49] * gavin__ is now known as gavin
  253. # [10:51] * Quits: GarethAdams|Work (n=GarethAd@pdpc/supporter/active/GarethAdams)
  254. # [10:52] <Hixie> i made the column narrower
  255. # [10:52] <Hixie> not sure how to really explain the wa1 spec without scaring people :-)
  256. # [10:53] * Quits: Maurice` (i=copyman@5ED548D4.cable.ziggo.nl)
  257. # [10:54] <Dashiva> By the way, mediawiki tables look much nicer with border=1 cellpadding=3 cellspacing=0 (at least I think so) :)
  258. # [10:54] <Hixie> have mediawiki devs not heard of css? :-)
  259. # [10:54] <hsivonen> what's the diff between current-work/ and complete.html?
  260. # [10:54] * hsivonen always read current-work/
  261. # [10:55] <Dashiva> You can use CSS too
  262. # [10:55] <Hixie> complete.html includes all the webapps specs
  263. # [10:55] <Hixie> Dashiva: i mean, why don't they jsut have some classes that make these tables actually pretty
  264. # [10:55] * Joins: Maurice` (i=copyman@5ED548D4.cable.ziggo.nl)
  265. # [10:55] <hsivonen> ok
  266. # [10:56] <Dashiva> AryehGregor might know
  267. # [10:57] <hsivonen> maybe mediawiki is supposed to support old IE
  268. # [10:58] <Dashiva> "All active work at WHATWG is gathered in the Web Applications 1.0 document, available in <links>. For the HTML-specific work only, see WHATWG HTML at <links>. Individual specifications are also available, see the following table."
  269. # [10:59] <Hixie> feel free to edit the table, i closed the tab :-)
  270. # [11:02] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  271. # [11:02] <hsivonen> I think the WHATWG needs a page with links to all the specs that are part of the canonical platform
  272. # [11:02] <hsivonen> including a table-based visualization on overlapped specs
  273. # [11:03] <hsivonen> whether the overlap is WHATWG vs. W3C or IETF
  274. # [11:03] <hsivonen> or CSS 2.1 vs. CSS3
  275. # [11:10] * Quits: Lachy (n=Lachlan@85.196.122.246) (Read error: 113 (No route to host))
  276. # [11:15] <Hixie> write one and put it on the blog :-)
  277. # [11:16] <hsivonen> Hixie: I'd get accused of Webmandering again
  278. # [11:17] <Hixie> people accuse people of that?
  279. # [11:17] <hsivonen> http://schepers.cc/?p=117
  280. # [11:24] <hsivonen> oh. jd has showed up in the blog comments
  281. # [11:32] <hsivonen> I intend the post a descriptive view of the platform some time based on the collectively edited W3C spec browser impl score card
  282. # [11:33] * Quits: Heimidal (n=heimidal@unaffiliated/heimidal) (Remote closed the connection)
  283. # [11:35] * Joins: danbri (n=danbri@unaffiliated/danbri)
  284. # [11:37] <Dashiva> Amusing the 'multi-page' link for Microdata links to the single page microdata.html, whereas 'single-page' links to all of WHATWG HTML :)
  285. # [11:44] <Dashiva> http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F
  286. # [11:44] <hsivonen> it's very confusing to have this many spec vieews
  287. # [11:45] <hsivonen> it would be clearer to have tiny bits and complete
  288. # [11:45] * Joins: zcorpan__ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  289. # [11:45] <Hixie> heh, i hadn't seen http://hsivonen.iki.fi/web-stack/ before
  290. # [11:45] <hsivonen> but the intermediate collections seem confusing
  291. # [11:45] <Hixie> here's mine: http://www.whatwg.org/specs/web-apps/current-work/images/abstract.png
  292. # [11:45] <Dashiva> There's only one, isn't there?
  293. # [11:46] <hsivonen> Dashiva: I've lost track how many intermediate collections there are
  294. # [11:46] <Dashiva> WHATWG HTML is "the" spec, WA 1.0 is more like a rendered view of complete
  295. # [11:46] <Hixie> Dashiva: i think i preferred it with the WHATWG HTML line in the table
  296. # [11:47] <Hixie> when you look at the answer you just naturally assume the table is complete
  297. # [11:47] <hsivonen> Hixie: the material of the sink makes it look like a bathroom sink rather than a kitchen sink
  298. # [11:47] <Hixie> whereas now it's omitting the two main links
  299. # [11:47] <Hixie> hsivonen: yeah, well, it was the best i could find on short notice :-P
  300. # [11:48] <Dashiva> Hixie: I was thinking like hsivonen, that it would be better to have a clear separation between individual specs and compilations
  301. # [11:48] <Dashiva> But by all means, it's a wiki :)
  302. # [11:52] <Hixie> the idea of that section is really to answer the question "what should i be reading"
  303. # [11:53] <Hixie> Dashiva: i like the split into two questions though
  304. # [11:53] * Quits: zcorpan__ (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
  305. # [11:53] <Hixie> anyway i really should go to bed
  306. # [11:57] * Joins: zcorpan__ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  307. # [11:57] * Joins: JonathanNeal (n=Jonathan@76-219-69-134.lightspeed.breaca.sbcglobal.net)
  308. # [12:01] * Joins: Phae (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com)
  309. # [12:02] * Joins: Lachy (n=Lachlan@85.196.122.246)
  310. # [12:02] <Hixie> hsivonen: btw original picture was http://www.flickr.com/photos/wonderlane/2986252088/
  311. # [12:04] <Lachy> ah, I finally got my internet connection back. That was annoying. ISP troubles, I guess.
  312. # [12:05] <Lachy> Hixie, the spec table in the FAQ looks good now.
  313. # [12:05] <Hixie> the most recent changes were mostly Dashiva's work :-)
  314. # [12:05] <Hixie> i might add the WHATWG HTML line back in tomorrow, we'll se
  315. # [12:05] <Hixie> e
  316. # [12:05] * Quits: zcorpan__ (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
  317. # [12:11] <Lachy> Dashiva, why did you decide to take out the _in Single-page_ links here? http://wiki.whatwg.org/index.php?title=FAQ&diff=next&oldid=4340 They seemed useful
  318. # [12:12] * Quits: danbri (n=danbri@unaffiliated/danbri) (Remote closed the connection)
  319. # [12:13] <hsivonen> http://twitter.com/adactio/status/7527318716
  320. # [12:13] <Dashiva> Lachy: I figured that if someone wants to see a specific specification, they wouldn't want to load all the other stuff in WHATWG HTML
  321. # [12:14] * Joins: maikmerten (n=maikmert@port-92-201-39-142.dynamic.qsc.de)
  322. # [12:14] <Dashiva> (Also, I couldn't find a good way to include them both without either too much text or vague link names)
  323. # [12:17] <Lachy> ok
  324. # [12:20] <Hixie> i like how in http://lists.w3.org/Archives/Public/public-html/2010Jan/0192.html shelley refers to a message about "postmessage and localstorage" that i supposedly sent, and goes on to criticise me for mentioning localstorage... when the message in question, which she quotes in the very same e-mail, doesn't mention localstorage
  325. # [12:20] <Hixie> (i only references onhashchange and postmessage, both in html5)
  326. # [12:20] <Hixie> referenced, even
  327. # [12:23] <Lachy> haha
  328. # [12:23] * Joins: alfa (n=phobos@91.85.166.210)
  329. # [12:28] <Lachy> Hixie, shouldn't this bug now be resolved WONTFIX and Rejected, or at least reopened as it's no longer resolved as stated? http://www.w3.org/Bugs/Public/show_bug.cgi?id=8118
  330. # [12:30] <Hixie> reopened it
  331. # [12:31] * Joins: smaug_ (n=chatzill@cs181150024.pp.htv.fi)
  332. # [12:31] * Joins: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi)
  333. # [12:32] <Hixie> nn
  334. # [12:32] * Joins: danbri (n=danbri@unaffiliated/danbri)
  335. # [12:32] <Lachy> so Julian thinks discussion changes in the WG's bug tracker is not an appropriate place to discuss spec changes? http://lists.w3.org/Archives/Public/public-html/2010Jan/0340.html
  336. # [12:33] <alfa> Does all the ridiculousness in the W3C HTML WG have the potential to delay browser implementations of new features?
  337. # [12:38] * Joins: foolip (n=philip@h-63-95.A163.priv.bahnhof.se)
  338. # [12:41] * Quits: ivan` (n=ivan@unaffiliated/ivan/x-000001) ("Coyote finally caught me")
  339. # [12:41] * Joins: ivan` (n=ivan@unaffiliated/ivan/x-000001)
  340. # [12:42] * Joins: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
  341. # [12:42] <Dashiva> alfa: To a certain degree, by consuming time and effort that could go to developing a better spec
  342. # [12:43] <hsivonen> Dashiva: ...and writing code
  343. # [12:53] * Quits: maikmerten (n=maikmert@port-92-201-39-142.dynamic.qsc.de) (Remote closed the connection)
  344. # [12:54] <Philip`> Someone should make a concise summary of all the complaints people make, so when two people make conflicting complaints (e.g. the spec is too monolithic, the spec is too fragmented; discussion should be in bugs, discussion should be on the list; etc) we can point them at each other to resolve their differences themselves
  345. # [12:55] <Philip`> without dragging in any more people to the discussion than is necessary
  346. # [12:57] * Joins: maikmerten (n=maikmert@port-92-201-39-142.dynamic.qsc.de)
  347. # [13:04] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) ("ChatZilla 0.9.86 [Firefox 3.5.7/20100106054634]")
  348. # [13:05] * Quits: foolip (n=philip@h-63-95.A163.priv.bahnhof.se) ("leaving")
  349. # [13:08] * Joins: gratz|home (n=gratz@gratz.gotadsl.co.uk)
  350. # [13:15] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  351. # [13:24] <alfa> davisha: ok, i was concerned that the current situation might cause FUD to make implementors consciously "wait and see"
  352. # [13:31] <hsivonen> alfa: it could. too early to tell
  353. # [13:36] * Joins: karlcow (n=karl@nerval.la-grange.net)
  354. # [13:36] <Dashiva> For some reason, my nick seems to be up there with gauge on spellability
  355. # [13:37] <alfa> dashiva: my apologies :)
  356. # [13:39] * Quits: dimich_ (n=dimich@98.125.242.107)
  357. # [14:09] * Joins: foolip (n=philip@h-63-95.A163.priv.bahnhof.se)
  358. # [14:27] * Joins: atof (n=chatzill@124.107.253.61)
  359. # [14:31] * Parts: atof (n=chatzill@124.107.253.61)
  360. # [14:32] * Quits: Maurice` (i=copyman@5ED548D4.cable.ziggo.nl)
  361. # [15:12] * Quits: maikmerten (n=maikmert@port-92-201-39-142.dynamic.qsc.de) (Remote closed the connection)
  362. # [15:17] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  363. # [15:17] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  364. # [15:26] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  365. # [15:33] * Joins: workmad3 (n=workmad3@84.45.226.85)
  366. # [15:36] * Joins: Kuruman (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
  367. # [15:44] * Joins: Kuruman_ (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
  368. # [15:47] * Joins: Kuruman__ (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
  369. # [15:54] * Quits: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  370. # [15:58] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
  371. # [16:03] * Quits: Kuruman (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  372. # [16:07] * Quits: Kuruman_ (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  373. # [16:11] * Quits: alfa (n=phobos@91.85.166.210)
  374. # [16:24] * Joins: ttepasse (n=ttepas--@ip-95-222-120-117.unitymediagroup.de)
  375. # [16:25] * Quits: Phae (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com)
  376. # [16:25] * Joins: mikekelly (i=mikek@s3x0r.biz)
  377. # [16:25] <mikekelly> hi fans
  378. # [16:26] <mikekelly> what's the barrier to standardizing a javascript API for setting/flushing Authorization header (per domain) ?
  379. # [16:27] <mikekelly> obviously this is outside of HTML or HTTP - this is more just a general question aimed at browser people =)
  380. # [16:27] * Joins: archtech (i=stanv@83.228.56.37)
  381. # [16:27] <Philip`> Why should it be a JS API?
  382. # [16:27] <mikekelly> why is XHR js?
  383. # [16:27] <mikekelly> :/
  384. # [16:27] <Philip`> Because the purpose of XHR is to let JS make HTTP requests, so it has to be JS
  385. # [16:28] <mikekelly> well this is to let JS set the Authorization header..
  386. # [16:28] <Philip`> Authorization seems to be a purely HTTP thing
  387. # [16:28] <mikekelly> what?
  388. # [16:28] <Philip`> (currently)
  389. # [16:28] <mikekelly> what does that even mean
  390. # [16:28] <mikekelly> :/
  391. # [16:29] <mikekelly> so you can't understand what one might want to set Authorization header for a browser session?
  392. # [16:29] <mikekelly> with js
  393. # [16:29] <Philip`> I just mean there isn't currently a JS interface to any part of it, as far as I'm aware
  394. # [16:29] <mikekelly> right - I'm asking what the barrier is to that kind of API
  395. # [16:29] <mikekelly> where access is simply set/flush the header
  396. # [16:30] <mikekelly> and browser persists this per domain the same way it does for HTTP Basic right now..
  397. # [16:30] * Quits: workmad3 (n=workmad3@84.45.226.85) (Read error: 54 (Connection reset by peer))
  398. # [16:30] <mikekelly> but also exposes flush so we can actually implement logout..
  399. # [16:30] <Philip`> Probably the main problem is to convince people that a JS interface is better than any other ways of making authorization more useful (e.g. allowing custom HTML login forms, adding something to HTTP for logout pages, etc)
  400. # [16:30] <mikekelly> that's not how HTTP Authorization works
  401. # [16:31] <mikekelly> Logging In is a client-side state change
  402. # [16:31] <mikekelly> it's outside the scope of HTTP
  403. # [16:31] <mikekelly> whether the client is required to resubmit the Auth credentials for every request.. or they are persisted.. is down to the client
  404. # [16:31] <mikekelly> HTTP is completely agnostic to that
  405. # [16:32] * Philip` sees a site that does <div class="FloatLeft VerdanaText Bold Font-Size-12 Margin-Top-4 Margin-Left-5 AlignCenter" style="width: 190px; height: 15px;" >
  406. # [16:32] <mikekelly> if browser provided a JS API for set/flush the header per domain this functionality could be controlled via HTML+js
  407. # [16:32] <Philip`> Hooray for separation of presentation and content
  408. # [16:33] <mikekelly> ?
  409. # [16:33] <mikekelly> =/
  410. # [16:33] <Philip`> mikekelly: Maybe it'd be something that's useful - I guess you should write a proposal and see if anyone's interested
  411. # [16:34] <Philip`> (That was an aside, not part of this discussion)
  412. # [16:34] <mikekelly> my proposal would be so badly written we'd waste all our time arguing about how bad it was
  413. # [16:34] <mikekelly> I'm more interested in why, from this end's perspective - that would be a bad idea
  414. # [16:35] <mikekelly> i.e. what are the obstacles to getting a standardized API agreed upon and implemented
  415. # [16:35] <Philip`> The obstacles are that somebody needs to propose the API and implementors need to be interested in it
  416. # [16:35] <mikekelly> how formal does that proposal need to be?
  417. # [16:35] <Philip`> like in http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
  418. # [16:36] <mikekelly> isn't this outside of HTML?
  419. # [16:37] <Philip`> There aren't any formal requirements, it should just try to clearly describe the problem that you're trying to solve, and your suggested way of solving it, in a way that other people can understand and agree with
  420. # [16:37] <Philip`> The same process should probably apply to any proposals for web browser features
  421. # [16:37] <mikekelly> ok then consider the last 10 minutes of this discussion my proposal
  422. # [16:37] <mikekelly> -_-
  423. # [16:38] <Philip`> That won't work because nobody will read it
  424. # [16:39] <mikekelly> ok so who are the people worth tlaking to direct about this
  425. # [16:39] <mikekelly> they must be in here..
  426. # [16:40] <Philip`> Email works better for this kind of thing
  427. # [16:40] <mikekelly> which list?
  428. # [16:41] <mikekelly> I'd still like to chat on here anyway it's a lot easier than back/forthing emails
  429. # [16:42] * Philip` remembers some previous HTTP authentication discussion on the WHATWG list but doesn't remember what happened to it or if there's a better place now
  430. # [16:42] <mikekelly> Hixie: can you think of any reason to object to such a javascript API ?
  431. # [16:42] <mikekelly> yeah the problem with that one was
  432. # [16:42] <mikekelly> they were tyring to standardise some HTML way of doing that
  433. # [16:42] <mikekelly> which I think is pointless
  434. # [16:42] <mikekelly> just need a standard JS API
  435. # [16:42] <mikekelly> and let apps handle it as code on demand
  436. # [16:43] <mikekelly> you need.. Auth.set, Auth.flush, and Auth.isSet
  437. # [16:43] <mikekelly> that's about it
  438. # [16:44] <mikekelly> in some ways it would be good to have this method of controlling all headers
  439. # [16:44] <mikekelly> :)
  440. # [16:45] <mikekelly> but Auth's a specific case where you probably don't want to provide accessor
  441. # [16:45] <mikekelly> for obvious reasons :)
  442. # [16:46] <mikekelly> Philip`: if I posted this to WHATWG and went on to say I thought this was separate from HTML
  443. # [16:47] <mikekelly> I'm going to get told it's not up for discussion
  444. # [16:48] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  445. # [16:48] * Quits: nattokirai (n=nattokir@y224241.dynamic.ppp.asahi-net.or.jp)
  446. # [16:50] <mikekelly> so.. can I post that kind of thing to WHATWG list? Is there somewhere else? Is it like this on purpose so you guys don't have to bother yourselves with the real world?! ;)
  447. # [16:51] <Philip`> I don't think the WHATWG is being unreasonable by not being the place to solve all the world's problems at once
  448. # [16:52] <mikekelly> thank god we're getting video tags sorted
  449. # [16:52] <Dashiva> What's wrong with posting it to a w3c list?
  450. # [16:52] <mikekelly> what's wrong with just discussing it on here first so you can explain why I'm so clearly wrong and we can all avoid wasting any more time?
  451. # [16:53] <Philip`> Because people here either don't know much about the topic and/or don't care about it and/or don't want to talk you and/or are away
  452. # [16:53] <mikekelly> clearly they do care about it there was enough ping/pong last time it came up
  453. # [16:54] <mikekelly> or do we need some time to think up some super-clever reasons why this "just isn't going to happen"
  454. # [16:55] <Dashiva> Whatwg exists to pick up the balls w3c drops. It's best to check if w3c is actually going to drop it first. :)
  455. # [16:55] <mikekelly> well.. the line I was given before was
  456. # [16:55] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  457. # [16:55] <mikekelly> it matters not a feck what the standards say if we don't give a toss about it
  458. # [16:56] <mikekelly> so.. to avoid *wasting my time* I'll just skip the beuracracy and ask you direct
  459. # [16:56] <mikekelly> 1. Why won't it work and/or 2. Why don't you care
  460. # [17:00] <mikekelly> "it doesn't matter" doesn't make much sense given the previous discussions around the same issue
  461. # [17:00] <mikekelly> so.. why won't it work ?
  462. # [17:06] * webben suspects more relevant questions might be 1. Why should people care (what problem are you trying to solve)? 2. How might it work (what different solutions are there)?
  463. # [17:08] <Dashiva> And how it interacts with the other open suggestions relating to auth headers
  464. # [17:09] * Joins: dglazkov_ (n=dglazkov@216.239.45.130)
  465. # [17:13] <mikekelly> webben: 1. A sensible way to use the Authorization header beyond HTTP Basic and the hideous login prompt
  466. # [17:13] <mikekelly> 2. A standard JS API for setting/flushing the header
  467. # [17:14] <mikekelly> as long as there's an API.. it can be used
  468. # [17:14] <mikekelly> just like XHR
  469. # [17:16] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  470. # [17:16] * dglazkov_ is now known as dglazkov
  471. # [17:18] <webben> mikekelly: That doesn't explain the problem you're trying to solve in end-user terms.
  472. # [17:21] <mikekelly> what?
  473. # [17:21] <mikekelly> if you literally mean end users using applications
  474. # [17:22] <mikekelly> then the difference between logging in through a form which POSTs to some endpoints and initiates a cookie'd session vs. a javascript rigged form that sets the Authorization header..
  475. # [17:22] <mikekelly> is nothing.
  476. # [17:22] <mikekelly> but the difference in terms of the underlying system is vast
  477. # [17:23] <mikekelly> since one is session based (using cookies) and the other is stateless (how HTTP is intended)
  478. # [17:24] <mikekelly> I shouldn't have to give you a lesson in why or how those are hugely different
  479. # [17:25] <mikekelly> but - yes - the 'user experience' is 'already solved'
  480. # [17:26] <mikekelly> webben: so.. where do we go from here?
  481. # [17:26] <webben> mikekelly: I think that makes for a harder sell, since there are a lot of features that need specifying/implementing that make a big difference to the user experience.
  482. # [17:26] <mikekelly> are you from the browser club?
  483. # [17:27] <webben> No. I'm a web developer.
  484. # [17:27] <mikekelly> hmm
  485. # [17:27] <mikekelly> really? fair enough.
  486. # [17:28] <mikekelly> the sell is supporting web architecture and recognizing an obvious problem and a simple solution..
  487. # [17:28] <mikekelly> :)
  488. # [17:29] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  489. # [17:29] * Joins: Lachy (n=Lachlan@85.196.122.246)
  490. # [17:29] <mikekelly> one could easily argue that video tags, SVG, etc. are all user experiences which are achievable via flash objects
  491. # [17:30] <webben> I think they offer a better user experience.
  492. # [17:30] <mikekelly> and why is that?
  493. # [17:30] <daedb> Because Flash is crap.
  494. # [17:31] <webben> Flash is crashy, has poor platform support, has poor accessibility support, has poor restylability support, and introduces additional security risks.
  495. # [17:31] <mikekelly> poor platform support?
  496. # [17:31] <webben> Yes.
  497. # [17:31] <mikekelly> I'm sure HTML5 will have humougous support
  498. # [17:31] <mikekelly> and no browser compat problems at all
  499. # [17:32] <mikekelly> I'm not being serious btw I'm just giving you an example of how pointless that 'user experience' line of argument is
  500. # [17:32] <mikekelly> it's not a realistic way of looking at 'users'
  501. # [17:32] <webben> HTML5 (as a description of the intersection of implementations) already has wider platform support.
  502. # [17:32] <Dashiva> Flash is closed, so it can by definition not be part of the open web platform...
  503. # [17:32] <mikekelly> open web is not user experience
  504. # [17:32] <mikekelly> nobody cares.
  505. # [17:32] <mikekelly> don't kid yourself
  506. # [17:32] <daedb> Flash is Adobe's way of trying to skullfuck the web.
  507. # [17:33] <webben> Flash's development is controlled by Adobe; it's a bit vague to say it's "closed".
  508. # [17:33] <mikekelly> so are websockets
  509. # [17:33] <mikekelly> but there you go
  510. # [17:33] <webben> (the specs are open to implementors now)
  511. # [17:33] <mikekelly> "hey I suck at HTTP - I know! WebSockets!"
  512. # [17:33] <mikekelly> you really should not have used 'web' in websockets
  513. # [17:34] <mikekelly> that really is a bit of a stretch.
  514. # [17:34] <webben> I don't think your example of pointlessness is a valid one.
  515. # [17:34] <mikekelly> sure it is
  516. # [17:34] <mikekelly> flash works fine in all major browsers
  517. # [17:34] <mikekelly> nobody has a problem with it
  518. # [17:34] <mikekelly> apart from people on Mac but then..
  519. # [17:34] <daedb> Although it's too bad that I don't know Flash... then I could apply for a job that sends me to Florida for 3 months :p
  520. # [17:35] <webben> mikekelly: The first claim is true, but does not contradict my claims. The second claim is untrue. Lots of people have lots of problems with Flash.
  521. # [17:35] <mikekelly> meh - it works
  522. # [17:35] <webben> (Given the web's usage, a small proportion of users is still a lot of people.)
  523. # [17:35] * Joins: omz (n=omz@host109.190-230-20.telecom.net.ar)
  524. # [17:36] <mikekelly> ok well I wasn't being completely serious just proving a point re: 'user experience'
  525. # [17:36] <webben> You didn't persuade me, I'm afraid.
  526. # [17:37] <mikekelly> mmhmm
  527. # [17:37] <webben> mikekelly: Have you considered trying to implement your idea in one of the various open source libraries?
  528. # [17:38] <mikekelly> I've considered how easy the implementation would/should be
  529. # [17:39] <webben> That's not really the same thing.
  530. # [17:39] <webben> http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element
  531. # [17:39] <mikekelly> Fascinating.
  532. # [17:40] <mikekelly> ok so the point I've got to here is
  533. # [17:41] <mikekelly> "that would probably work but unfortunately the 'user experience' would not change and therefore it has no value"
  534. # [17:41] <webben> I don't understand how you conclude that from our discussion.
  535. # [17:41] <mikekelly> I'm not coding a PoC for something that simple
  536. # [17:41] <mikekelly> complete waste of time
  537. # [17:42] <webben> I didn't offer any ideas on whether it would work; I said that if it wouldn't have an end-user impact it would be a harder sell.
  538. # [17:42] <mikekelly> the end user impact is that they will be using stateless HTTP Authorization
  539. # [17:42] <webben> that's a technical detail, not an end-user impact
  540. # [17:42] <mikekelly> so is the openness of flash.
  541. # [17:43] <webben> I didn't raise the "openness of flash".
  542. # [17:43] <mikekelly> and object vs. video tags
  543. # [17:43] <mikekelly> and anything else in HTML
  544. # [17:43] <webben> Lots of things in HTML have end-user impact.
  545. # [17:43] <mikekelly> lots of things being added to html5?
  546. # [17:44] <Dashiva> Video, whether you agree with it or not, was a fairly easy sell
  547. # [17:44] <webben> I've already explained some of the reasons I think 'video' has end-user impact.
  548. # [17:45] <mikekelly> ok well you're failing to accept tthat developers and service/content providers are also users of html..
  549. # [17:45] <mikekelly> they care about stateless Auth
  550. # [17:45] <mikekelly> well.. the smart ones who know what they're talking about do
  551. # [17:45] <webben> mikekelly: No I'm differentiating between typical users and developers; and saying that features that affect the former are an easier sell.
  552. # [17:46] <mikekelly> why? so the browser vendors get more chicks?
  553. # [17:46] <mikekelly> can you please explain why that is the case..?!
  554. # [17:46] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  555. # [17:46] <webben> Because features that affect the primary user are more likely to increase software's share of the market.
  556. # [17:47] <mikekelly> 'primary user'?
  557. # [17:47] <Dashiva> "Users are more important than authors"
  558. # [17:47] <mikekelly> yes I'm asking you WHY you make that distinction
  559. # [17:47] <mikekelly> and how you justify that
  560. # [17:47] <webben> It seems self-evident to me.
  561. # [17:47] <mikekelly> oh ok then
  562. # [17:47] <othermaciej> hi all
  563. # [17:47] <mikekelly> I thought the web arch guys were supposed to be religious.. :)
  564. # [17:48] <Dashiva> The web exists for the users
  565. # [17:48] <mikekelly> bullshit
  566. # [17:48] <webben> Am I supposed to be a "web arch guy"?
  567. # [17:48] <mikekelly> it's client/server
  568. # [17:48] <mikekelly> webben: clearly not.
  569. # [17:48] <Dashiva> webben: No, mikekelly is
  570. # [17:48] <webben> Oh I see.
  571. # [17:49] <mikekelly> 16:46 < Dashiva> The web exists for the users < please explain this sentiment
  572. # [17:49] <mikekelly> the web is client/server
  573. # [17:49] <webben> mikekelly: Do you disagree that most users of popular browsers are not coders who would use your feature directly?
  574. # [17:50] <mikekelly> they aren't coders but they would use my feature directly
  575. # [17:50] <mikekelly> not conciously but they would use it..
  576. # [17:50] <webben> mikekelly: And that developer choice of what APIs to use are primarily determined by popular browser choices?
  577. # [17:50] <mikekelly> well that's given..
  578. # [17:50] <mikekelly> the sky is blue btw
  579. # [17:51] <mikekelly> where are you going with this..?
  580. # [17:52] <mikekelly> when people get HTML.. and run javascript + ajax.. they are using XHR
  581. # [17:52] <webben> So do you disagree that popular browsers stand to gain more marketshare by improving the user experience of those typical users than by putting the same energy into providing APIs not implemented by other browsers, that developers will adopt on the basis of market share?
  582. # [17:53] <mikekelly> obsolutely not because it's an utterly imperfect market
  583. # [17:53] <mikekelly> which you know very well
  584. # [17:53] <mikekelly> or at least you should
  585. # [17:53] <webben> I suspect most markets are imperfect one way or another.
  586. # [17:53] <mikekelly> so you all just sit on your arses trying to dream up 'sexy' fluff
  587. # [17:54] <mikekelly> while we have to do real work and deal with the bullshit you wont address
  588. # [17:54] <webben> mikekelly: Do you contend that neither action has an effect on marketshare, then?
  589. # [17:54] <Dashiva> It doesn't seem like your proposal adds much except being sexy for fans of HTTP...
  590. # [17:54] <mikekelly> Dashiva: yeah.. fans of HTTP happen to be a MASSIVE economic force
  591. # [17:55] <webben> mikekelly: What action do you think popular browsers can take to increase their marketshare?
  592. # [17:55] <mikekelly> a huge consumer of resources..
  593. # [17:55] <Dashiva> No, they happen to be a very small group of people
  594. # [17:55] <mikekelly> erm..
  595. # [17:55] <mikekelly> no,
  596. # [17:55] <Dashiva> _Users_ of HTTP are a different story
  597. # [17:55] <mikekelly> what?!
  598. # [17:55] <mikekelly> are you fking insane?
  599. # [17:56] <Dashiva> What percentage of people do you think even know what HTTP is?
  600. # [17:56] <mikekelly> 'fans' of HTTP happen to be anyone *DOING BUSINESS ON THE WEB*
  601. # [17:56] <Dashiva> Hardly
  602. # [17:56] <mikekelly> erm
  603. # [17:56] <mikekelly> ah man
  604. # [17:56] <webben> mikekelly: I like cats. That doesn't make me a fan of the precise evolution of cats' digestive systems.
  605. # [17:56] <Dashiva> HTTP is a tool. If it does the job, that's all they care about.
  606. # [17:56] <mikekelly> no
  607. # [17:57] <mikekelly> HTTP and tooling around that has direct effect on their capital expense
  608. # [17:57] <webben> mikekelly: The user experience does not make users a fan of the mechanics of how that experience is delivered.
  609. # [17:57] <webben> (not automatically, anyhow)
  610. # [17:57] <mikekelly> scalable, evolveable systems SAVE on capital expense
  611. # [17:57] <mikekelly> so this isn't just 'fanbois'
  612. # [17:57] <mikekelly> this is business people
  613. # [17:57] <Dashiva> It's a _tool_
  614. # [17:57] <mikekelly> fucking hell
  615. # [17:57] <mikekelly> it's a PROTOCOL
  616. # [17:58] <Dashiva> SPDY is a good hint. If the tool doesn't fit well, you look for a better one.
  617. # [17:58] <webben> Punctuating your discussion with expletives and uppercase does not make your arguments more effective.
  618. # [17:59] <mikekelly> ok so - stateless auth means that the system is more efficient
  619. # [17:59] <mikekelly> so it's faster
  620. # [17:59] <mikekelly> so users experience a faster website
  621. # [17:59] <mikekelly> there you go.
  622. # [18:00] <Dashiva> You replace one header with another
  623. # [18:00] <mikekelly> is that a joke?
  624. # [18:00] <Dashiva> Sessions are already possible both with and without http auth
  625. # [18:00] <webben> right so finally we're back to talking about the end-user experience.
  626. # [18:01] <mikekelly> sessions shouldn't have to exist full stop
  627. # [18:01] <webben> mikekelly: So the goal is to increase the speed of the user experience?
  628. # [18:01] <mikekelly> using HTTP Auth eliminates the need for sessions
  629. # [18:01] <mikekelly> that is my point
  630. # [18:01] <mikekelly> avoiding sessions results in far more scalable systems
  631. # [18:01] <mikekelly> that are more efficient
  632. # [18:02] <mikekelly> so they run faster and consume less resources
  633. # [18:02] <mikekelly> which is good for everyone.
  634. # [18:02] <webben> mikekelly: Which would increase the speed of user experience more? This or SPDY?
  635. # [18:02] <mikekelly> that has nothing to do with what I'm talking about.. SPDY is mostly optmization on top of HTTP
  636. # [18:03] <webben> mikekelly: Heck, this or developers compressing their JS/using CDNs.
  637. # [18:03] <webben> mikekelly: It has everything to do with the end goal of increasing the speed of the user experience.
  638. # [18:03] <mikekelly> CDNs and Js compression have nothing to do with one another
  639. # [18:03] <webben> mikekelly: They share the goal of increasing the speed of the user experience.
  640. # [18:03] <mikekelly> terrific thanks for that
  641. # [18:03] <webben> (Well, that's one benefit.)
  642. # [18:04] <mikekelly> webben: statless HTTP requests have the goal of increasing the efficiency of systems and improving user experience
  643. # [18:05] <webben> mikekelly: So when asking: is this worth doing, you need to consider whether there are other solutions that do more, not just whether your solution would have any effect at all.
  644. # [18:05] <mikekelly> right.. :/
  645. # [18:05] * Joins: erlehmann (n=erlehman@82.113.106.6)
  646. # [18:06] <webben> mikekelly: In particular, it's worth noting that JS compression for example works with all popular user agents so it's more attractive to typical developers than a feature where you'd need to code an alternative for popular browsers that don't support it.
  647. # [18:07] <mikekelly> thanks for the heads up
  648. # [18:08] <webben> Sarcasm doesn't make your arguments more effective either.
  649. # [18:08] <mikekelly> That is why this conversation revolves around a standard API for setting/flushing the Auth header..
  650. # [18:09] <mikekelly> note: standardized
  651. # [18:09] <mikekelly> i.e. 'popular browsers support it'
  652. # [18:09] <mikekelly> like XHR..
  653. # [18:09] <mikekelly> so.. anyway..
  654. # [18:09] <mikekelly> Dashiva: using HTTP Auth eliminates the need for sessions - avoiding sessions results in far more scalable systems that are more efficient - so they run faster and consume less resources
  655. # [18:09] <webben> mikekelly: In some distant future. In the meantime, browsers can implement features that deliver (arguably) more significant user benefits right now.
  656. # [18:10] <webben> Implementing features that benefit users right now is likely to be more attractive.
  657. # [18:10] <mikekelly> and that statement discludes my suggestion because of some bullshit arbitrary definition of 'user'
  658. # [18:10] <mikekelly> and 'benefit'
  659. # [18:10] <webben> It does not seem arbitrary to me.
  660. # [18:10] <mikekelly> well it is - which is why you can't quantify them
  661. # [18:12] <webben> I don't understand how my ability to quantify them would say anything about the arbitrariness of the definition.
  662. # [18:13] <Dashiva> (A system large enough to need good scalability likely has requirements on user experience that dictate hardware investment. More efficient systems would just mean less hardware used, not better user experience.)
  663. # [18:13] * Quits: archtech (i=stanv@83.228.56.37) (Client Quit)
  664. # [18:14] <mikekelly> Dashiva: yes - I guess if they get more users they should just go down the money tree for a few hours
  665. # [18:14] * Quits: vvv (n=vvv@mediawiki/VasilievVV) ("KVIrc Insomnia 4.0.0, revision: 3410, sources date: 20090703, built on: 2009/08/12 22:29:13 UTC http://www.kvirc.net/")
  666. # [18:14] <mikekelly> lets be a bit more realistic an assume there isn't a bottomless pit of money..
  667. # [18:14] <othermaciej> I think most sites do not use HTTP Auth because they want to control the login UI themselves
  668. # [18:15] <mikekelly> NO
  669. # [18:15] <mikekelly> really?
  670. # [18:15] <othermaciej> I don't think it has anything to do with scalability issues
  671. # [18:15] * Joins: dglazkov_ (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  672. # [18:15] <mikekelly> well clearly not - moving away from statelessness (HTTP Auth) is not in the interest of scalability
  673. # [18:15] <mikekelly> that is my point
  674. # [18:15] <othermaciej> mikekelly: whoah there turbo
  675. # [18:16] <othermaciej> let's try to hold back our all-caps sarcasm
  676. # [18:16] <othermaciej> HTTP Auth isn't stateless
  677. # [18:17] <othermaciej> well, depending on what you mean by stateless
  678. # [18:17] <mikekelly> you weren't here but the start of this convo was my proposal for a JS API that can set/flush the Auth header.. which would allow html+js UI to log in and out
  679. # [18:17] <mikekelly> othermaciej: no 'shared state'; i.e. no session
  680. # [18:17] <othermaciej> digest auth has both permanent state on the client (saved username / pw) and temporary state (the nonce)
  681. # [18:18] <mikekelly> and you can leverage that from html+js ?
  682. # [18:19] <othermaciej> A JS API to set a username/password pair to use for a specific protection space on a particular server might be useful
  683. # [18:19] <othermaciej> I don't think it would result in things being any less stateful
  684. # [18:19] <othermaciej> your responses still have to vary based on the Authorization header
  685. # [18:19] <othermaciej> (instead of based on Cookie)
  686. # [18:20] <othermaciej> in fact with digest auth Authorization is different every time, so it's harder to build a reverse proxy that caches effectively
  687. # [18:20] * Joins: seventh (i=seventh@189.59.132.85)
  688. # [18:20] <mikekelly> no, that's what layering is for
  689. # [18:20] <othermaciej> and basic auth sends the password in essentially plaintext every time, which is broken
  690. # [18:20] <mikekelly> whereas sessions are perfectly secure of course
  691. # [18:22] <mikekelly> Digest isn't different every time, regardless using tokens (whether they contain variable nonces etc) in the Auth header doesn't require shared state/token
  692. # [18:22] <Dashiva> There's already one or two proposals for combining form login with HTTP auth
  693. # [18:22] <mikekelly> Which is why I would say a simple API to set/flush
  694. # [18:23] <webben> Arguments of the form: "We can ignore problem X with Solution A, because Solution B is not totally immune to similar problems." aren't very strong.
  695. # [18:23] * Quits: dglazkov (n=dglazkov@216.239.45.130) (Read error: 60 (Operation timed out))
  696. # [18:23] * dglazkov_ is now known as dglazkov
  697. # [18:23] <mikekelly> othermaciej: a set/flush would provide a generic mechanism for any HTTP Auth mechanism
  698. # [18:24] <mikekelly> Digest,OAuth, WSSE, etc.
  699. # [18:24] <mikekelly> js picks up 401's - parses WWW-Authenticate header
  700. # [18:24] <mikekelly> does it's magic
  701. # [18:24] <mikekelly> sets the Authorization header
  702. # [18:25] <othermaciej> you really don't want to set the actual Auth header
  703. # [18:25] <mikekelly> why is that?
  704. # [18:25] <othermaciej> because the client is not in a position to compute the digest for every resource
  705. # [18:25] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
  706. # [18:25] <mikekelly> it wouldn't.. it would set it
  707. # [18:25] <mikekelly> and the API would persist it
  708. # [18:25] <mikekelly> the same way it does if you log in with Basic
  709. # [18:25] <othermaciej> when you load a page and its subresources over http digest auth, each resource needs a different Authorize header
  710. # [18:26] <mikekelly> no it doesn't..
  711. # [18:26] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  712. # [18:26] <othermaciej> "The Digest scheme challenges
  713. # [18:26] <othermaciej> using a nonce value. A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given
  714. # [18:26] <othermaciej> nonce value, the HTTP method, and the requested URI."
  715. # [18:26] <othermaciej> from the RFC
  716. # [18:27] <othermaciej> it's a challenge-response protocol
  717. # [18:27] <othermaciej> you can't set a valid response before seeing the chalenge
  718. # [18:27] <othermaciej> many other strong auth methods (NTLM, Kerberos) also work on a challenge/response basis
  719. # [18:28] <mikekelly> right - but the client credentials don't change..
  720. # [18:28] <othermaciej> the username and password don't change
  721. # [18:29] <othermaciej> so you could let JS tell those to the browser
  722. # [18:29] <mikekelly> with the auth echeme
  723. # [18:29] <othermaciej> but the *header* that you send
  724. # [18:29] <othermaciej> that does change
  725. # [18:29] <mikekelly> a decent point
  726. # [18:29] <mikekelly> thank you
  727. # [18:29] <mikekelly> :)
  728. # [18:30] <mikekelly> so an api per supported Auth scheme?
  729. # [18:31] <othermaciej> a single server can have multiple named protection spaces
  730. # [18:31] <mikekelly> where credentials are presisted and the header calculated
  731. # [18:31] <mikekelly> realms?
  732. # [18:31] <othermaciej> right, realms
  733. # [18:31] <mikekelly> yeah - that's ok right?
  734. # [18:31] <othermaciej> you'd need a username/password per {protocol,host,port,realm} tuple
  735. # [18:32] <mikekelly> realm is specified in the request
  736. # [18:32] * webben vaguely wonders whether HTTP Auth could be directly supported in HTML with something likely digestUsername="#idref" and a digestPassword="#idref" on any element taking an "action" attribute.
  737. # [18:32] <webben> *like
  738. # [18:32] <mikekelly> it's much easier for everyone if it's just a JS API
  739. # [18:33] * webben disagrees.
  740. # [18:33] <Dashiva> It's much easier if we provide a way to map a regular non-JS form to an auth response
  741. # [18:33] <othermaciej> not sure
  742. # [18:33] <othermaciej> doing it declaratively is handy
  743. # [18:33] <othermaciej> but the JS API could also be useful
  744. # [18:33] <mikekelly> it is - but it's way less risk as an API
  745. # [18:34] <webben> Sure, I didn't mean having an HTML feature would mean a JS feature would be bad.
  746. # [18:34] <mikekelly> at least then you can see how it behaves 'in the wild' and make the judgement
  747. # [18:34] <othermaciej> that being said, I don't see how http auth is any less stateful, and as I said before, it seems harder to cache via areverse proxy
  748. # [18:34] <webben> Not sure how it's less risk as an API.
  749. # [18:34] <mikekelly> Vary: Authorization
  750. # [18:34] <othermaciej> Vary: Authorization is no better than Vary: Cookie
  751. # [18:35] <mikekelly> it's not harder
  752. # [18:35] <othermaciej> in fact it's worse, because the Authorization header is different every single time with strong auth schemes
  753. # [18:35] <mikekelly> you generally can't cache a private resource anyway
  754. # [18:35] <othermaciej> whereas session cookies persist
  755. # [18:35] <mikekelly> depending on how you build your systems
  756. # [18:36] <othermaciej> on a system like facebook nearly every resource is private
  757. # [18:36] <othermaciej> also, both Authorization and Cookie are added promiscuously - the only way to exclude them from non-private resources is to put those on a separate subdomain
  758. # [18:37] <mikekelly> why is that a problem?
  759. # [18:38] <othermaciej> you can't put your main page on a separate subdomain
  760. # [18:38] <othermaciej> anyway
  761. # [18:38] <mikekelly> why would you want to?
  762. # [18:38] <mikekelly> the resposne determines cachability
  763. # [18:38] <othermaciej> I think a version of your proposal is reasonable, but I don't think your justification for it (less stateful / more scalable) seems sound to me
  764. # [18:38] <mikekelly> the fact that request contained cookie or auth header is irrelevant
  765. # [18:39] <mikekelly> othermaciej: it's simple; there's no shared state by session
  766. # [18:39] <mikekelly> which means the server side doesn't need to maintain any session
  767. # [18:39] <mikekelly> which makes horizontal scalability lot more simple
  768. # [18:40] <mikekelly> the only thing you're worring about there is the nonce
  769. # [18:40] <mikekelly> which is a lot less of a challenge than a pool of sessions, for obvious reasons
  770. # [18:41] <mikekelly> no?
  771. # [18:44] <webben> Although for the next five years or so, you'd still need a pool of sessions for users of browsers that don't support the API, if you wanted to give them the same login UI?
  772. # [18:44] * Joins: workmad3 (n=workmad3@84.45.226.85)
  773. # [18:44] <mikekelly> how many new features fall into that category?
  774. # [18:45] <othermaciej> I don't understand why storing the nonce is less of a burden than storing a session cookie
  775. # [18:45] <othermaciej> I suppose you could time it out more aggressively
  776. # [18:46] <webben> mikekelly: Many features require double provision; I think it's rare for that double-provision to prevent one realizing the benefits of single provision.
  777. # [18:46] <webben> that is to say, if you have to maintain nonces and sessions, has scalability gotten any simpler?
  778. # [18:47] <webben> Contrast SPDY. In theory, that runs from the same web servers on the same machines. If a client supports it, their user experience will be faster; if not, it won't.
  779. # [18:47] <mikekelly> ...
  780. # [18:47] <mikekelly> :/
  781. # [18:47] <webben> The need to cater to clients that don't support does not negate its advantages.
  782. # [18:47] <webben> *don't support it
  783. # [18:47] <webben> Do you see what I mean?
  784. # [18:49] <mikekelly> if it's an API it would be possible to write work-arounds for legacy clients
  785. # [18:49] <mikekelly> of course
  786. # [18:49] <webben> mikekelly: I'm talking about the server.
  787. # [18:49] <mikekelly> sure - the web is an evolutionary thing
  788. # [18:50] <mikekelly> it doesn't improve by magic..
  789. # [18:50] <mikekelly> you're asking me what my objective is
  790. # [18:51] <webben> That doesn't undermine the distinction - for individuals developers - between adopting a feature that can improve X now, versus one that could only improve X in five years time and in the meantime makes X more complicated.
  791. # [18:52] <mikekelly> ok well we have big players in the web
  792. # [18:52] <mikekelly> I'm sure if they thought they could cut costs they'd be interested
  793. # [18:52] <webben> SPDY can improve performance now, even if it makes delivering performance more complicated. Seems to me you're saying this API would improve scalability in five years or so, while making scalability more complicated in the meantime.
  794. # [18:52] <webben> Which could in fact increase costs, as far as I can see.
  795. # [18:53] <mikekelly> it's really not that complicated if you're systems are built properly :)
  796. # [18:53] <webben> mikekelly: I didn't make any judgement about *how* much more complicated it is.
  797. # [18:53] <webben> Simply that is is more complicated.
  798. # [18:53] <mikekelly> ok well then you can't just make that judgement it has to be in some context
  799. # [18:53] <webben> benefits vs costs
  800. # [18:54] <mikekelly> ok it could be 4 days of work complicated
  801. # [18:54] <webben> immediate benefit: 0; immediate cost: >0 (due to it being more complicated)
  802. # [18:54] <mikekelly> and 20 million saved in beenefit
  803. # [18:54] <webben> how is this 20 million saved if you still need to maintain the session pool?
  804. # [18:55] <mikekelly> 20 million as 15% of some massive scale
  805. # [18:55] <webben> How though?
  806. # [18:56] <mikekelly> with a really well designed, distributed system
  807. # [18:56] <webben> That doesn't really answer the question.
  808. # [18:56] <mikekelly> you want a web arch lesson?
  809. # [18:57] <webben> I'd like a concise explanation of how you'd increase scalability while maintaining a session pool.
  810. # [18:57] <mikekelly> Roy Fielding wrote his dissertation on a style of building systems that seems to work quite well. :)
  811. # [18:58] <mikekelly> I know I'm not realy allowed to say that
  812. # [18:58] <webben> How would you apply the ideas in that dissertation to solve this problem?
  813. # [18:59] <mikekelly> by leveraging the layered constraint as it applies to HTTP.
  814. # [18:59] <webben> Which means what?
  815. # [18:59] <mikekelly> have you read the paper?
  816. # [19:00] <webben> A while ago, yeah.
  817. # [19:00] <mikekelly> statelessness is a primary constraint of the style he outlines there
  818. # [19:01] <webben> Okay ... but your solution still has to involve "state" because it has to include a session pool.
  819. # [19:01] <mikekelly> mmmhmm..
  820. # [19:02] <mikekelly> if the components of whatever makes up your system are decoupled then it's a lot easier to "partition" in the way you seem to think is so impossible
  821. # [19:03] <webben> mikekelly: Are you saying you'd basically have one lot of servers handle requests using your API and another lot handle requests using sessions?
  822. # [19:03] <mikekelly> regardless - features like this can have application and value, the fact that we may have to wait until it is appropriate for mass distribution is irrelevant, and sitting around worrying about that isn't going to make it happen
  823. # [19:04] <webben> It may be irrelevant to you. It's not irrelevant to developers of clients or servers considering implementing the feature.
  824. # [19:05] <webben> Especially, when they could implement something else to realize cost-savings, like SPDY.
  825. # [19:06] <mikekelly> why do you keep referring to SPDY as an alternative to this?
  826. # [19:07] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  827. # [19:07] <webben> mikekelly: Because it also offers a faster user experience with (potentially) lower costs.
  828. # [19:08] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  829. # [19:08] <mikekelly> and that somehow eliminates the benefit here how?
  830. # [19:08] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net) (Client Quit)
  831. # [19:08] <webben> It doesn't elimate the putative benefit; it means the benefit/cost ratio of one action is higher than the other action.
  832. # [19:09] <webben> So rational actors are more likely to take the former action - because time/resource/money is limited.
  833. # [19:09] <webben> *eliminate
  834. # [19:09] * Joins: timz (n=mostrovo@dc51469cbe.adsl.wanadoo.nl)
  835. # [19:10] <mikekelly> .. right ..
  836. # [19:10] <mikekelly> :)
  837. # [19:11] <webben> So I'd suggest developing a client/server pair that implements your ideas along the lines of SPDY would be a good way to gain traction for them.
  838. # [19:13] <mikekelly> a client/server pair that implements some form of HTTP Authorization?
  839. # [19:13] <mikekelly> I don't think I need to bother.
  840. # [19:14] * Quits: erlehmann (n=erlehman@82.113.106.6) ("Ex-Chat")
  841. # [19:14] <mikekelly> http://docs.amazonwebservices.com/AmazonS3/2006-03-01/index.html?RESTAuthentication.html
  842. # [19:15] <webben> yeah, I meant a client implementing your JS API and a server system that supports session pools and nonces simultaneously.
  843. # [19:15] * Joins: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  844. # [19:16] <webben> not just any old implementation of HTTP Authorization.
  845. # [19:16] <mikekelly> to prove what? that the programming languages work ok?
  846. # [19:16] * Parts: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  847. # [19:17] <webben> mikekelly: Well, if nothing else, you'd then be able to submit patches to the systems you'd modified in order to have actual implementations.
  848. # [19:17] <webben> mikekelly: Though I suspect you might also refine the ideas through actual implementation.
  849. # [19:17] <mikekelly> that sounds like a terrific waste of time
  850. # [19:18] <webben> mikekelly: Is that because you'd have to learn a lot of new code to contribute the patch to an existing browser?
  851. # [19:20] * webben is confused as to why it's a terrific waste of time for you, but a great use of others' time.
  852. # [19:21] <mikekelly> .. this conversation is turning into a terrific waste of time
  853. # [19:22] * Quits: omz (n=omz@host109.190-230-20.telecom.net.ar) (Read error: 110 (Connection timed out))
  854. # [19:22] <mikekelly> it's a waste of time because 1. I'm not a browser dev and 2. what's the point if nobody agrees anyway
  855. # [19:23] <othermaciej> I'm a browser dev and we'd probably take a WebKit patch to implement something like this, if it also got discussion in the relevant standards
  856. # [19:24] * Joins: omz (n=omz@host161.201-252-128.telecom.net.ar)
  857. # [19:28] * Joins: vvv (n=vvv@mediawiki/VasilievVV)
  858. # [19:29] <mikekelly> othermaciej: that was really my initial query - where abouts would you 'take' something like this
  859. # [19:32] <mikekelly> because if it's "just" a JS API like XHR it doesn't really belong in HTML spec
  860. # [19:32] <mikekelly> right?
  861. # [19:36] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  862. # [19:38] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  863. # [19:39] * Quits: workmad3 (n=workmad3@84.45.226.85) (Remote closed the connection)
  864. # [19:40] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Client Quit)
  865. # [19:46] * Joins: cohitre (n=cohitre@c-98-237-252-207.hsd1.wa.comcast.net)
  866. # [19:47] <webben> mikekelly: http://www.w3.org/2008/webapps/ and WHATWG would seem appropriate forums.
  867. # [19:47] * Parts: cohitre (n=cohitre@c-98-237-252-207.hsd1.wa.comcast.net)
  868. # [20:02] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 104 (Connection reset by peer))
  869. # [20:13] * Joins: erlehmann (n=erlehman@82.113.121.2)
  870. # [20:13] * Quits: erlehmann (n=erlehman@82.113.121.2) (Read error: 104 (Connection reset by peer))
  871. # [20:13] * Joins: erlehmann (n=erlehman@82.113.121.2)
  872. # [20:20] <Philip`> "an already almost one million pixels height spec"
  873. # [20:21] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  874. # [20:21] <Philip`> That's the first time I've seen it measured in those units
  875. # [20:22] <daedb> Well we could always increase the line-height, then it'll be even taller!
  876. # [20:36] * Joins: Heimidal (n=heimidal@cpe-76-168-254-92.socal.res.rr.com)
  877. # [20:47] * Joins: dimich_ (n=dimich@98.125.224.126)
  878. # [20:50] * paul_irish_ is now known as paul_irish
  879. # [20:55] * Joins: omz_ (n=omz@host147.190-229-17.telecom.net.ar)
  880. # [20:55] * Quits: erlehmann (n=erlehman@82.113.121.2) ("Ex-Chat")
  881. # [20:56] * Joins: workmad3 (n=workmad3@84.45.226.85)
  882. # [20:57] * Quits: omz (n=omz@host161.201-252-128.telecom.net.ar) (Read error: 110 (Connection timed out))
  883. # [21:03] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 54 (Connection reset by peer))
  884. # [21:07] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  885. # [21:11] * Quits: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) (Remote closed the connection)
  886. # [21:17] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  887. # [21:33] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  888. # [22:02] * Quits: smaug_ (n=chatzill@cs181150024.pp.htv.fi) ("ChatZilla 0.9.86 [Firefox 3.7a1pre/20091230113157]")
  889. # [22:04] * Joins: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  890. # [22:05] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  891. # [22:08] * Parts: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  892. # [22:18] * Quits: gratz|home (n=gratz@gratz.gotadsl.co.uk) ("Leaving")
  893. # [22:23] * Quits: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote closed the connection)
  894. # [22:25] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  895. # [22:28] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  896. # [22:33] * Quits: workmad3 (n=workmad3@84.45.226.85) (Remote closed the connection)
  897. # [22:40] * Quits: omz_ (n=omz@host147.190-229-17.telecom.net.ar) ("Leaving")
  898. # [22:41] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  899. # [22:51] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 113 (No route to host))
  900. # [22:51] * Joins: workmad3 (n=workmad3@84.45.226.85)
  901. # [22:55] * Quits: JonathanNeal (n=Jonathan@76-219-69-134.lightspeed.breaca.sbcglobal.net) (Read error: 110 (Connection timed out))
  902. # [22:55] * Parts: timz (n=mostrovo@dc51469cbe.adsl.wanadoo.nl)
  903. # [22:59] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  904. # [23:15] * Joins: nattokirai (n=nattokir@y224241.dynamic.ppp.asahi-net.or.jp)
  905. # [23:28] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Remote closed the connection)
  906. # [23:28] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  907. # [23:40] * Quits: nattokirai (n=nattokir@y224241.dynamic.ppp.asahi-net.or.jp)
  908. # Session Close: Sun Jan 10 00:00:00 2010

The end :)