| 00:03 | <nessy> | I'd call that web fundamentalism |
| 00:04 | <Hixie> | i don't even know what he means |
| 00:05 | <Hixie> | which i guess is his point |
| 00:05 | <Hixie> | hopefully he'll clarify |
| 00:35 | <jwalden> | Philip`: it's a character flaw; bz argues too much with people he should ignore, even when he knows better (and he'll be the first to admit it) :-) |
| 00:39 | <roc_> | everyone I know succumbs to that at times |
| 00:42 | <jwalden> | I tend to think bz succumbs more often than others |
| 01:00 | <Hixie> | I used to do that |
| 01:00 | <Hixie> | I designed mail filters to avoid it |
| 01:01 | <Hixie> | (the mail is filtered such that it takes enough effort for me to see it that I don't see it until after the thread is a few days old, at which point I don't feel the need to jump in anymore) |
| 02:34 | <Hixie> | should placeholder="" apply to type=password? what about type=date? type=number? |
| 02:35 | <Hixie> | yes no yes looks like the better answer |
| 02:40 | Hixie | decides yes no no |
| 02:58 | <jcranmer> | ********* yesterday 7 ? |
| 03:17 | <Hixie> | hm? |
| 03:18 | <Hixie> | rb is such a troll it's hilarious |
| 03:18 | <Hixie> | his lst 6 or 7 e-mails have all said the exact same thing and avoided answering any of the actual questions he was asked |
| 09:00 | <yecril71> | The wording "static object" is ambiguous indeed, new or not new. |
| 09:00 | <yecril71> | I would rather say "snapshot" to avoid misunderstandings. |
| 09:03 | <Hixie> | "static" is far more correct english than "snapshot" for this case |
| 09:07 | <hsivonen> | is comatose politically incorrect? The kind of NodeLists the Selectors API returns are comatose, not live. |
| 09:08 | <hsivonen> | or a copy of the value |
| 09:08 | <Hixie> | "static" is the right word, people's misunderstandings notwithstanding |
| 09:30 | <takkaria> | 7B7B7B7B7B7B7B7BThen the operations could still handle that common case of being the |
| 09:30 | <takkaria> | setter/getter methods.Then the operations could still handle that common case of being the |
| 09:30 | <takkaria> | oops, sorry |
| 09:30 | <takkaria> | Then the operations could still handle that common case of being the |
| 09:30 | <takkaria> | ack |
| 09:31 | <takkaria> | mouse is being a bit screwy. and you get no points for guessing what I'm reading |
| 09:37 | <jruderman> | i've been to that erotic-stories site |
| 09:38 | <yecril71> | Tell it to K&R. |
| 09:39 | <yecril71> | The effect of their technical vocabulary cannot be undone, I am afraid. |
| 09:41 | <Hixie> | ? |
| 09:41 | <Hixie> | i rarely understand you, yecril71 :-) |
| 09:42 | <yecril71> | The meaning of "static" is engraved in stone by Kerrighan and Ritchie. |
| 09:43 | <yecril71> | It need not be perfect English but you cannot get rid of that. |
| 09:43 | <yecril71> | Especially in the context of a programming language. |
| 09:49 | <Hixie> | the meaning of static as defined by C-like languages is pretty much exactly what we're talking about here |
| 09:49 | <Hixie> | so that's fine |
| 10:01 | <zcorpan> | Hixie: perhaps you should define "static" alongside "live" and xref it |
| 10:01 | <Hixie> | well it now says "new" |
| 10:01 | <Hixie> | which seems clear to me |
| 10:01 | <Hixie> | since why would you return a new object each time if it was live |
| 10:02 | <zcorpan> | ok |
| 10:05 | <hsivonen> | http://blog.jclark.com/2008/11/what-allowed-in-uri.html |
| 10:08 | <Hixie> | not sure what to make of that |
| 10:17 | <yecril71> | See e.g. the documentation of "itoa", or "localtime". |
| 10:17 | <yecril71> | It is not reentrant *because* it returns a static object. |
| 10:17 | <yecril71> | (a pointer to one) |
| 10:18 | <yecril71> | Your argument about "new" is valid but: |
| 10:18 | <yecril71> | - it can be easily overlooked |
| 10:19 | <yecril71> | - the statement seems contradictory. |
| 10:26 | <Hish> | hi. regarding the <output for"id1 id2 id3> element: is there a way for the #id1 element to find out in which output element it is used for calculation? |
| 10:27 | <hsivonen> | yay for placeholder |
| 10:30 | <Hixie> | Hish: not currently |
| 10:30 | <Hish> | ok. thx. |
| 10:41 | <takkaria> | wow, WF2 integration work is pretty much done |
| 10:46 | <Hixie> | getting there |
| 10:47 | <Hixie> | i need to go through the wf2 spec at one point line by line |
| 10:47 | <Hixie> | making sure i haven't missed anything |
| 10:47 | <hsivonen> | Hixie: do you have plans on rewriting the meta sniffing algorithm as a state machine? |
| 10:48 | <Hixie> | which one? |
| 10:48 | <hsivonen> | Hixie: the prescan on bytes |
| 10:48 | <Hixie> | "8.2.2.1 Determining the character encoding"? |
| 10:49 | <hsivonen> | Hixie: yes |
| 10:49 | <Hixie> | no, no intention of rewriting that section. |
| 10:49 | <Hixie> | why? |
| 10:49 | <Hixie> | does it need it? |
| 10:49 | <hsivonen> | Hixie: it might be useful to implment it as a state machine at least |
| 10:50 | <hsivonen> | unless waiting for the first n bytes has a trivial perf hit even when the meta occurs slighly before n |
| 10:50 | <hsivonen> | Hixie: do you have plans on prescribing speculative script tag prescanning? |
| 10:50 | <Hixie> | i imagine waiting for bytes will take far longer than reading them |
| 10:50 | <Hixie> | no |
| 10:50 | <Hixie> | other than network traffic, it has no observable side-effects |
| 10:51 | <hsivonen> | ok |
| 11:48 | <mookid> | Hixie: someone said you would be the person to talk about with regards to an informal proposal |
| 11:48 | <Hixie> | sure |
| 11:48 | <mookid> | did you read any of it previously? |
| 11:48 | <mookid> | It was a discussion abuot an optional Accept attribute |
| 11:49 | <mookid> | for indicating content-type of a request |
| 11:49 | <mookid> | in the Accept header |
| 11:50 | <Hixie> | just saw an e-mail about it, filed it along with other forms-related feedback for future consideration (it can take years for me to get to replying to a particular e-mail, there's 2545 e-mails in my feedback pile right now) |
| 11:50 | <mookid> | it's not forms related :P |
| 11:50 | <mookid> | an optional tag for <a> or <img> - any hypermedia request |
| 11:51 | <mookid> | to indicate to the browser what Accept header to send |
| 11:51 | <mookid> | having this as part of HTML5 will stop encourageing developers to misuse URI's and include content-type in them |
| 11:52 | <Hixie> | yeah i guess it should have been put in the links folder |
| 11:52 | <Hixie> | no biggie |
| 11:52 | <Hixie> | to be honest though personally i think the whole http content negotiation feature is a big failure and we'd be better off removing the whole thing from http |
| 11:53 | <mookid> | it's a failure because HTML and Browser support for the rfc is pathetic? -_- |
| 11:53 | <Hixie> | i haven't seen many people using it, i've seen very few people needing it, and users seem to get confused by it whenever they are exposed to it |
| 11:53 | <mookid> | you can't use it because the markup is insufficient |
| 11:54 | <Hixie> | no i think it's a failure because it solves a problem that doesn't exist in a way that isn't compatible with the way most people (authors and users) think |
| 11:54 | <mookid> | they only think that way because the HTML they've been working with is crap.! |
| 11:54 | <mookid> | that's not a fair criticism of HTTP |
| 11:54 | <mookid> | that's a problem with HTML and browsers |
| 11:55 | <mookid> | content-type doesn't belong in a resource identifier, is what I'm getting at |
| 11:58 | <Hixie> | what problem does this solve? |
| 11:58 | <Hixie> | content-type is a waste of time too, we should just be using unique identification strings for content types like the PNG header |
| 12:04 | <mookid> | right - you're suggesting that content negotiation belongs in the URI |
| 12:05 | <mookid> | reading Roy Fielding's dissertation it becomes clear that this is not the intention of a URI at all |
| 12:06 | <mookid> | I'm suggesting a way that HTML can allow for both - I don't see how that's a bad thing |
| 12:06 | <mookid> | unless, of course, you understand HTTP better than Roy..! :P |
| 12:08 | <Hixie> | i'm suggesting that there not be any content negotiation because people don't need it or care for it |
| 12:11 | <Hixie> | anyway, bed time for me now |
| 12:11 | <Hixie> | nn |
| 12:14 | <hsivonen> | http://mxr.mozilla.org/mozilla-central/source/parser/htmlparser/public/nsIParser.h#89 |
| 12:14 | <hsivonen> | that's a lot of different cases... |
| 12:14 | <hsivonen> | now I need to figure out which ones are tentative and which ones are confident |
| 12:18 | <hsivonen> | I guess < 9 are tentative and >= 9 are confident |
| 12:42 | <mookid> | Hixie: content negotiation is one of the main components of RESTful APIs - it allows your URI's to serve JSON/XML for application interaction and HTML for user interaction |
| 12:43 | <mookid> | if you take out content-negotiation that means one URI can only serve one content-type |
| 12:43 | <mookid> | one URI = one resource |
| 12:44 | <mookid> | one resource can have many representations |
| 12:47 | <hsivonen> | mookid: what problem is solved if to dereference a link you need a URI and an accept value and then you stick these into separate places in the HTTP request instead of baking the format identification into the URI? |
| 12:47 | <mookid> | because that's not the purpose of a URI |
| 12:47 | <hsivonen> | mookid: that's not a statement of solving a problem. |
| 12:48 | <mookid> | no, but the approach that - well everyone uses URIs to negotiate content so therefore it's the best way |
| 12:48 | <mookid> | is equally insufficient |
| 12:48 | <hsivonen> | why? |
| 12:48 | <mookid> | because it's purely the inadequacy of html and browsers that has led to that |
| 12:48 | <hsivonen> | sounds like dogma to me |
| 12:49 | <hsivonen> | not like an actual problem |
| 12:49 | <mookid> | have you read Roy Fielding's thesis? there are benefits from having one URI for a resource |
| 12:50 | <hsivonen> | mookid: I have read parts of it, but I haven't read it from start to finish. |
| 12:50 | <hsivonen> | mookid: can you point me to a benefit? |
| 12:50 | <mookid> | yes |
| 12:50 | <mookid> | So I can send a colleague a message; 'you can get the report at http://example.com/report';, and they can use that URL in any user agent that is appropriate. A browser is a special case in which many different content-types are dealt with. The same benefit is not achieved if the content is negotiated via the URL, since the user would have to know the type their user agent required and modify the URL accordingly |
| 12:51 | <mookid> | it means that you can use one URI to serve several user agents |
| 12:51 | <hsivonen> | what other user agent would the colleague use? |
| 12:51 | <mookid> | they could maybe use excel |
| 12:51 | <mookid> | or.. word.. or wahtever |
| 12:51 | <mookid> | this is the direction web applications are going |
| 12:52 | <mookid> | I'm not making this up for nothing! |
| 12:52 | <hsivonen> | so isn't the accept header bit then something that the agent should generate instead of something that the the hypertext reference should contain? |
| 12:52 | <mookid> | browsers are different case really |
| 12:53 | <mookid> | they, generally, pass the content to the OS if they can't understand it |
| 12:54 | <mookid> | most UA's just handle one filetype |
| 12:54 | <mookid> | browsers do lots - whcih is why it would be nice to have that ability reflected in html |
| 12:54 | <mookid> | does that make sense? |
| 12:55 | <hsivonen> | so if you feed them general Web URLs, you are likely to end up frustrated, which is why the user probably wants to know a priori that the URL works with a particular kind of non-browser HTTP agent |
| 12:55 | <hsivonen> | mookid: no, I don't think your argumentation makes sense |
| 12:55 | <mookid> | they will, generally, have some idea - the worst that can happen is there UA will say "nope, no good here" |
| 12:55 | <mookid> | well it makes sense because I'm suggesting the best solution is to provide a way to use HTTP as it was intended |
| 12:56 | <hsivonen> | If you send me an URL to a report, why would I try it in Excel if you didn't tell me that it has been specifically crafted to work usefully in Excel? |
| 12:56 | <mookid> | if anyone should be justifying themselves with a use case it should be the guys saying "content negotiation is done in URIs" |
| 12:57 | <mookid> | well the idea is that as the application frameworks for these kinds of APIs grow.. all user agents will be able to interact with the data |
| 12:57 | <mookid> | e.g. opening it in iTunes streams a voice-translated version for the blind |
| 12:57 | <mookid> | that type of thing |
| 12:57 | <hsivonen> | no, only user agents that support the particular flavor(s) of data availabale will work |
| 12:58 | <hsivonen> | it's useless to try a URL that deferences into KML in Excel, for example. |
| 12:58 | <mookid> | right.. so the worst that can happen is a UA says 'nope sorry I dont know what to do with that' |
| 12:58 | <hsivonen> | if I have a zillion agents in addition to a browser, do I try each one when you send me and architecturally correct URL? |
| 12:59 | <mookid> | well you pick the one you know/guess is appropriate |
| 12:59 | <mookid> | you're assuming complete ignorance on behalf of the user |
| 13:00 | <hsivonen> | no, I'm assuming that a user who gets an HTTP URL by email without additional instruction dereferences the URL using a browser |
| 13:00 | <mookid> | I would send an email out saying "here's the report: example.com/report, you can open it in excel, powerpoint, and word" - how would you do it with URIs? :) |
| 13:01 | <hsivonen> | Here's the report in various formats http://example.com/report.xls, http://example.com/report.ppt and http://example.com/report.doc |
| 13:01 | <mookid> | but if they're all the same resourcee |
| 13:02 | <mookid> | just different representations |
| 13:02 | <mookid> | then that's a misuse of the term URI |
| 13:02 | <mookid> | I've spent a fair amoutn of time studying this |
| 13:02 | <mookid> | I'm not suggesting this for fun..! |
| 13:02 | <hsivonen> | I posit that the case where the alternative representations of a resource are truly equivalent is so rare that it is pointless to design for it |
| 13:03 | <mookid> | like RSS feed and index.html ? |
| 13:03 | <mookid> | :) |
| 13:04 | <hsivonen> | an RSS feed and index.html are rarely equivalent in the sense that one didn't contain some information that the other contains |
| 13:04 | <mookid> | I think my report example makes sense.. the only reason these kinds of interactions arent the case is because web application development is young.. and because html discourages peolpe from using URIs as they were intended |
| 13:04 | <mookid> | they are completely equivalent in the majority of cases |
| 13:04 | <mookid> | look at blogs.. |
| 13:04 | <mookid> | look at technorati.. |
| 13:05 | <hsivonen> | mookid: well, depends on at what point in time you cast "intended" in stone |
| 13:05 | <mookid> | well.. |
| 13:05 | <hsivonen> | mookid: the original HTTP didn't even have content types |
| 13:05 | <mookid> | I'd call an rfc.. an intention |
| 13:05 | <mookid> | HTTP 1.1 did |
| 13:05 | <mookid> | and does |
| 13:05 | <mookid> | so that's a mute point |
| 13:05 | <hsivonen> | so one might write Accept off as later day astronauting ;-) |
| 13:05 | <mookid> | ? |
| 13:06 | <mookid> | you aren't doing a very good job of convincing me I have to say |
| 13:06 | <hsivonen> | mookid: HTTP conneg is younger than URLs |
| 13:06 | <mookid> | I've spent a fair while looking at this |
| 13:06 | <hsivonen> | I could say the same thing. |
| 13:06 | <mookid> | well I'm looking at how it is defined now.. and how people are using it moving forwards (which is presumably what HTML5 should be looking at) |
| 13:06 | <mookid> | well you admitted that you havent read that much into it |
| 13:07 | <mookid> | why would you not want to give developers the option at least? |
| 13:07 | <hsivonen> | I haven't read the canonical theory in its entirety. I have considered the practical side quite a bit. |
| 13:07 | <mookid> | how can you do that if you dont have a full grasp of the concepts? |
| 13:07 | <hsivonen> | mookid: giving the option is not free |
| 13:07 | <hsivonen> | mookid: also, conneg sucks for seachability |
| 13:07 | <mookid> | free? |
| 13:08 | <mookid> | does it? |
| 13:08 | <hsivonen> | mookid: implementing the feature has an opportunity cost: the developers wouldn't be doing something else |
| 13:09 | <mookid> | these kinds of functionality is what helps the framework developers |
| 13:09 | <mookid> | if you can standardise this stuff it will assist tooling for proper HTTP transactions |
| 13:09 | <hsivonen> | mookid: yes, without representation-specific URIs and with a countably infinite set of potential Accept values, how do you index all representations of a resource? |
| 13:10 | <mookid> | that's an issue of producing a format for spiders |
| 13:10 | <mookid> | that's a non issue if all it requires is another content type built specifically for crawlers |
| 13:10 | <hsivonen> | well, doing that isn't costless, either |
| 13:10 | <hsivonen> | afk, I'll be back |
| 13:10 | <mookid> | depends how your aplpication is built |
| 13:10 | <mookid> | if you're just providing an extra view to a model |
| 13:10 | <mookid> | it's a 2 second job |
| 13:11 | <mookid> | across the board |
| 13:12 | <mookid> | content negotiation is bad right now for searchability because it *is* done in the URI |
| 13:12 | <mookid> | that's the point I'm trying to get across here |
| 13:13 | <mookid> | google are championing REST for a reason |
| 13:13 | <mookid> | :) |
| 13:14 | <takkaria> | relying on authors to provide an index of their representations to spiders seems very prone to spamming attempts |
| 13:15 | <Philip`> | Why is it any more prone to that than providing a separate HTML document which links to lots of other URIs that spiders will follow? |
| 13:17 | <Philip`> | (Unintentional errors seem a more important problem, because people would forget about their spider-specific index and it would be buggy or out-of-date) |
| 13:17 | <takkaria> | fair point |
| 13:20 | <hsivonen> | mookid: is google really championing REST according to Fielding or POX over HTTP Web services with a lower case s? |
| 13:21 | <hsivonen> | I'd argue that AtomPub-based services are their own class of services with Atom-aware clients. They aren't totally generic conneg |
| 13:44 | <hsivonen> | zcorpan: I believe I've now addressed the problems that blocked building v.nu on Windows |
| 13:59 | MikeSmith | wonders why/whether "using HTTP as it was intended" should be a goal |
| 14:00 | <MikeSmith> | I would doubt that most people would say we are now using HTML as it was originally intended |
| 14:03 | <hsivonen> | looks like I need to expand my fragment parsing API to deal with fragments rooted at foreign content... |
| 14:19 | <hsivonen> | when a document has been created with document.open() and everything is document.written, does the first level of document.write count as being equivalent to a network stream or does it count as the first level of document write? |
| 14:19 | <hsivonen> | I assume the former considering the behavior of Hixie's live dom viewer |
| 14:24 | <zcorpan> | hsivonen: that's nice |
| 14:27 | hsivonen | finds |
| 14:27 | <hsivonen> | // Hack to pass on to the dtd the caller's desire to |
| 14:27 | <hsivonen> | // parse a fragment without worrying about containment rules |
| 14:27 | <hsivonen> | if (aMode == eDTDMode_fragment) |
| 14:27 | <hsivonen> | mCommand = eViewFragment; |
| 14:28 | <hsivonen> | Hixie: have you studied the purpose/impact of Gecko having some kind of magic fragment mode for containment rules? |
| 14:54 | <pergj> | hsivonen: I don't remember seeing anything in the HTML5 spec that would give different behaviour for document.write immediately after document.open |
| 14:56 | <hsivonen> | pergj: but if document.write after document.open counted as the first level of document.write, how could Hixie's live dom viewer have the right document.write semantics? |
| 14:58 | <pergj> | hm... Not sure... |
| 16:58 | <BenMillard> | takkaria, you just sent 5 empty messages. So now who's "fail"! :P |
| 16:59 | <Dashiva> | They're not empty, they're images encoded with lenpeg v2 |
| 17:00 | <BenMillard> | oh, they show up empty in Opera and the logs |
| 17:03 | <Dashiva> | http://www.dangermouse.net/esoteric/lenpeg.html |
| 17:03 | <BenMillard> | yeah, I've just reached the bottom of that :( |
| 17:05 | <takkaria> | ah, oops |
| 17:05 | <takkaria> | my mouse is doing weird things today |
| 17:06 | <takkaria> | mixed with X11's middle-click-is-paste thing, bad things happen |
| 17:16 | <MikeSmith> | takkaria: your mouse should meet Hixie's cats |
| 17:16 | <takkaria> | :) |
| 17:30 | <BenMillard> | MikeSmith, nice job on the TPAC 2008 minutes and overview page. |
| 17:33 | <MikeSmith> | BenMillard: thanks for your prompting. I still need to add some of the links you suggested |
| 17:41 | <jmb> | so, a really unscientific measure of how complex the html5 parsing algorithm is in comparison with a pre-existing html4 parser: |
| 17:41 | <jmb> | sloccount on libxml's HTML{parser,tree}.c => 5188 sloc |
| 17:42 | <jmb> | sloccount on hubbub's tokeniser and treebuilder source trees => 9127 sloc |
| 17:44 | <takkaria> | I imagine hubbub has more boilerplate than lixml though |
| 17:45 | <jmb> | could well. hence "unscientific" :) |
| 17:50 | <jmb> | oh, in case anyone cares, that's libxml 2.7.2, and hubbub svn head |
| 17:56 | <gsnedders> | First two thoughts when writing CV: 1) What do I put in it? 2) How do I mark it up? |
| 17:57 | <takkaria> | look at Tim Bray's |
| 17:57 | gsnedders | doesn't like the markup of Hixie's :) |
| 17:58 | <takkaria> | http://www.tbray.org/ongoing/When/200x/2005/11/12/Template.html |
| 17:59 | <Philip`> | Nobody cares about the markup, since they'll just print it out :-p |
| 17:59 | <gsnedders> | Is it really a table though? |
| 18:04 | <takkaria> | it's not really a table, I don't think, but I don't think it matters |
| 18:04 | <takkaria> | you evidently do :) |
| 18:04 | <gsnedders> | http://alexking.org/site/projects/html-resume-template/demo/resume.php semms a lot closer |
| 18:10 | <BenMillard> | gsnedders, mine is here and I was told "your CV rocks" by 1 potential employer: http://sitesurgeon.co.uk/ |
| 18:10 | <gsnedders> | How ugly. |
| 18:10 | gsnedders | ducks |
| 18:10 | <BenMillard> | yeah, the visual aspects aren't my strong point :) |
| 18:10 | <BenMillard> | the markup and content is what you seemed interested by |
| 18:11 | <BenMillard> | anyway, dinnertime now, cya |
| 18:38 | <gsnedders> | Prince doesn't support meta@charset seemingly |
| 18:42 | <takkaria> | no, it doesn't |
| 18:51 | <jcranmer> | I presume if I had <input type="xxxinvalid">, would getting .type return "text" ? |
| 18:51 | <jcranmer> | s/would/then/ |
| 19:05 | <gsnedders> | jcranmer: yes |
| 19:05 | <jcranmer> | ah, good :-) |
| 19:27 | <Dashiva> | public-hmtl is back in high gear again, I see |
| 19:29 | <takkaria> | lots of revs but the break is on |
| 20:15 | <Lachy> | Hixie, Thanks for finally adding placeholder :-) |
| 23:34 | <Hixie> | man i need to eat before i can reply to the crazy stuff on the w3c html lists |
| 23:35 | <Hixie> | roy fielding in particular appears to live on a different planet |
| 23:37 | <roc> | the one email I read of his suggested that testing your HTML in a browser is bad because you might be tempted to make it less pure |
| 23:40 | <jcranmer> | bwahuh? |
| 23:40 | <gavin> | But now that Firefox is getting just as buggy and complex as |
| 23:40 | <gavin> | the other major browsers, they have no reason to switch at all. |
| 23:40 | <gavin> | Firefox usage hasn't increased since it decided to be no better |
| 23:40 | <gavin> | than the others. |
| 23:41 | <gavin> | that's an interesting assertion! |
| 23:41 | <jcranmer> | numerous factual errors in ther |
| 23:41 | <jcranmer> | there |
| 23:41 | <jcranmer> | shall I pull out the mandatory xkcd reference? |
| 23:42 | <Lachy> | jcranmer, xkcd references are always funny |
| 23:45 | <Philip`> | jcranmer: XKCD references are getting a bit tired now :-p |
| 23:46 | <jcranmer> | it's the one where the character responds to trolls with long, multi-paragraph replies detailing why the poster should just die |
| 23:49 | <Lachy> | http://xkcd.com/493/ |
| 23:49 | <Lachy> | is that the one you meant? |
| 23:50 | <jcranmer> | no, not that one |
| 23:51 | <Lachy> | ok, then I can't find it |
| 23:52 | <jcranmer> | I'm not finding it either |
| 23:52 | <svl> | This one: http://xkcd.com/406/ ? |
| 23:54 | <jcranmer> | yes! |