/irc-logs / freenode / #whatwg / 2009-09-27 / end

Options:

  1. # Session Start: Sun Sep 27 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:00] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  4. # [00:04] * Quits: tantek (n=tantek@67.180.200.14)
  5. # [00:05] * Joins: nessy (n=nessy@124-170-205-120.dyn.iinet.net.au)
  6. # [00:13] * Quits: dbaron (n=dbaron@c-98-234-51-190.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  7. # [00:26] * Quits: Steve^ (n=steve@92.40.107.139.sub.mbb.three.co.uk) ("Leaving")
  8. # [00:27] * Quits: Phae (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com)
  9. # [00:27] * Joins: heycam (n=cam@nat/mozilla/x-jwborwnrgqgqhdvl)
  10. # [00:29] * Quits: Lachy_ (n=Lachlan@85.196.122.246) ("Leaving")
  11. # [00:30] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  12. # [00:30] * Joins: Lachy (n=Lachlan@85.196.122.246)
  13. # [00:34] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  14. # [00:41] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  15. # [00:46] * Joins: tantek (n=tantek@70.36.139.108)
  16. # [00:47] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  17. # [00:48] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  18. # [00:50] * Quits: zdobersek (n=zan@cpe-92-37-69-226.dynamic.amis.net) ("Leaving.")
  19. # [00:51] * Quits: Midler (n=midler@212.37.124.243) ("Leaving.")
  20. # [00:55] * Quits: miketaylr (n=miketayl@user-0cdf5gs.cable.mindspring.com)
  21. # [01:00] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  22. # [01:02] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  23. # [01:02] * Quits: benward (n=benward@adsl-63-204-27-202.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  24. # [01:03] * Quits: ttepasse (n=ttepas--@p5B014B93.dip.t-dialin.net) ("?Q")
  25. # [01:03] * Quits: nessy (n=nessy@124-170-205-120.dyn.iinet.net.au) ("This computer has gone to sleep")
  26. # [01:03] * Joins: masinter (n=user@c-76-102-104-162.hsd1.ca.comcast.net)
  27. # [01:06] * Quits: Guest76618 (n=and@apo29.girton.cam.ac.uk)
  28. # [01:09] <masinter> i'm tracking down more stuff about mime sniffing
  29. # [01:10] * Joins: roc_ (n=roc@115.130.22.130)
  30. # [01:10] <Philip`> With all this sniffing, has anybody worked out what mimes smell like yet?
  31. # [01:10] <masinter> The Barth paper contains the claim "Once one browser vendor implements content sniffing, the other browser vendors are forced to follow suit or risk losing market share [1]", where [1] is not some study of market share of browser vendor behavior, but just some mozilla bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=175848
  32. # [01:11] <masinter> well, seems like a pretty smelly reference
  33. # [01:11] * Joins: and (n=and@128.232.240.217)
  34. # [01:13] <masinter> it's a pretty astounding claim, really, that browser market share depends on content type sniffing
  35. # [01:13] <masinter> rather than, say, performance, ease of use, conformant behavior when confronted with actually properly labelled content
  36. # [01:13] <jgraham> It's a pretty astounding claim that it doesn't
  37. # [01:13] <masinter> it doesn't what?
  38. # [01:14] <jgraham> Depend on content sniffing
  39. # [01:14] <masinter> i mean that it's a more significant factor than 100 other things
  40. # [01:14] <jgraham> It doesn't have to be
  41. # [01:14] <jgraham> It just has to be a sufficienty significant factor
  42. # [01:14] <jgraham> Which it is
  43. # [01:14] <tantek> it's the standard, if the browser doesn't show the web page (properly), or shows it in some broken way, the user tries a different browser, if the other browser appears to "work", the user sticks with it.
  44. # [01:15] <masinter> how significant a factor is it?
  45. # [01:15] <jgraham> Indeed, users couldn't care less about whether content is properly labelled or not
  46. # [01:15] <tantek> more significant than performance, pretty GUI, brand name, etc.
  47. # [01:15] <Philip`> I think its significance is about 0.18
  48. # [01:15] <jgraham> masinter: I don't know how to put in on a scale.
  49. # [01:16] <masinter> i mean, 1% of the population would switch from FirefOx to Chrome if Chrome sniffed and FireFox didn't, even if Firefox was faster and implemented more other features?
  50. # [01:16] <tantek> none of that matters if the browser "breaks" from the user's perception.
  51. # [01:16] <jgraham> It is significant enough that it has to be there
  52. # [01:16] <masinter> exactly this response has to be there?
  53. # [01:16] <Philip`> It is believed by browser vendors to be significant enough that it has to be there
  54. # [01:16] <masinter> i mean, this is a major "feature" and the justification is that someone read a bug report?
  55. # [01:17] <jgraham> Philip`: Those two statements are roughly equivalent
  56. # [01:17] <masinter> which product manager would back that up?
  57. # [01:17] <tantek> "oh this browser doesn't work with my bank, I'll try another browser, or ask my friends which browser they use and try that. oh look this other browsers seems to 'work' with my bank, and is fine with other sites too, I'll stick to it."
  58. # [01:17] <masinter> which banks have misconfigured web servers?
  59. # [01:17] <tantek> which banks don't?
  60. # [01:17] <jgraham> masinter: Working with the web is a major feature. In a web browser
  61. # [01:17] <masinter> sure, some user sites, c'mon tantek
  62. # [01:17] <tantek> misconfigured HTTP, HTML you name it
  63. # [01:17] <Philip`> The theoretically quantifiable figure is probably more like: If a million happy Firefox users try out Chrome, how many abandon Chrome because one of the websites they like to visit fails to work in Chrome (due to sniffing differences)
  64. # [01:17] <masinter> you're making circular definitions
  65. # [01:17] <tantek> know any bank sites that validate? good luck.
  66. # [01:18] <masinter> name one, Tantek, that has misconfigured mime types?
  67. # [01:18] <masinter> this isn't about validation, it's about content-type sniffing
  68. # [01:18] <tantek> nope - all the same
  69. # [01:18] <masinter> my left shoe isn't configured properly either
  70. # [01:18] <tantek> it's all about compat
  71. # [01:18] <masinter> tantek, what is all the same?
  72. # [01:18] <tantek> to the user it's all the same. my browser is broken.
  73. # [01:18] <masinter> hmmm, argument by assertion?
  74. # [01:18] <tantek> doesn't matter whether the pipe or pipe-fitting is broken
  75. # [01:19] <jgraham> masinter: Since banks typically require a login it is rather hard to verify whether they have configured their server correctly
  76. # [01:19] <tantek> and experience. i've built browsers.
  77. # [01:19] <masinter> i understand the nature of the argument, tantek, and repeating it doesn't help
  78. # [01:19] <tantek> and usertested browser useres.
  79. # [01:19] <tantek> users even
  80. # [01:19] <masinter> |<tantek> "oh this browser doesn't work with my bank, I'll try another browser,
  81. # [01:19] <tantek> this is one of those "duh" things to anyone who builds browsers.
  82. # [01:19] <jgraham> tantek: indeed
  83. # [01:19] <masinter> "duh" "duh"
  84. # [01:20] <masinter> well, it's a "duh" argument indeed that if you make claims about banks and user behavior and market share that you have to have more than saying "well, duh, we're right and you're wrong nyah nyah nyah"
  85. # [01:20] <Hixie> masinter: market research data that i've seen from two different browser vendors puts compatibility with sites as the number #1 reason for switching browsers
  86. # [01:20] <Hixie> literally above all else
  87. # [01:21] <Hixie> more important than security, than having extensions/add-ons, than having features, than speed, anything
  88. # [01:21] <masinter> well, why is the citation in http://www.adambarth.com/papers/2009/barth-caballero-song.pdf to a mozilla bug report?
  89. # [01:21] <jgraham> I would say that Hixie's data matches my experience
  90. # [01:21] <Hixie> what else would you cite? browser vendors aren't going to publish the data telling their competition why they are losing customers!
  91. # [01:22] <masinter> I mean, if there were any market research data, why cite the bug report?
  92. # [01:22] <Hixie> i don't think i've seen any of these numbers publicly
  93. # [01:22] <masinter> oh, well, you could cite "John Q. Product Manager, Personal Communication"
  94. # [01:22] <jgraham> masinter: I doubt the market research data mentions content type sniffing explicitly
  95. # [01:22] <masinter> jgraham: so you have any personal experience with content-type sniffing?
  96. # [01:23] <masinter> i was just looking at the table again, and noticing content-type sniffing for application/postscript
  97. # [01:23] <jgraham> masinter: It's not something I have worked on directly. So only the amount of experience you get by osmosis doing general browser QA
  98. # [01:23] <masinter> and trying to figure out why a user would switch browsers if the browser they were using wouldn't sniff application/postscript
  99. # [01:24] <masinter> i mean, since it doesn't help you any to sniff postscript, because most people don't have a postscript interpreter installed anyway
  100. # [01:24] <Philip`> If I clicked a link to a .ps file of an academic paper and got a load of gibberish text, I'd be pretty unhappy
  101. # [01:24] <tantek> masinter, perhaps Adobe could fund a development experiment to create a "conformant" (but real-world-web-site-content-breaking) browser (e.g. fork Moz or WebKit and rm all the compat behavior) and see if anyone bothered to use it as a primary browser.
  102. # [01:24] <masinter> so how does the market share loss argument (which is unsubstantiated) even apply for postscript?
  103. # [01:24] <masinter> so you'd want it to infer application/octet-stream?
  104. # [01:25] <jgraham> masinter: Well presumably the type of people looking at postscript documents have postscript interpreters installed
  105. # [01:25] <masinter> why are you making normative requirements based on presumptions?
  106. # [01:25] * jgraham isn't doing anything
  107. # [01:26] <masinter> you don't support making content-type sniffing a normative requirement?
  108. # [01:26] <jgraham> Yes, but that's not what you said
  109. # [01:26] <masinter> ok, let's go break this down
  110. # [01:27] <jgraham> Or, at least, I assumed "making normative requirements" refered specifically to the postscript sniffing
  111. # [01:27] <masinter> do you support http://tools.ietf.org/html/draft-abarth-mime-sniff-01 and the HTML specification's normative reference to that as something HTML interpreters MUST follow?
  112. # [01:29] <jgraham> In general, yes. Possibly some details could be altered, I don't know
  113. # [01:30] <masinter> and, in particular, the requirement in section 3 that the 'sniffed type' for documents labeled text/plain should follow the sniffing algorithm such that data that looks like postscript MUST be treated as application/postscript, even though it is text/plain?
  114. # [01:30] <masinter> what justification is sufficient for altering details?
  115. # [01:31] <jgraham> http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx
  116. # [01:33] <jgraham> masinter: Details can be altered if a) they don't match current practice and implementors refuse to change to match the spec or b) there is a compelling (to implementors) case made that the detail can be changed without adversly affecting marketshare
  117. # [01:33] <masinter> yes, i read that blog but it doesn't answer my question about what you think the criteria is for following exactly what IE happened to do?
  118. # [01:34] <masinter> and how do you measure "adversely affecting marketshare"?
  119. # [01:34] <masinter> i'm just wondering whether "compatibility" is taken as covering a multitude of sins where what was really asked for is much more limited
  120. # [01:34] <jgraham> masinter: That ballis in the court of those trying to change the details
  121. # [01:35] <jgraham> I don't know a-priori what arguments would be compelling to indicate that a specific change would not adversly affect compatibility
  122. # [01:36] <masinter> "ball is in the court" metaphor assumes some ownership of the court, doesn't it?
  123. # [01:37] <jgraham> (but obvious things would be studies indicating that a particular part of the sniffing did not apply to a significant number of pages)
  124. # [01:37] <masinter> after all, the internet draft doesn't match current practice, for good reason
  125. # [01:37] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) ("Leaving...")
  126. # [01:37] <masinter> well, since there's never been any evidence that anything besides text/plain => html matters, and even then, only for a limited number of sites
  127. # [01:38] <masinter> and since browser content-type sniffing isn't uniform anyway
  128. # [01:38] <jgraham> I guess you mean that you haven't come across the evidence.
  129. # [01:39] <jgraham> I would be very surprised if that was the case
  130. # [01:39] <tantek> masinter, do you have a test case URL that demonstrates non-uniform browser content-type sniffing?
  131. # [01:39] <masinter> i thought XML wasn't uniform
  132. # [01:39] <tantek> no XML is worse, it's draconian
  133. # [01:39] * jgraham is going to bed now
  134. # [01:40] <masinter> looking for XML test case
  135. # [01:40] <Hixie> tantek: there are lots of areas of content-type sniffing that aren't uniform -- it leads to security bugs, it leads to an arms race increasing how much is sniffed, and it leads to a general low level of interop; that's why I, and now Adam, are trying to specify this.
  136. # [01:40] <masinter> tantek you think all browsers sniff XML from text/plain uniformly?
  137. # [01:40] <Hixie> tantek: we want to nail it does so that this kind of crap can be uniformly implemented and stop spreading like a cancer
  138. # [01:41] <masinter> yeah, i think you're looking at the wrong end of the telescope, and that every case of sniffing actually needs to be justified by "some users really care" rather than the general principle of "if IE did it, we're going to slavishly follow"
  139. # [01:42] <masinter> i think it's a bad idea to sniff PDF too, for that matter, although Adobe security just said it didn't matter to them much
  140. # [01:42] <tantek> which IE followed vaguely from "if Netscape did it, we're going to follow in order to not 'break' sites"
  141. # [01:42] * da3d found a site earlier today that serves up an svg image as text/plain...
  142. # [01:42] <tantek> Hixie, I think your approach to this problem is reasonable.
  143. # [01:42] <masinter> but if something's labeled text/plain but looks like PDF it should still be treated as text/plain, because if the MIME type is broken, probably something else is too
  144. # [01:42] * tantek would like to see a path forward out of the compat mess.
  145. # [01:43] <masinter> tantek: are you saying my approach is unreasonable?
  146. # [01:43] <Hixie> masinter: the doc adam is working on is so far removed from what IE does that your suggesting that it has any resemblence to it belies your ignorance of the subject
  147. # [01:43] <masinter> oh c'mon Hixie
  148. # [01:43] <tantek> masinter, no, I can see the reason behind your approach as well. but it's just less practical.
  149. # [01:43] <masinter> now you're gonna start calling me names
  150. # [01:43] <masinter> Jane, you ignorant ... etc.
  151. # [01:44] <Hixie> masinter: well, stop trying to troll us then
  152. # [01:44] <masinter> discussing a subject at your convenience is trolling?
  153. # [01:44] <masinter> everybody who disagrees with you is a troll?
  154. # [01:45] <Hixie> masinter: accusing us of following 'general principle of "if IE did it, we're going to slavishly follow"' is either ignorant or a troll. Which is it?
  155. # [01:45] <masinter> we spent quite a while at the TAG meeting talking about sniffing, and i thought it was worth just, you know, talking about it
  156. # [01:45] <tantek> How many people on the TAG have actually built and shipped a browser?
  157. # [01:45] <masinter> you don't make any provocative statements, do you?
  158. # [01:45] <tantek> (in this decade)
  159. # [01:45] <tantek> (not a rhetorical question)
  160. # [01:46] <Hixie> in #whatwg? i make provocative statements all the time :-)
  161. # [01:46] <masinter> i think it is a pretty irrelevant question, isn't it?
  162. # [01:47] <tantek> not at all, it's the difference between architectural handwaving and shipping software brutally tested by a market
  163. # [01:47] <masinter> oh, ok, 'slavishly' was wrong, how about 'without careful consideration of actual user benefit'?
  164. # [01:47] <masinter> tantek, are you saying the TAG does 'architectural handwaving'?
  165. # [01:47] * tantek says this as someone who has done both (handwaving and shipping)
  166. # [01:47] * Quits: Super-Dot (n=Super-Do@adsl-75-61-92-172.dsl.pltn13.sbcglobal.net)
  167. # [01:47] * masinter waves his hand to no effect
  168. # [01:47] <Hixie> masinter: seriously? you think we're ignoring the benefits of users?
  169. # [01:48] <masinter> no, i didn't say you were 'ignoring' it
  170. # [01:48] <Philip`> http://www.igmetall-eisenach.de/pressemitteilungen/pressemitteilung_29_08_05_14_07 doesn't look very good for me in Firefox
  171. # [01:48] <Hixie> masinter: what exactly do you think our motivations are? just to make the web a horrible place?
  172. # [01:48] <masinter> i'm just asking about the end user benefit of application/postscript?
  173. # [01:48] <Hixie> masinter: so you're saying we're incompetent?
  174. # [01:48] <masinter> oh c'mon
  175. # [01:48] <Hixie> we don't carefully consider stuff?
  176. # [01:48] <masinter> in this particular instance, i'm asking for the benefit of your careful consideration
  177. # [01:49] <masinter> what is, please, the end-user benefit of content-type sniffing application/postscript?
  178. # [01:49] <Hixie> no, you're just chain-accusing us of random evils
  179. # [01:49] <masinter> really, i came with a specific question about a specific use case
  180. # [01:49] <Hixie> i'm not interested in discussing technical work with people who go from insulting me to trying to act all innocent by asking technical questions
  181. # [01:49] <masinter> and i got platitudes about market share and who has shipped a browser
  182. # [01:50] <masinter> i'm not insulting you, and asking questions and criticizing the specification you wrote is not directed against you
  183. # [01:50] <Hixie> you're not insulting me? let's see. in the last
  184. # [01:50] <Hixie> 10, 20 minutes
  185. # [01:50] <masinter> no, i really am not
  186. # [01:50] <Hixie> you've said:
  187. # [01:50] <Hixie> * that's we're slavishly following a principle of "if IE did it, we're going to follow"
  188. # [01:51] <Hixie> * that we don't consider users carefully
  189. # [01:51] <masinter> well, read what the barth paper says
  190. # [01:51] <Hixie> * that we're giving you platitudes when we're giving you our actual reasoning
  191. # [01:51] <masinter> I didn't say that you didn't consider users in general, but i can't see it in the particular case
  192. # [01:51] <masinter> "Once one browser vendor implements content sniffing,
  193. # [01:51] <masinter> the other browser vendors are forced to follow suit or risk
  194. # [01:51] <masinter> losing market share"
  195. # [01:52] <masinter> how would you interpret that sentence, from http://www.adambarth.com/papers/2009/barth-caballero-song.pdf
  196. # [01:52] <masinter> once one browser vendor implements X, the other browser vendors are forced to follow suit
  197. # [01:52] <masinter> what is that ? Or do you think the paper is wrong?
  198. # [01:53] <masinter> now "one browser" doesn' mean Amaya, of course, it means the unmentionable Internet Exploder
  199. # [01:53] * Joins: Super-Dot (n=Super-Do@adsl-75-61-92-172.dsl.pltn13.sbcglobal.net)
  200. # [01:53] <Hixie> if you want to ask about something adam wrote, i recommend asking adam
  201. # [01:53] <masinter> so was this just academic hyperbole on Barth's part?
  202. # [01:54] <masinter> so you have no opinion about this logic? It isn't the justification for content-type sniffing?
  203. # [01:54] <masinter> when I asked about the content-type sniffing and research, it's the paper Adam pointed me to
  204. # [01:54] <Hixie> i've already given the justification for mime sniffing in this very conversation, let me repaste it:
  205. # [01:55] <masinter> i mean, we could go back to trading email but it's better just to talk this out, you take what i'm saying and make it personal
  206. # [01:55] <Hixie> <Hixie> there are lots of areas of content-type sniffing that aren't uniform -- it leads to security bugs, it leads to an arms race increasing how much is sniffed, and it leads to a general low level of interop; that's why I, and now Adam, are trying to specify this.
  207. # [01:55] <Hixie> i take what you're saying and make it personal when you insult my competence, yes
  208. # [01:57] <masinter> i'm not talking about you, i'm talking about specs and documents
  209. # [01:57] <masinter> and we're better off to focus on that, it was bad enough that mpilgrim wanted to tell me i was ugly
  210. # [01:57] <Hixie> saying that'we slavishly following things, saying that we write specs without "carefully considering user benefits", that's personal
  211. # [01:57] <masinter> wait, i was talking about this sentence in the barth draft
  212. # [01:57] <masinter> "forced to follow suit"? What is that?
  213. # [01:58] <Hixie> you mean his paper?
  214. # [01:58] <masinter> it wasn't about you or Adam, it was what "browser vendors" felt they were "compelled to do"
  215. # [01:58] <masinter> "slavishly follow" == "forced to follow suit"
  216. # [01:59] <Hixie> you just said slavishly follow was wrong!
  217. # [01:59] <masinter> i think that was legitimate english use that was not about you at all, it was about the presumption of what browser vendors felt they had to do
  218. # [01:59] <Hixie> now you're saying it's right?
  219. # [01:59] <masinter> no, the fact that browser vendors may believe they are forced to follow suite -- i don't dispute that they believe that
  220. # [02:00] <Hixie> but you said we were slavishly following IE
  221. # [02:00] <Hixie> which is completely wrong
  222. # [02:00] <masinter> i just think they are wrong, there are lots of things they could do besides "follow suit"
  223. # [02:00] * masinter looks back
  224. # [02:00] <masinter> "yeah, i think you're looking at the wrong end of the telescope, and that every case of sniffing actually needs to be justified by "some users really care" rather than the general principle of "if IE did it, we're going to slavishly follow"
  225. # [02:00] <masinter> that's what i said
  226. # [02:01] <Hixie> you also said "oh, ok, 'slavishly' was wrong"
  227. # [02:01] <masinter> and you assumed that i was talking about you having this general principle, but certainly it's clear you odn't
  228. # [02:01] <Hixie> let's start this conversation over because you've contradicted yourself so many times i no longer know what to ignore and what not to ignore
  229. # [02:01] <Hixie> hi larry, how are you? how can i help you today?
  230. # [02:01] <masinter> well, ok
  231. # [02:01] * Quits: roc_ (n=roc@115.130.22.130)
  232. # [02:01] <masinter> what's the justification for sniffing application/postscript ?>
  233. # [02:02] <masinter> i know IE does it, and maybe some other browsers too, but there doesn't actually seem to be any end-user benefit, and potentially some harm instead
  234. # [02:02] <masinter> seems like a bad idea
  235. # [02:02] <masinter> well, i don't know that IE does it, i presume that
  236. # [02:03] <masinter> I'm assuming every bit of sniffing that IS done in draf-barth is becasue someone else already does it, and probably someone else = IE
  237. # [02:03] <masinter> is there a specific end-user benefit for that?
  238. # [02:03] <Hixie> I believe the justification for having sniffing for application/postscript in the spec is that when i created that table, I copied the algorithms in Mozills's codebase that were unambiguously beneficial to users.
  239. # [02:03] <masinter> how were they "unambigiously beneficial"?
  240. # [02:04] <masinter> since in this case the benefit seems mysterious
  241. # [02:04] <Hixie> (IE really has very little bearing on what the content-sniffing draft says, in practice, because we used what the other browsers found themselves forced to implement as a guide for what was actually necessary, and what was not)
  242. # [02:04] <masinter> i mean, just because someone implemented it in Mozilla doesn't mean it is unambiguously beneficial
  243. # [02:04] <Hixie> (IE basically ignores Content-Type 99% of the time, so following IE would basically mean throwing out most of the MIME mechanisms)
  244. # [02:05] <masinter> right? You're not assuming that "since Mozilla did it, it must be right", of course
  245. # [02:05] * Hixie looks at adam's draft to make sure he's talking about the right table
  246. # [02:06] <masinter> " I copied the algorithms in Mozills's codebase that were unambiguously beneficial to users." -- how did you determine "unambiguously beneficial"?
  247. # [02:07] <Hixie> this sniffing is beneficial because if a user finds a page with no MIME type, or the MIME types unknown/unknown, application/unknown, or */*, or if the user loads a text/plain page that is clearly not text/plain (since it contains raw binary), and if the page is in fact a postscript page, it's more useful to show the postscript in an interpreted fashion than expose the user to the source of the file.
  248. # [02:07] <Hixie> in practice, in particular, users prefer browsers that allow them to print the resulting files, rather than show the source
  249. # [02:08] <masinter> what postscript interpreters to people have?
  250. # [02:08] <Hixie> and market research data (not published) shows this kind of thing (though not necessarily this specific case) is the #1 reason for users to switch browsers.
  251. # [02:08] <masinter> most operating systems don't come with postscript interpreters, and when people install them, the ones i've used -- most of them over the years -- don't do the right thing anyway
  252. # [02:09] <masinter> so trying to fire up something that isn't installed, or something that is installed and does the wrong thing -- how does that help anyone?
  253. # [02:09] <Hixie> generally, users specifically opting to view postscript pages have postscript interpreters, i would imagine (though this is not based on any hard data)
  254. # [02:09] <Hixie> it doesn't do the wrong thing, actually -- it will typically offer the file to be saved to disk
  255. # [02:09] <Hixie> which is reliably more useful to users than showing the content raw on the screen
  256. # [02:09] <Philip`> (I believe most Linuxes have PS interpreters by default)
  257. # [02:10] <masinter> do they, Philip?
  258. # [02:10] <Philip`> masinter: I believe so
  259. # [02:11] <masinter> i'm just interested in the "unambiguously beneficial" bit
  260. # [02:12] <masinter> the other example where type sniffing seems harmful is interpreting text/plain as text/xml even if it's mal-formed
  261. # [02:12] <Hixie> what would the benefit be of _not_ either offering the file to download or opening the file in a PS interpreter?
  262. # [02:12] <Philip`> (e.g. okular (KDE) and evince (Gnome) both support PDF and PS and some other formats)
  263. # [02:12] <Hixie> i don't believe text/plain is _ever_ sniffed as text/xml by adam's draft
  264. # [02:12] <masinter> it would be better to assume application/octet-stream than application/postscript
  265. # [02:12] <Hixie> that would be a security risk
  266. # [02:12] <Hixie> masinter: why?
  267. # [02:13] <masinter> because just because it starts with a few bytes of the header is no indication that the rest of the file is valid
  268. # [02:14] <masinter> it's a heuristic at best, and the consequences are ugly. at least with text/html you can View Source and see the original text/plain
  269. # [02:14] <masinter> and you're not turning text into application
  270. # [02:14] <Hixie> wait, which case are you talking about?
  271. # [02:14] <masinter> no, application/octet-stream is lower capability than text/plain
  272. # [02:14] <masinter> and much lower than application/postscript. It means that *no* automatic processing should happen
  273. # [02:14] <Hixie> text/plain containing binary being interpreted as application/postscript, you think that would be better interpreted as application/octet-stream?
  274. # [02:15] <masinter> better not being interpreted
  275. # [02:15] <Hixie> or...?
  276. # [02:15] <masinter> since application/octet-stream is the explicit "type unknown" mime type
  277. # [02:15] <Hixie> i'm not sure i understand what you're saying browsers should do and in what case
  278. # [02:16] <masinter> well, if we can agree that a change is in order because there's a problem, then working out the solution is next
  279. # [02:16] <Hixie> which case are you talking about?
  280. # [02:16] <masinter> there are a lot of ways in which browsers could respond to a heuristically determined server configuration error, only one of which is to automatically assume that because the heuristic triggered
  281. # [02:17] <masinter> well, i noticed application/postscript and thought it was worth understanding the justification for that in the current draft
  282. # [02:18] <masinter> i thought it was worth at least talking this out first, don't you? would you have preferred to wait for some formal objection with a line-by-line analysis first?
  283. # [02:18] <Hixie> so you're proposing that text/plain-labeled content, containing undisplayable binary and starting with the postscript signature, instead of being interpreted as application/postscript, would be better interpreted as application/octet-stream?
  284. # [02:18] <Hixie> i'm jsut trying to understand your proposal
  285. # [02:18] * Joins: miketaylr (n=miketayl@user-0cdf5gs.cable.mindspring.com)
  286. # [02:19] <masinter> i haven't made a proposal yet, and don't want to make one offhand
  287. # [02:19] <Hixie> oh. what did you mean by "it would be better to assume application/octet-stream than application/postscript" then?
  288. # [02:19] <masinter> well, that would be better, but i don't know if it would be best
  289. # [02:20] <masinter> it's worth examining what all of the alternatives are to the current proposed behavior before making a concrete proposal, isn't it?
  290. # [02:20] <Hixie> so you're saying that in your opinion, if the UA finds text/plain-labeled content containing undisplayable binary and starting with the postscript signature, it would be better (though maybe not best) if, instead of being interpreted as application/postscript, it was interpreted as application/octet-stream?
  291. # [02:21] <masinter> well, "interpreted as application/octet-stream" is pretty misleading
  292. # [02:21] <masinter> it would be better if no automatic interpretation were offered, and the user instead prompted to save the file
  293. # [02:22] <othermaciej> that's what "interpreted as application/octet-stream" amounts to in practice
  294. # [02:22] <Hixie> that's also what "interpreted as application/postscript" amounts to in practice, unless the user has a viewer, which i understand (based on masinter's comments) is not the common case
  295. # [02:22] <masinter> well, i think i understand that, not sure everyone who reads this dialog would know that for sure, and "rather than interpreting as X, interpret as Y" where X is the best guess -- sounds like an odd proposal
  296. # [02:23] <Hixie> oh i thought you said Y in this case was the better guess
  297. # [02:23] <masinter> well, and the possibility that Linux systems often have postscript interpreters, maybe Firefox on Linux does something interesting?
  298. # [02:24] <masinter> the only harm to users in not doing sniffing is that they always are offered to save the file without invoking the displayer automatically
  299. # [02:24] <Hixie> no, not at all
  300. # [02:24] <Hixie> in this case, not doing sniffing would mean showing the undisplayable binary content to the user
  301. # [02:24] <masinter> why is it undisplayable?
  302. # [02:24] <masinter> my emacs displays binary data just fine, and so does notepad
  303. # [02:25] <Hixie> the file in this example is "text/plain-labeled content containing undisplayable binary and starting with the postscript signature", that's the case we're talking about
  304. # [02:25] <masinter> yes, exactly
  305. # [02:25] <masinter> well, you're saying "undisplayable" and I think it is "ugly"
  306. # [02:25] <masinter> but most systems display it
  307. # [02:26] <masinter> and it might be a general heuristic about text/plain data with ugly (or undisaplayable) binary
  308. # [02:26] <Hixie> this only gets invoked with files containing control characters that are by definition invalid in text/plain
  309. # [02:26] <othermaciej> Safari has an inline PostScript viewer
  310. # [02:26] * masinter fires up windows safari
  311. # [02:27] * Joins: benward (n=benward@98.210.154.133)
  312. # [02:27] <othermaciej> not the Windows version
  313. # [02:27] <othermaciej> (yet, anyway)
  314. # [02:27] <othermaciej> Mac Safari displays PostScript and PDF files natively in the browser window (with ability to download or open in external viewer provided)
  315. # [02:28] * masinter switches to mac
  316. # [02:28] <othermaciej> the reason I cite this is because, for Safari at least, sniffing as "application/octet-stream" vs "application/postscript" would result in significantly different behavior
  317. # [02:28] * Quits: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  318. # [02:29] <othermaciej> contra Hixie's earlier remark
  319. # [02:30] <Hixie> iirc, the case larry was saying that not sniffing would be better for is the case where the signature is present but the file isn't postscript -- any idea how safari handles that case?
  320. # [02:30] <othermaciej> long ago, we would often display binary files labeled as text/plain in UglyText format
  321. # [02:30] <othermaciej> that's what we would do if we had no sniffing
  322. # [02:30] <othermaciej> users really really hated that behavior back when it happened frequently
  323. # [02:31] <masinter> i'm going through www-cdf.fnal.gov/offline/PostScript/
  324. # [02:31] <othermaciej> not only due to the ugly, but also because it was unclear to them how to actually download, and often because binary files would take forever to render as text and hog lots of memory
  325. # [02:31] <Hixie> othermaciej: yeah that matches my experience with other browsers
  326. # [02:32] <othermaciej> if we tried to view a file with the PostScript signature inline and it wasn't really PostScript, we would probably show a broken partial rendering, but would still offer the "download" and "open in external viewer" controls
  327. # [02:32] <Hixie> so a superset of treating it as larry suggested, as application/octet-stream?
  328. # [02:33] <Hixie> that seems better than just treating it as application/octet-stream
  329. # [02:33] <othermaciej> that amounts to treating it as application/postscript (though I'm not sure if we actually presently sniff for the PostScript signature)
  330. # [02:34] * masinter is looking at MIME types
  331. # [02:35] <othermaciej> and yes, I think a broken attempt to render as PostScript is likely better than just downloading (a file that looks like a PostScript file but isn't, is most likely a damaged but perhaps still usable PostScript file)
  332. # [02:35] <othermaciej> and it is definitely better than a broken attempt to render as plain text
  333. # [02:36] <masinter> if a site misconfigures postscript and sends it as plain text, wouldn't they also send other binary data as plain text too?
  334. # [02:36] <othermaciej> probably
  335. # [02:36] <masinter> shar files, .double files, etc?
  336. # [02:36] <masinter> so those would show up as ugly text too?
  337. # [02:36] <othermaciej> I think the most common data types sent erroneously as plaintext are video files
  338. # [02:37] <masinter> unix binaries
  339. # [02:37] <othermaciej> I think the algorithm to detect unrenderable text would identify most of those things and treat them as "application/octet-stream"
  340. # [02:38] <othermaciej> (and thus cause them to download instead of displaying inline)
  341. # [02:38] <masinter> so not sniffing postscript wouldn't generate ugly text anyway
  342. # [02:39] <Hixie> if postscript were removed from that table, then the user would just get the "save as" dialog
  343. # [02:39] <othermaciej> that's right, it would be the difference between "download" and "attempt to display inline as PostScript, with a control available to download"
  344. # [02:39] <masinter> for mac safari users
  345. # [02:39] <Hixie> which i think is pretty unambiguously worse than having the choice between saving it or immediately viewing it
  346. # [02:39] <othermaciej> (assuming that sniffing for binary-looking stuff in text/plain was retained in general)
  347. # [02:40] <masinter> well, unless it isn't really postscript
  348. # [02:40] <Hixie> in particular, for instance, users downloading videos are usually downloading porn they want to see right away, and are not trying to save them to disk
  349. # [02:40] <masinter> i was talking about postscript, not videos. are there video types in the table?
  350. # [02:40] <Hixie> not yet, but adam and i were talking about adding them
  351. # [02:40] <Hixie> since that would be a big help to users
  352. # [02:41] <othermaciej> I haven't personally seen content that looks like PostScript but isn't, to the degree that trying to render it as PostScript is actively harmful
  353. # [02:41] <masinter> i'm still puzzled by the market share justification
  354. # [02:41] <masinter> maybe it's just Adam & etc's choice of wording
  355. # [02:41] <othermaciej> the market share justification skips a few steps in the logic
  356. # [02:41] <othermaciej> here's the bottom line:
  357. # [02:42] <othermaciej> - Not having sniffing causes some sites not to work as users expect, often enough that browsers lacking sniffing noticed.
  358. # [02:42] <masinter> i'm not arguing there isn't a 'market share justification', just the quantifiers in the logic
  359. # [02:42] <othermaciej> - Users complain to browser vendors or switch browsers when sites don't work.
  360. # [02:42] <othermaciej> - Browser vendors believe that not providing adequate real-world compatibility hurts their market share.
  361. # [02:43] <masinter> does that make sense? You might justify that "some sniffing of some times are necessary if sites that require it are widely deployed and important to users, and the consequences of sniffing are egregious enough to be noticable"
  362. # [02:43] <othermaciej> I can tell you that Web site compatibility is still a big concern for Safari, even though we have been out for 8 years and have many major companies actively looking to support us.
  363. # [02:43] <masinter> yes, of course "Web site compatibility" is a big concern and i'm not doubt it
  364. # [02:43] <othermaciej> We spent most of our engineering effort over those 8 years fixing Web compatibility bugs.
  365. # [02:43] <masinter> i'm not doubting the steps of the logic, or your efforts
  366. # [02:44] <Hixie> that's not the bottom line, the bottom line is this: we tried requiring that UAs not browser sniff for 19 years, and the result was that the requirement was ignored.
  367. # [02:44] <othermaciej> Our Product Marketing still cites it as a very important area for users.
  368. # [02:44] <masinter> no, that's hardly the bottom line of anything
  369. # [02:44] <Hixie> so now we're trying to mitigate the damage by saying how it should be done
  370. # [02:44] <Hixie> that is the only reason i'm doing this
  371. # [02:44] <Hixie> i want interop
  372. # [02:44] <masinter> for 19 years we've had "browser wars" where browser vendors went out of their way to encourage behavior differences and paid people to put up "best viewed by IE/Netscape" badges
  373. # [02:44] <othermaciej> I can stand behind those statements, but I don't think I can prove that removing sniffing specifically would have a large effect on market share.
  374. # [02:45] <othermaciej> we haven't really done heads-up A/B experiments of sniffing and not sniffing to see how many more users switch to other browsers, or how many fewer adopt Safari
  375. # [02:45] <Hixie> masinter: and is that going to change?
  376. # [02:45] <othermaciej> we are not inclined to do that level of investigation
  377. # [02:45] <masinter> i appreciate your efforts, but i don't think it's insulting you to question some of the conclusions you've come to
  378. # [02:46] <Hixie> you haven't insulted me since we restarted the conversation, indeed
  379. # [02:46] <Hixie> but do you think the browser wars are going to end?
  380. # [02:46] <othermaciej> the browser wars are currently escalating, not cooling down
  381. # [02:46] <masinter> i hope they will but i don't understand why they would
  382. # [02:46] <othermaciej> fortunately, all the major browser vendors seem to see interoperability as more in their interest than proprietary author-targeted features
  383. # [02:47] <Hixie> masinter: well, if the browser wars are the reason the requirement to not sniff was ignored, and we have no reason to think they would stop other than hope, i respectfully suggest we should go with the working assumption that for the forseeable future, the requirement not to sniff will continue to be ignored
  384. # [02:48] <masinter> oh hmm, well someone started this trend
  385. # [02:48] <masinter> I mean, someone was first in sniffing, and the other browser vendors followed suit, right?
  386. # [02:48] <Hixie> they long ago became millionaires and retired
  387. # [02:49] <masinter> well, what about sniffing video?
  388. # [02:49] <masinter> nobody would put up a site with videos labeled as text/plain if it didn't work in SOME browser
  389. # [02:50] <masinter> and the people who built the browser that sniffed video -- are they all millionaires and retired?
  390. # [02:50] <Hixie> probably, i believe that would be the IE team
  391. # [02:50] <Hixie> they sniff pretty much everything
  392. # [02:51] <masinter> well, so... are there a lot of postscript files mislabeled as text/plain?
  393. # [02:52] <masinter> maybe a list of 3-4 examples?
  394. # [02:52] <Hixie> no idea off-hand
  395. # [02:52] <Hixie> i don't really see any harm in sniffing in the case where the mime type is absent altogether
  396. # [02:52] <Hixie> in fact, iirc that's what http suggests doing
  397. # [02:52] <masinter> it says MAY not MUST
  398. # [02:53] <Hixie> sure, so does adam's draft
  399. # [02:53] <masinter> i don't think it says SHOULD, lemme check
  400. # [02:53] <masinter> well, unless it's an escallation
  401. # [02:53] <masinter> but almost everything is an escalation
  402. # [02:53] <masinter> i mean, if you have a buggy jpeg implementation, jpeg is an escalation
  403. # [02:54] <Hixie> and the text/plain-content-with-binary-data case is basically the same as there being no type -- you have something you know isn't text/plain, so the choice is between treating it as just unknown, or treating it as something known but not text/plain
  404. # [02:54] <masinter> sniffing could even be site-by-site with a table of well-known broken sites, and sniffing prompting
  405. # [02:54] <Hixie> which is the same as when you have something unknown because it has no type -- the choice then is between treating it as just unknown, or treating it as something known
  406. # [02:55] <masinter> i've started getting warnings about bad certificates
  407. # [02:55] <masinter> which i never got before
  408. # [02:55] <masinter> no, text/plain content with binary data is different from there being no type, by a long shot
  409. # [02:55] <Hixie> well, yes, in that the default behaviour is worse, sure
  410. # [02:56] <masinter> if it's mislabeled, it's a warning to be suspicious about other things
  411. # [02:56] <masinter> Hixie: you quoted something i said as if it were really wrong, about how matching reality is sometimes not the most important goal
  412. # [02:57] <masinter> but sometimes reality sucks, and trying to match it isn't nearly as good as trying to fix it
  413. # [02:57] <Hixie> surely the goal of any spec is to have the spec and reality match, however that happens
  414. # [02:57] <masinter> sometimes reality is insecure, divergent, broken, crashing, giving bad experiences, etc.
  415. # [02:58] <masinter> well, you know, there's leadership: sometimes you have to propose something that vendors jointly agree to do even if none of them would do it if the others didn't agree
  416. # [02:58] <masinter> certainly all of the new stuff is in that category -- nobody's implemented it before it was proposed
  417. # [03:00] <masinter> etc. ... insecure, not international, inconsistent with other software that you also want to interoperate with, there are performance difficulties, not accessible, .... there's a long list of ways in which the community actually needs to be led out of local minima
  418. # [03:01] <masinter> i think the difference is really how long you're willing to wait
  419. # [03:01] <othermaciej> the sites with a lot of mislabeled content tend to be in the "long tail"
  420. # [03:01] <othermaciej> so listing them is not practical, but nontheless they do have a significant user impact
  421. # [03:01] <masinter> i didn't say list them all, just give some examples
  422. # [03:02] <masinter> i read several suggestions in the history about asking users "This site seems to mislabel images, want me to try to show them anyway?"
  423. # [03:02] <masinter> and then remembering that on a site-by-site basis
  424. # [03:03] <Hixie> when would a user say "no"?
  425. # [03:03] <othermaciej> you suggested "a table of well-known broken sites", it was not clear to me that this was as an example rather than as a restriction on sniffing
  426. # [03:03] <masinter> i mean, after all, people are sending their sites to google every time they go to a new page
  427. # [03:03] <masinter> oh sorry, Maciej, you're right, i made two suggestions
  428. # [03:03] <masinter> you could seed the user's configuration
  429. # [03:03] <othermaciej> It seems to me that citing live Web content for examples of particular practices is a bad idea, since it's likely to change
  430. # [03:04] <masinter> well, this would be "site's i'm willing to let you sniff"
  431. # [03:04] <masinter> it would apply back-pressure, if the sites were maintained, to fix them
  432. # [03:04] <othermaciej> then such a seed list would not work well for my cited "long tail" reason
  433. # [03:05] <Hixie> masinter: btw, do you agree with the statement "the goal of any spec is to have the spec and reality match, however that happens"? it wasn't clear if you were agreeing or not, above.
  434. # [03:05] <masinter> there are numerous web applications that aren't browsers and don't have the 'market share' argument that would be better off if sniffing weren't a requirement
  435. # [03:05] <masinter> hixie, it's a timing issue
  436. # [03:05] <othermaciej> I don't think having users opt in to sniffing on a per-site basis would improve the user experience
  437. # [03:05] <othermaciej> I think it would harm the user experience
  438. # [03:06] <masinter> and the word "match", I think, has a wide range of interpretations
  439. # [03:06] <othermaciej> so I would not be inclined to go that way, even if not for the collective action problem
  440. # [03:06] <Hixie> masinter: how long as you willing to wait?
  441. # [03:06] <masinter> well, that depends a bit on the impact of the divergence
  442. # [03:06] <othermaciej> I think it would be silly for me as a browser developer to prioritize the needs of developers of non-browser applications over the needs of my users
  443. # [03:07] <masinter> i'm in favor of specs actually acknowledging current practice, telling people what's really going on
  444. # [03:07] <Hixie> masinter: how long as you willing to wait for the least impactful divergence?
  445. # [03:07] <masinter> "least impactful" is "no impact", no?
  446. # [03:08] <masinter> any time you have a normative requirement that can't be tested, there's no way to determine whether the spec matches reality, is there?
  447. # [03:08] <Hixie> masinter: how long as you willing to wait for implementations and the corresponding specs to be 100% in convergence?
  448. # [03:09] <masinter> need to go soon lets wrap this part up before we get onto anything else
  449. # [03:09] <masinter> specifications, standards, draft standards, are *proposals* for implementors
  450. # [03:10] <masinter> which implementors either agree or don't agree to implement
  451. # [03:10] <Hixie> 5 years? 10 years? 20 years? 100 years?
  452. # [03:10] <masinter> and in the history of standards, there are no standards that are uniformly and exactly and pricely followed
  453. # [03:10] <Hixie> this doesn't seem like a question that needs a complicated answer
  454. # [03:10] <Hixie> are you saying it's ok for standards to not be uniformly and exactly and pricely followed?
  455. # [03:10] <masinter> it does, because the thing you're asking for a time frame for is complicated
  456. # [03:11] <masinter> can you name a standard that is?
  457. # [03:11] <Hixie> HTML5 will be in 2022
  458. # [03:11] <masinter> the width of railroad tracks? The distance between threads in a screw?
  459. # [03:11] <masinter> can you name any standard in the history of standards that has ever precisely and uniformly and exactly followed?
  460. # [03:11] <masinter> the length of a meter?
  461. # [03:12] <masinter> i think that got redefined anyway, wavelength of cesium?
  462. # [03:12] <masinter> i forget
  463. # [03:12] <Hixie> i cannot name any web standards that match reality, no, and i consider that a failing of our industry that i am trying to address in the specs i work for
  464. # [03:12] <Hixie> do you disagree?
  465. # [03:12] <masinter> disagree that you're trying to address this?
  466. # [03:12] <Hixie> disagree that it's a problem
  467. # [03:13] <masinter> it's a problem that no standard in this history of standards in computer software has ever been exactly and precisely implemented by anyone? Or more than any one implementor?
  468. # [03:14] <Hixie> right
  469. # [03:14] <masinter> well, i dunno, i have some modesty here
  470. # [03:15] <masinter> i've worked on a lot of standards, and i think it's better to have a realistic goal of interoperability
  471. # [03:15] <Hixie> ok, let me phrase it another way
  472. # [03:15] <Hixie> what goal is more important than the goal of specs matching reality within a time frame of a few years or decades?
  473. # [03:15] <masinter> that the standard helps people build things that work together, that seems like a more realistic goal, especially if the things work better than they did when the standard was written
  474. # [03:16] <masinter> that it's helpful to the industry in general, that it leads people to better solutions jointly than they would have made if they were all working alone or in private consortia
  475. # [03:16] <masinter> W3C's motto is "Leading the web to its full potential"
  476. # [03:16] <Hixie> aah, that explains a lot about our arguments
  477. # [03:16] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
  478. # [03:17] <masinter> yes, i think so, of course, a standard isn't very helpful if nobody follows it
  479. # [03:17] <Hixie> indeed if you consider getting people to work together to be more important than getting full documented interop, then the html5 effort and the specs that it has spawned lie mimesniff are going to seem quite alien to you
  480. # [03:17] <masinter> i'm not sure, but my impression is that most people involved in this effort agree with my goal more than with yours, but i'd be interested in a poll
  481. # [03:17] <masinter> hardly alien
  482. # [03:18] <masinter> i mean, i think i understand what you want to do, i just don't think it's practical, and it's causing a lot of difficulties and alienating a lot of pepole who actually want to lead the industry to better things, rather than just describe whatever it is that a few browser vendors are willing to claim is "reality"
  483. # [03:18] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  484. # [03:18] <masinter> like with the character sniffing
  485. # [03:19] <masinter> you said something about all browsers implementing it or else having known bugs that they would implement it
  486. # [03:19] <masinter> i was going to joke about the cow planning commission's planned cowpath
  487. # [03:20] <masinter> and even then, there's a big range in a spec between descriging what's implemented, what MAY be done, what SHOULD be done, and what MUST be done
  488. # [03:21] <masinter> lots of ways of mandating the 'right thing' without nailing down behavior which isn't necessary in order to accomplish interoperability
  489. # [03:21] <tantek> masinter, very little of what W3C has produce over the past 10 years (e.g. http://w3.org/TR/ ) has anything to do with "Leading the web to its full potential". Mostly either useless specs, or useful only to BigCorps and behind the firewall / intranets - quite disconnected from the reality of "the web".
  490. # [03:21] <Hixie> i think your goal is a worthy goal, i just think specs are a horrible way to go about achieving that goal
  491. # [03:21] <masinter> there's no reason to believe that browser makers, if there were a spec by 2012, would continue to follow it anyway
  492. # [03:22] * Quits: tantek (n=tantek@70.36.139.108)
  493. # [03:22] <masinter> seems to me that, at least in my experience in standards, that's what all standards efforts have been about
  494. # [03:22] <Hixie> if you want people working together, team building exercises, open retreats, social outings, unconferences, and the like are far more effective
  495. # [03:22] <masinter> well, no, i don't think so, because you actually need agreement on a technical spec
  496. # [03:23] <Hixie> if implementors (browser vendors or otherwise) find reason to start deviating from the spec, then the spec needs changing
  497. # [03:23] <Hixie> as i've said before, no spec is ever "finished" or "done" until it's obsolete
  498. # [03:23] <masinter> i do remember an standards subcommitee meeting where i called a meeting of the committee to convene in the hot tub
  499. # [03:23] <masinter> well, that's certainly not the case with any other standard I can think of, can you name anohter spec that has that policy?
  500. # [03:24] <Hixie> CSS has that policy
  501. # [03:25] <Hixie> but as i said, i think we as an industry have failed because of not having this policy
  502. # [03:25] <masinter> well, does anyone agree with you on that?
  503. # [03:25] <Hixie> it's pretty much the consensus of the csswg and the whatwg, as far as i can tell, though i've hardly done a formal poll on the subject
  504. # [03:26] <Hixie> aaron sent an e-mail to the whatwg list basically asking us to move to that modal formally
  505. # [03:26] <Hixie> which i imagine we'll do once html5 is done
  506. # [03:26] <Hixie> ("done" as in there are no remaining missing sections, not "done" as in interoperably implemented)
  507. # [03:27] <masinter> i think we might be able to make progress on technical issues without resolving the philosophy question
  508. # [03:27] <Hixie> possibly, but in that case you have to realise that we may come to different conclusions based on the same data, because our goals differ
  509. # [03:28] <masinter> Hixie: I don't think you're goal is *wrong* in the sense that it isn't desirable
  510. # [03:29] <masinter> well, hmmmm
  511. # [03:29] <masinter> actually, no, i guess i would still say it's secondary
  512. # [03:30] <masinter> writing specs that helps the industry build stuff that works better than it would if the spec hadn't been written is more important than making sure the spec precisely and exactly and completely describes what everyone has and will do in the future
  513. # [03:30] <masinter> put that way, your goal sounds very Orwellian: everything that isn't mandatory is forbidden
  514. # [03:31] <masinter> s/has and will do in the future/has implemented/ ?
  515. # [03:32] <masinter> it's the same reason why i think that interoperability with deployed browsers with significant deployed base and are unlikely to change quickly should be a goal
  516. # [03:32] <Hixie> i thought you said it shouldn't be a goal
  517. # [03:33] <masinter> well describing how to accomplish it
  518. # [03:33] <masinter> i mean, if you want to be useful to web site builders, giving them a clue, considering what they have to do ... those are factors
  519. # [03:34] <masinter> because otherwise we'll have a HTML5 web and a non-HTML5 web, and that doesn't help the industry build stuff than works better etc...
  520. # [03:34] <Hixie> the goal "matching reality" means that there will only be an HTML5 web
  521. # [03:34] <masinter> i really do have to go but i think this has been useful, hope you have
  522. # [03:35] <Hixie> even if it means matching browsers that won't change
  523. # [03:36] <masinter> i'm willing to continue this later if you are, but i need to go now, ok?
  524. # [03:37] <Hixie> sure
  525. # [03:37] <Hixie> later
  526. # [03:37] * Quits: masinter (n=user@c-76-102-104-162.hsd1.ca.comcast.net) ("ERC Version 5.2 (IRC client for Emacs)")
  527. # [03:49] * Joins: doublec (n=doublec@118-92-57-189.dsl.dyn.ihug.co.nz)
  528. # [03:52] * Joins: tantek (n=tantek@67.180.202.79)
  529. # [03:56] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  530. # [04:07] * Joins: wakaba_ (n=wakaba@98.225.100.220.dy.bbexcite.jp)
  531. # [04:16] * Quits: doublec (n=doublec@118-92-57-189.dsl.dyn.ihug.co.nz) ("Leaving")
  532. # [04:26] * Quits: wakaba (n=wakaba@221.157.197.113.dy.bbexcite.jp) (Read error: 113 (No route to host))
  533. # [04:44] * Quits: heycam (n=cam@nat/mozilla/x-jwborwnrgqgqhdvl) (Read error: 104 (Connection reset by peer))
  534. # [04:46] * Quits: shepazu (n=schepers@nat/mozilla/x-ywddnatibfxnjfxd)
  535. # [04:52] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  536. # [05:04] * Quits: tantek (n=tantek@67.180.202.79)
  537. # [05:20] * Quits: gunderwonder (n=gunderwo@143.84-49-178.nextgentel.com) (Read error: 110 (Connection timed out))
  538. # [05:29] * Quits: miketaylr (n=miketayl@user-0cdf5gs.cable.mindspring.com)
  539. # [05:30] * Quits: aboodman (n=aboodman@72.14.229.81)
  540. # [05:35] * Quits: mpilgrim (n=mpilgrim@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 104 (Connection reset by peer))
  541. # [05:36] * Joins: mpilgrim (n=mpilgrim@96.10.240.189)
  542. # [05:44] * Joins: doublec (n=doublec@118-92-57-189.dsl.dyn.ihug.co.nz)
  543. # [05:46] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  544. # [05:51] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 145 (Connection timed out))
  545. # [05:51] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  546. # [05:52] * Quits: benward (n=benward@98.210.154.133) (Read error: 110 (Connection timed out))
  547. # [05:54] * Joins: tantek (n=tantek@70.36.139.108)
  548. # [06:01] * Joins: roc_ (n=roc@115.130.56.46)
  549. # [06:08] * Joins: JoePeck (n=JoePeck@74.69.85.249)
  550. # [06:17] * Joins: benward (n=benward@98.210.158.106)
  551. # [06:37] * Joins: heycam (n=cam@66.134.141.179)
  552. # [06:48] * Joins: tantekc (n=tantek@70.36.139.108)
  553. # [06:48] * Quits: tantek (n=tantek@70.36.139.108) (Connection reset by peer)
  554. # [06:48] * tantekc is now known as tantek
  555. # [06:56] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
  556. # [07:00] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  557. # [07:16] * Joins: shepazu (n=schepers@66.134.141.179)
  558. # [07:34] * Quits: doublec (n=doublec@118-92-57-189.dsl.dyn.ihug.co.nz) ("Leaving")
  559. # [07:37] * Joins: tantekc (n=tantek@70.36.139.108)
  560. # [07:37] * Quits: tantek (n=tantek@70.36.139.108) (Read error: 104 (Connection reset by peer))
  561. # [07:37] * tantekc is now known as tantek
  562. # [08:05] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  563. # [08:21] * Quits: annodomini (n=lambda@wikipedia/lambda)
  564. # [08:22] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 113 (No route to host))
  565. # [08:22] * othermaciej_ is now known as othermaciej
  566. # [08:24] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  567. # [08:25] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Nick collision from services.)
  568. # [08:25] * othermaciej_ is now known as othermaciej
  569. # [08:51] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  570. # [08:53] * Quits: tantek (n=tantek@70.36.139.108) (Read error: 131 (Connection reset by peer))
  571. # [08:53] * Joins: tantekc (n=tantek@70.36.139.108)
  572. # [08:53] * tantekc is now known as tantek
  573. # [08:58] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  574. # [09:00] * Joins: mpilgrim_ (n=mpilgrim@rrcs-96-10-240-189.midsouth.biz.rr.com)
  575. # [09:01] * Quits: mpilgrim (n=mpilgrim@96.10.240.189) (Read error: 131 (Connection reset by peer))
  576. # [09:01] * mpilgrim_ is now known as mpilgrim
  577. # [09:10] * Joins: zalan (n=zalan@catv-89-135-110-21.catv.broadband.hu)
  578. # [09:16] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  579. # [09:16] * Joins: weinig_ (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  580. # [09:16] * Joins: |zalan| (n=zalan@catv-89-135-110-21.catv.broadband.hu)
  581. # [09:29] * Quits: tantek (n=tantek@70.36.139.108)
  582. # [09:37] * Quits: zalan (n=zalan@catv-89-135-110-21.catv.broadband.hu) (Read error: 110 (Connection timed out))
  583. # [09:43] * Quits: benward (n=benward@98.210.158.106) ("Sleep")
  584. # [09:43] * Joins: erlehmann (n=erlehman@80.187.104.233)
  585. # [09:46] * Joins: benward (n=benward@98.210.158.106)
  586. # [09:54] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  587. # [09:57] <hsivonen> this reminded me of some standards discussions: http://farm3.static.flickr.com/2488/3952434921_3c9b723ee8_b.jpg
  588. # [10:23] * hsivonen notes that Mac OS X and most Linux distros ship with the capability to display .ps files. Only Windows is the odd one out.
  589. # [10:40] <Philip`> Windows doesn't even ship with the capability to display .pdf files
  590. # [10:51] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
  591. # [10:51] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  592. # [10:57] * Quits: roc_ (n=roc@115.130.56.46)
  593. # [10:59] * Quits: Super-Dot (n=Super-Do@adsl-75-61-92-172.dsl.pltn13.sbcglobal.net) ("Colloquy more like Coolloquy")
  594. # [11:01] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
  595. # [11:06] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  596. # [11:07] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  597. # [11:08] <othermaciej> hsivonen: amusing
  598. # [11:08] * Joins: nessy (n=nessy@124-170-205-120.dyn.iinet.net.au)
  599. # [11:11] * Joins: maikmerten (n=maikmert@BAE052e.bae.pppool.de)
  600. # [11:12] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  601. # [11:13] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  602. # [11:21] * Quits: benward (n=benward@98.210.158.106) (Read error: 110 (Connection timed out))
  603. # [11:24] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  604. # [11:27] * maikmerten is now known as maik|eat
  605. # [11:30] * Quits: erlehmann (n=erlehman@80.187.104.233) (Read error: 145 (Connection timed out))
  606. # [11:33] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 113 (No route to host))
  607. # [11:33] * othermaciej_ is now known as othermaciej
  608. # [11:53] * Joins: Super-Dot (n=Super-Do@adsl-75-61-92-172.dsl.pltn13.sbcglobal.net)
  609. # [11:54] * Joins: Steve^ (n=steve@92.40.61.34.sub.mbb.three.co.uk)
  610. # [11:58] * Joins: workmad3 (n=davidwor@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  611. # [11:58] * Quits: Super-Dot (n=Super-Do@adsl-75-61-92-172.dsl.pltn13.sbcglobal.net) (Client Quit)
  612. # [12:00] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  613. # [12:00] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  614. # [12:00] * othermaciej_ is now known as othermaciej
  615. # [12:02] <Hixie> http://damowmow.com/playground/microdata/004/ is my proposal for what we'll test monday
  616. # [12:02] <Hixie> it takes into account the stuff we've learnt so far
  617. # [12:05] * Joins: jacobolus (n=jacobolu@140.247.239.92)
  618. # [12:06] <Steve^> the item attribute has gone, replaced by itemscope and itemtype?
  619. # [12:12] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  620. # [12:12] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  621. # [12:12] * othermaciej_ is now known as othermaciej
  622. # [12:17] <Steve^> At first I assumed itemprop="fn org" labelled the string as both fn and org, just like class="foo bar" works.
  623. # [12:18] <Steve^> But I see the space is part of the name too, is this wise?
  624. # [12:18] <Steve^> In all other cases a hyphen is used instead
  625. # [12:19] * Philip` attempts to use git
  626. # [12:19] <Philip`> User-friendliness point 1: you can run "git add -n" for the same as "git add --dry-run", but you have to run "git push --dry-run" and can't run "git push -n"
  627. # [12:21] <Hixie> Steve^: it actually does do what you thought in the real syntax
  628. # [12:21] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  629. # [12:21] <Hixie> Steve^: i just didn't want to try to explain that in the study, and it wasn't the point being tested
  630. # [12:21] <Steve^> ah, ok
  631. # [12:22] <Hixie> and yes, see http://damowmow.com/playground/microdata/NOTES for the changes and reasoning
  632. # [12:22] <Steve^> I'm the guy that notices these things and gets annoyed that the teacher won't tell me the truth :P
  633. # [12:23] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  634. # [12:23] <Hixie> yeah, i know the feeling!
  635. # [12:23] <Steve^> Hixie, who are the test subjects?
  636. # [12:24] <Hixie> the intro doc has to be as brief as possible to not take too much of the hour for them to read, while hitting all the points they'll need for the exercises, so i was focusing on conveying tutorial-like info, not spec-like info
  637. # [12:24] <Hixie> you mean their names? :-)
  638. # [12:25] <Steve^> are they people off the street? college students? web developers?
  639. # [12:25] <Hixie> web devs
  640. # [12:25] <Hixie> and software engineers
  641. # [12:25] <Hixie> from various walks of life
  642. # [12:26] <Steve^> then I feel good about my employability
  643. # [12:26] <Hixie> we
  644. # [12:26] <Hixie> er
  645. # [12:26] <Hixie> we've had an interesting range of people
  646. # [12:26] <Hixie> some were highly competent, and got this concept pretty quickly
  647. # [12:27] <Steve^> oh
  648. # [12:27] <Hixie> others thought they did but were stumbling around having problems with things that weren't even being studied
  649. # [12:27] <Hixie> like basic html syntax
  650. # [12:27] <Steve^> you mention a few things that were a problem for everyone
  651. # [12:28] <Hixie> yeah, containership in particular
  652. # [12:28] <Hixie> i've tried to make the intro doc introduce that concept more forcefully
  653. # [12:28] <Hixie> to see if it was just a poor intro, or if the concept itself is hard
  654. # [12:28] <Hixie> similarly i've made the intro say explicitly that you can't just make up names
  655. # [12:29] <Steve^> the intro reads very very well
  656. # [12:30] <Hixie> if it tests well i might just end up using it almost verbatim as the intro section
  657. # [12:30] <Steve^> itemref seems upside-down to me, if you took a section out of context, you may lose the itemref link and the name/value pair loses meaning or becomes part of another item
  658. # [12:31] <Steve^> itemfor at least tells you it doesn't belong there, even if you don't know the whole story
  659. # [12:31] <Hixie> seems the problems exist in both directions
  660. # [12:33] <Philip`> Require the syntax to indicate the link in both directions, then it's harder to unknowingly break
  661. # [12:33] <Steve^> I think itemref breaks more than itemfor
  662. # [12:34] <Steve^> as it could add data to an item that shouldn't be there
  663. # [12:34] <Steve^> I like the idea of articles being completely extractable, independent of their surroundings
  664. # [12:35] <Hixie> the problem with itemfor="" is that it's a performance nightmare -- given an item, you have no choice but to walk the entire DOM to find if there are any more properties
  665. # [12:38] <Philip`> If you're extracting all the items from a document, that's not a problem, because you have to walk the DOM anyway and you can keep track of itemfors while you're doing it
  666. # [12:38] <Philip`> so it only seems a problem when you're trying to extract microdata from a specific element on the page
  667. # [12:39] * Philip` doesn't know how the use cases typically would be extracting data
  668. # [12:41] * Philip` wonders if querySelector('*[itemfor]') would be unreasonably slow anyway
  669. # [12:42] <Steve^> there are use cases?! :)
  670. # [12:45] <Hixie> the DOM API would be a case where you're trying to extract microdata from a specific element on the page
  671. # [12:45] <Hixie> and it happens to be a case where performance is critical
  672. # [12:46] <Hixie> ok bed time
  673. # [12:46] <Hixie> nn
  674. # [12:46] <Steve^> bye
  675. # [12:49] * Joins: j4_james (n=James@bb-87-82-3-146.ukonline.co.uk)
  676. # [13:01] * Joins: riven (n=colin@5ED0BF60.cable.ziggo.nl)
  677. # [13:11] * Joins: zdobersek (n=zan@cpe-92-37-77-47.dynamic.amis.net)
  678. # [13:12] * Quits: zdobersek (n=zan@cpe-92-37-77-47.dynamic.amis.net) (Read error: 104 (Connection reset by peer))
  679. # [13:18] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  680. # [13:18] * Joins: othermaciej_ (n=mjs@69.181.42.237)
  681. # [13:18] * othermaciej_ is now known as othermaciej
  682. # [13:20] * Quits: othermaciej (n=mjs@69.181.42.237) (Read error: 131 (Connection reset by peer))
  683. # [13:20] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  684. # [13:20] * othermaciej_ is now known as othermaciej
  685. # [13:21] * Joins: zdobersek (n=zan@cpe-92-37-77-47.dynamic.amis.net)
  686. # [13:30] * Quits: workmad3 (n=davidwor@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  687. # [13:34] <AryehGregor> Sigh, yet another video about HTML5 only available if you have Flash.
  688. # [13:36] <Steve^> there are videos about HTML5?
  689. # [13:37] <murr5y> gief url!
  690. # [13:37] <AryehGregor> http://vimeo.com/6691519
  691. # [13:38] <AryehGregor> I didn't bother watching.
  692. # [13:38] <murr5y> well obv, it's on vimeo
  693. # [13:38] <AryehGregor> (Using Chrome on Linux, where enabling plugins causes the browser to freeze up every ten minutes, has given me remarkable fortitude in resisting the temptation to use Flash.)
  694. # [13:38] <AryehGregor> Maybe whatwg.org should offer to host HTML5-related videos in Theora with <video> only.
  695. # [13:39] <AryehGregor> Maybe it could allow uploads to the wiki, actually. I think OggHandler would need setup as an extension, though, off the top of my head.
  696. # [13:39] <Steve^> Why are you using Chrome then?
  697. # [13:40] * Joins: gunderwonder (n=gunderwo@143.84-49-178.nextgentel.com)
  698. # [13:40] <AryehGregor> Because Firefox is hideously slow by comparison, at least for me. Not so much with a fresh profile, but I can't be bothered to dig through what's wrong with my Firefox profile.
  699. # [13:40] <murr5y> flash is shabby in linux either way :p
  700. # [13:40] <Steve^> I found Opera handy with flash problems. Clearly flash was at fault, but Firefox would tend to crash too, whereas Opera would be a little more graceful
  701. # [13:40] <AryehGregor> I also like a lot of the features, like more screen real estate and such.
  702. # [13:41] <murr5y> i use opera/linux, it's relatively stable but crashes once in a while
  703. # [13:41] <Steve^> Its interesting to see how anti-accessible chrome is heading
  704. # [13:41] <AryehGregor> In what way?
  705. # [13:41] <Steve^> disabled users would benefit from more buttons on the chrome
  706. # [13:41] <AryehGregor> Really?
  707. # [13:41] <Steve^> such as text zoom buttons
  708. # [13:41] <Steve^> yes
  709. # [13:41] <AryehGregor> Do you have data to support that?
  710. # [13:41] <Steve^> Not personally, but it was heavily backed at standards.next
  711. # [13:42] <Steve^> users can be shown where the particular options are to make text bigger, but they easily forget
  712. # [13:42] <Steve^> the menus are too confusing. Having a button under the users nose may help them use these options
  713. # [13:42] <othermaciej> having lots of buttons in the default UI is bad for most people
  714. # [13:42] <AryehGregor> Frankly, I'm not disabled, so I don't really care. If you have poor vision, you should be increasing your default OS font size.
  715. # [13:42] <AryehGregor> (I don't personally care, I mean. If I were a Chromium dev I'd care.)
  716. # [13:43] <Steve^> sure
  717. # [13:43] <AryehGregor> (But not at the expense of non-disabled users, since there are way more of them.)
  718. # [13:43] <Steve^> the concensus is
  719. # [13:43] <Steve^> that you should have a javascript text soom function on your site
  720. # [13:43] <Steve^> because we can't trust the browsers and OS settings to me easy to set
  721. # [13:43] <Steve^> which is daft, but that's the way it is
  722. # [13:44] <othermaciej> in Safari on Mac, you can use Command + and Command - to zoom
  723. # [13:44] <Steve^> othermaciej, that's not helpful
  724. # [13:44] <othermaciej> which for experienced users is much more memorable than any button, since it is quick and consistent across apps
  725. # [13:44] <Steve^> the user needs to remember that
  726. # [13:44] <othermaciej> I dare say it's more helpful than having zoom buttons on the default toolbar (you can customize the toolbar to add them)
  727. # [13:44] <Steve^> memorable is a bad assumption for accessibility
  728. # [13:45] <othermaciej> putting lots of buttons in the toolbar is a bad assumption for usability by anyone
  729. # [13:45] <othermaciej> there is also an OS-wide screen zoom feature
  730. # [13:45] <Steve^> sure, don't put everything on there
  731. # [13:46] <othermaciej> I think web pages adding zoom (with different behavior than the built-in kind) is likely to be more confusing than helpful
  732. # [13:46] <AryehGregor> Has anyone presented any data indicating a real problem?
  733. # [13:46] <Steve^> I'm bringing this information from a meeting of people working with cognitive and other disabilities
  734. # [13:46] <AryehGregor> And do they have actual data?
  735. # [13:47] <Steve^> yes
  736. # [13:47] <AryehGregor> Guess they should file an issue in Chrome's issue tracker, then.
  737. # [13:48] <Steve^> one woman showed us videos of people interacting with common websites, she's done a lot of hands on work with disabled users
  738. # [13:48] <Steve^> but she doesn't seem to have a website, so I'm not sure what I can show you
  739. # [13:48] <AryehGregor> "Give our small minority of users extra space on the toolbar that's wasted for everyone else" probably isn't an adequate solution, though.
  740. # [13:48] <Steve^> But it is a fact that many users cannot remember where the browsers settings for text size is
  741. # [13:48] <AryehGregor> They shouldn't have to, they should set it once in the OS if they need to.
  742. # [13:48] <AryehGregor> And have it work for all apps.
  743. # [13:48] <Steve^> or any other setting
  744. # [13:49] <Steve^> should is another bad word
  745. # [13:49] <Steve^> unfortunately we have to work with what people actually do, rather than what they should
  746. # [13:49] <othermaciej> most users don't change any settings
  747. # [13:49] <Steve^> A good example is an internet cafe with a different browser and a computer that can't be altered
  748. # [13:49] <Steve^> how do we allow them to use our website?
  749. # [13:50] <othermaciej> however, it would be wrong to conclude from this that UI should be designed to cater to a wide variety of special needs
  750. # [13:50] <Steve^> this could be a council website, viewed from a library machine for example
  751. # [13:50] <othermaciej> (the default UI)
  752. # [13:50] <Steve^> So, a dialog should pop up at the start, please select your disabilities:
  753. # [13:51] <AryehGregor> No, dialogs are evil.
  754. # [13:51] <othermaciej> Mac OS X does let you indicate you are blind at install (or initial system configuration) time and goes straight into spoken UI
  755. # [13:51] <Steve^> bruce posted a link on twitter to a site about html5 with massive text. It was actually too big to read and I closed the site
  756. # [13:51] <Steve^> This is what users do when they have difficulties, they close the site
  757. # [13:52] <Steve^> I think Mac OS X is a bad example as not everyone can use it
  758. # [13:52] <AryehGregor> Burdening all users with things that are only really needed for a small minority is still not the answer.
  759. # [13:52] <Steve^> and I don't think Apple give cheap macs to people that need them
  760. # [13:53] * jgraham wonders what OS "everyone can use"
  761. # [13:53] <Steve^> Perhaps not, but what is the answer?
  762. # [13:53] <AryehGregor> Realistically, essentially everyone can use a Windows desktop. Lots of people need to run Windows-only apps, few people need to run Mac/Linux-only apps.
  763. # [13:54] <othermaciej> the answer is to allow minorities to configure software for their needs fairly easily
  764. # [13:54] <AryehGregor> Steve^, maybe there is none. Life acts that way sometimes.
  765. # [13:54] <AryehGregor> Cure all visual disabilities, how about that?
  766. # [13:54] <othermaciej> Mac OS X ships with a screen reader included, but we don't turn it on for all users
  767. # [13:54] <AryehGregor> C'mon, we're in the middle of a biotech revolution, right?
  768. # [13:54] <othermaciej> likewise it has high-contrast mode which is also not on by default
  769. # [13:55] <AryehGregor> othermaciej, I talked to a blind user once about screen readers. IIRC, he said the major screen readers were Windows were both terrible and horrifyingly expensive; the Linux ones were about as terrible as the Windows ones, but at least they were free; and OS X's was awesome and came bundled with the OS. :)
  770. # [13:55] <AryehGregor> s/were Windows/for Windows/
  771. # [13:55] <othermaciej> sorry to keep using Mac OS X as an example based on the fact that I think it does things well
  772. # [13:55] <jgraham> AryehGregor: Well I could, but I would have to buy windows. Just like I had to buy a Mac (my desktop was second hand and so didn't have an OS)
  773. # [13:56] <Steve^> anyway, my original point is that chrome is going the wrong way
  774. # [13:56] <Steve^> minimalist designs confuse people
  775. # [13:56] <AryehGregor> I totally disagree. And so do Google's usability studies.
  776. # [13:56] <othermaciej> I don't think that is true as a general rule
  777. # [13:56] <AryehGregor> (which, presumably, are mostly on people who aren't disabled)
  778. # [13:56] <murr5y> complex designs confuse people
  779. # [13:56] <Steve^> I think Microsofts choice to hide the menu bar from everything is very confusing
  780. # [13:57] <Steve^> I hate menus that auto-hide items
  781. # [13:57] * jgraham finds the Chrome UI somewhat too minimal but that might not be typical
  782. # [13:57] <othermaciej> there is such a thing as being too minimalist, to the point that you can't find needed features
  783. # [13:57] <Steve^> I need to be able to see the options
  784. # [13:57] <AryehGregor> That I agree with, but I don't think it's comparable to Chrome's UI decisions.
  785. # [13:57] <murr5y> it's a fine line
  786. # [13:57] * Quits: maik|eat (n=maikmert@BAE052e.bae.pppool.de) (Remote closed the connection)
  787. # [13:57] <murr5y> and it all depends on the users needs
  788. # [13:57] <othermaciej> but in general, user interfaces with fewer moving parts are easier to use
  789. # [13:58] <Steve^> if you are trained with the Office ribbon, it is nice to use
  790. # [13:58] <Steve^> but IE7 is dreadful for finding options
  791. # [13:58] <jgraham> It's more like UIs with the right (and only the right) moving parts are easiest to use
  792. # [13:58] <othermaciej> of course, I work for a company famous for making a device with only one button, so I may be biased
  793. # [13:58] <AryehGregor> http://www.theonion.com/content/video/apple_introduces_revolutionary
  794. # [13:58] <Steve^> doesn't it have 2 buttons?
  795. # [13:58] <AryehGregor> (another Flash-only video, of course)
  796. # [13:58] <jgraham> e.g. it turn out that the apple remote is a terrible ui for doing text input
  797. # [13:59] <jgraham> because it only has 5 buttons
  798. # [13:59] <othermaciej> that I'd believe
  799. # [14:00] <othermaciej> I certainly would not use it to write my novel, or even compose an email
  800. # [14:01] <Steve^> I must depart, be back later
  801. # [14:01] <jgraham> We were using one to find music on youtube and the gap between songs was about as long as the songs because entering the search terms was so slow
  802. # [14:01] * Parts: Steve^ (n=steve@92.40.61.34.sub.mbb.three.co.uk) ("Leaving")
  803. # [14:02] <jgraham> Not taht this has anything to do with the chrome ui, really
  804. # [14:02] <othermaciej> not really, no
  805. # [14:15] <annevk2> why is there itemtype now? I thought types were based on elements?
  806. # [14:16] <annevk2> wow, that Web IDL discussion exploded
  807. # [14:19] * Quits: nessy (n=nessy@124-170-205-120.dyn.iinet.net.au) ("This computer has gone to sleep")
  808. # [14:20] * jgraham doesn't know if it is worth making a case for catchalls
  809. # [14:21] <annevk2> 400 new messages during the weekend is no fun
  810. # [14:21] <jgraham> Especially since they are pretty much part of the legacy now
  811. # [14:21] <jgraham> annevk2: I sympathise
  812. # [14:22] <othermaciej> making a case for them being good?
  813. # [14:22] <jgraham> othermaciej: Making a case for them being a naural fit for localStorage
  814. # [14:22] <jgraham> *natural
  815. # [14:23] <othermaciej> they are, but the possibility for conflict with built-in methods and properties makes them hard to use safely
  816. # [14:24] <jgraham> What do you mean safely? Just "people have to avoid creating items called toString" or someething security related?
  817. # [14:24] <othermaciej> having storage items named "key", "length" or "clear" is not that unlikely
  818. # [14:24] <othermaciej> not security, just "easy to write buggy code accidentally"
  819. # [14:25] <othermaciej> for example, if you write APIs that layer on top of Storage and handle arbitrarily named storage items, you'd better use getItem() / setItem() instead of brackets
  820. # [14:26] <jgraham> There is a concern there
  821. # [14:27] <jgraham> Although it is generally true in ECMAScript that if you try to use an object as a hash table you can trip over the things in the prototype chain
  822. # [14:27] <othermaciej> yep - would be nice to have proper hashtables of some sort
  823. # [14:28] <jgraham> Indeed, and if ECMAScript had them localStorage woul be using that API instead
  824. # [14:29] <jgraham> I tend to think that if people are trying to make some natural feeling API and the language makes it hard to do that safely it is a problem with the language rather than with the desire for that API
  825. # [14:30] <jgraham> Although it is harder to fix the language than just avoid certian designs
  826. # [14:32] * Quits: weinig_ (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  827. # [14:32] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  828. # [14:32] <othermaciej> I think if the Storage object forced you to use methods (maybe just "get" and "set" instead of getItem and setItem) it would not feel much less natural
  829. # [14:33] <othermaciej> (of course it's too late to change now, but speaking hypothetically)
  830. # [14:47] * Joins: myakura (n=myakura@p2034-ipbf4205marunouchi.tokyo.ocn.ne.jp)
  831. # [14:48] * Joins: Phae (n=phaeness@81.99.213.109)
  832. # [14:50] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  833. # [14:50] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  834. # [14:50] * othermaciej_ is now known as othermaciej
  835. # [14:52] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (niven.freenode.net irc.freenode.net)
  836. # [14:52] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  837. # [14:53] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
  838. # [14:55] * Joins: TabAtkins (n=chatzill@70.139.15.246)
  839. # [14:55] * Quits: TabAtkins (n=chatzill@70.139.15.246) (Client Quit)
  840. # [14:56] * Joins: GarethAdams|Home (n=GarethAd@5ac3fd38.bb.sky.com)
  841. # [14:57] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  842. # [14:58] * Joins: ROBOd (n=robod@89.122.216.38)
  843. # [15:02] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  844. # [15:03] * Joins: othermaciej (n=mjs@69.181.42.237)
  845. # [15:12] * Joins: ttepasse (n=ttepas--@p5B0150A8.dip.t-dialin.net)
  846. # [15:12] * Quits: othermaciej (n=mjs@69.181.42.237) (Read error: 145 (Connection timed out))
  847. # [15:22] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  848. # [15:26] * Joins: roc (n=roc@115.130.8.181)
  849. # [15:31] * Joins: aroben (n=aroben@unaffiliated/aroben)
  850. # [15:32] * Joins: Midler (n=midler@212.37.124.243)
  851. # [15:32] * Joins: maikmerten (n=maikmert@77.132.5.46)
  852. # [15:40] * Quits: GarethAdams|Home (n=GarethAd@5ac3fd38.bb.sky.com)
  853. # [15:56] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  854. # [15:56] * Quits: jacobolus (n=jacobolu@140.247.239.92) (Remote closed the connection)
  855. # [16:13] * Joins: annodomini (n=lambda@c-75-69-96-104.hsd1.nh.comcast.net)
  856. # [16:14] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  857. # [16:21] * and is now known as Guest262
  858. # [16:23] * Joins: theMadness (n=petal@host50-5-static.58-217-b.business.telecomitalia.it)
  859. # [16:25] <theMadness> Ouhm, xfn seems to be conflicting with html5.
  860. # [16:25] <theMadness> http://gmpg.org/xfn/join <=point 3, that doesn't quite validate.
  861. # [16:38] <gsnedders> theMadness: Everything ignores the profile attribute anyway.
  862. # [16:39] <theMadness> Yay. :P
  863. # [16:39] * Quits: roc (n=roc@115.130.8.181) (Read error: 110 (Connection timed out))
  864. # [16:46] * Quits: JoePeck (n=JoePeck@74.69.85.249) (Read error: 131 (Connection reset by peer))
  865. # [16:46] * Joins: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  866. # [16:47] * Quits: gsnedders (n=gsnedder@217.44.35.222) ("Adios intarwebs.")
  867. # [16:52] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  868. # [16:53] * Joins: Steve^ (n=steve@92.40.61.34.sub.mbb.three.co.uk)
  869. # [17:00] * Quits: maikmerten (n=maikmert@77.132.5.46) (Remote closed the connection)
  870. # [17:17] * Quits: heycam (n=cam@66.134.141.179) ("bye")
  871. # [17:18] * Joins: tantek (n=tantek@70.36.139.108)
  872. # [17:24] * Joins: Eahp (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com)
  873. # [17:27] * Quits: shepazu (n=schepers@66.134.141.179)
  874. # [17:29] * Quits: Phae (n=phaeness@81.99.213.109) (Nick collision from services.)
  875. # [17:29] * Eahp is now known as Phae
  876. # [17:30] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  877. # [17:41] * Joins: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  878. # [17:43] * Joins: gsnedders (n=gsnedder@host217-44-35-222.range217-44.btcentralplus.com)
  879. # [17:45] * Joins: workmad3 (n=davidwor@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  880. # [17:50] * Quits: Phae (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com) (Read error: 110 (Connection timed out))
  881. # [17:56] * Quits: yutak_home (n=kee@M006079.ppp.dion.ne.jp) ("Ex-Chat")
  882. # [17:59] * Joins: sbublava (n=stephan@77.117.227.249.wireless.dyn.drei.com)
  883. # [17:59] * Joins: jonpierce (n=jonpierc@c-98-216-49-27.hsd1.ma.comcast.net)
  884. # [18:01] * Quits: sbublava (n=stephan@77.117.227.249.wireless.dyn.drei.com) (Client Quit)
  885. # [18:15] * Joins: shepazu (n=schepers@nat/mozilla/x-lhzrblwsxerswodv)
  886. # [18:16] * Joins: heycam (n=cam@nat/mozilla/x-bvkmukttogqlphug)
  887. # [18:16] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  888. # [18:16] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  889. # [18:19] * Quits: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Read error: 110 (Connection timed out))
  890. # [18:22] * Joins: jacobolus (n=jacobolu@140.247.133.68)
  891. # [18:34] * Joins: svl (n=me@g228027037.adsl.alicedsl.de)
  892. # [18:37] <hsivonen> We should define Universal Representation Locators
  893. # [18:38] * Quits: gsnedders (n=gsnedder@host217-44-35-222.range217-44.btcentralplus.com) (Remote closed the connection)
  894. # [18:38] * Joins: ROBOd2 (n=robod@89.122.216.38)
  895. # [18:38] * Joins: gsnedders (n=gsnedder@host217-44-35-222.range217-44.btcentralplus.com)
  896. # [18:43] * Quits: jacobolus (n=jacobolu@140.247.133.68) (Remote closed the connection)
  897. # [18:43] * Quits: ROBOd (n=robod@89.122.216.38) (Read error: 145 (Connection timed out))
  898. # [18:58] * Joins: xmlscript (n=chatzill@220.181.67.190)
  899. # [19:15] * Quits: myakura (n=myakura@p2034-ipbf4205marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  900. # [19:18] * Quits: xmlscript (n=chatzill@220.181.67.190) ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]")
  901. # [19:22] <AryehGregor> hsivonen, or define "resource" to mean "representation, since no one uses content negotiation anyway, stfu".
  902. # [19:26] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  903. # [19:28] * Joins: aboodman (n=aboodman@72.14.229.81)
  904. # [19:28] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
  905. # [19:32] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  906. # [19:34] <hsivonen> AryehGregor: yeah, that would be better
  907. # [19:35] <Dashiva> That would just make even more noise
  908. # [19:35] <Dashiva> Go with Representation, that way you don't change a stable and useful existing standard
  909. # [19:37] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  910. # [19:39] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
  911. # [19:40] * Quits: svl (n=me@g228027037.adsl.alicedsl.de) ("And back he spurred like a madman, shrieking a curse to the sky.")
  912. # [19:49] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  913. # [19:49] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
  914. # [19:50] * Quits: fupp (n=User@mg038a.studby.ntnu.no) (Read error: 110 (Connection timed out))
  915. # [19:50] * Quits: annodomini (n=lambda@wikipedia/lambda)
  916. # [19:53] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  917. # [19:54] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
  918. # [20:03] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  919. # [20:04] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
  920. # [20:08] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  921. # [20:08] * Quits: aboodman (n=aboodman@72.14.229.81)
  922. # [20:10] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
  923. # [20:11] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  924. # [20:18] * Quits: zdobersek (n=zan@cpe-92-37-77-47.dynamic.amis.net) (Read error: 104 (Connection reset by peer))
  925. # [20:22] * Joins: zdobersek (n=zan@cpe-92-37-77-47.dynamic.amis.net)
  926. # [20:23] * Quits: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  927. # [20:25] * Joins: dbaron (n=dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  928. # [20:33] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
  929. # [20:34] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  930. # [20:49] * Quits: gsnedders (n=gsnedder@host217-44-35-222.range217-44.btcentralplus.com) (Remote closed the connection)
  931. # [20:58] * Joins: maikmerten (n=maikmert@BAE052e.bae.pppool.de)
  932. # [21:03] * Joins: jre (n=chatzill@mail.greenbytes.de)
  933. # [21:04] * Joins: GarethAdams|Home (n=GarethAd@5ac3fd38.bb.sky.com)
  934. # [21:17] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  935. # [21:20] * Quits: jonpierce (n=jonpierc@c-98-216-49-27.hsd1.ma.comcast.net)
  936. # [21:22] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  937. # [21:23] * Joins: maikmerten_ (n=maikmert@U14fd.u.pppool.de)
  938. # [21:23] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  939. # [21:34] * Quits: maikmerten_ (n=maikmert@U14fd.u.pppool.de) (Remote closed the connection)
  940. # [21:38] * Quits: maikmerten (n=maikmert@BAE052e.bae.pppool.de) (Read error: 110 (Connection timed out))
  941. # [21:50] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  942. # [21:51] * Quits: ROBOd2 (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  943. # [22:05] * Quits: zdobersek (n=zan@cpe-92-37-77-47.dynamic.amis.net) ("Leaving.")
  944. # [22:06] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  945. # [22:14] * Quits: eighty4 (n=eighty4@eighty4.se) ("ZNC - http://znc.sourceforge.net")
  946. # [22:15] * Joins: eighty4 (n=eighty4@eighty4.se)
  947. # [22:15] * Joins: sebmarkbage (n=miranda@h-73-244.A146.priv.bahnhof.se)
  948. # [22:17] * Joins: Blazeix (n=wafuqua@24.169.235.59)
  949. # [22:19] * Joins: danbri (n=danbri@unaffiliated/danbri)
  950. # [22:24] * Joins: rubys1 (n=rubys@cpe-065-190-139-141.nc.res.rr.com)
  951. # [22:24] * Parts: rubys1 (n=rubys@cpe-065-190-139-141.nc.res.rr.com)
  952. # [22:28] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  953. # [22:29] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Remote closed the connection)
  954. # [22:29] * Joins: rubys1 (n=rubys@cpe-065-190-139-141.nc.res.rr.com)
  955. # [22:29] * Parts: rubys1 (n=rubys@cpe-065-190-139-141.nc.res.rr.com)
  956. # [22:29] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  957. # [22:34] * Quits: dbaron (n=dbaron@c-98-234-51-190.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  958. # [22:38] * Parts: Blazeix (n=wafuqua@24.169.235.59)
  959. # [22:45] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  960. # [22:49] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
  961. # [22:54] * Quits: Steve^ (n=steve@92.40.61.34.sub.mbb.three.co.uk) ("Leaving")
  962. # [22:58] <AryehGregor> Hixie, are we still scheduled for October Last Call?
  963. # [22:59] * Joins: gsnedders (n=gsnedder@host217-44-35-222.range217-44.btcentralplus.com)
  964. # [23:00] <Philip`> If there's a delay, we can just redefine October to match the reality of the spec's status
  965. # [23:06] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  966. # [23:21] * Joins: mitnavn (n=mitnavn@unaffiliated/mitnavn)
  967. # [23:25] * Quits: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  968. # [23:34] * Joins: Super-Dot (n=Super-Do@adsl-75-61-92-172.dsl.pltn13.sbcglobal.net)
  969. # [23:43] <jgraham> Isn't the internet in an eternal september anyway?
  970. # [23:49] * Joins: nessy (n=nessy@124-170-205-120.dyn.iinet.net.au)
  971. # [23:56] * Quits: tantek (n=tantek@70.36.139.108)
  972. # Session Close: Mon Sep 28 00:00:00 2009

The end :)