| 00:08 | <Philip`> | http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml doesn't work in Opera :-( |
| 00:08 | <Philip`> | e.g. it says "The format of the symbol name should be ___H_." instead of "The format of the symbol name should be <PROJECT>_<PATH>_<FILE>_H_." |
| 00:09 | <Philip`> | (XSLT, yay) |
| 02:31 | <Hixie> | did hsivonen mention if he was going to send an analysis of his data? |
| 06:43 | <BenMillard> | hello, is anyone here? |
| 06:56 | <BenMillard> | well, to anyone who reads the logs: I realised that redesigning the complexdatatable.html (test file 3) was suggested by a couple of people (including me), nobody has yet produced a redesigned variant for further review |
| 06:57 | <BenMillard> | so that's what I've been doing during the small hours of this morning, typing my reasoning as I go |
| 06:58 | <BenMillard> | since nobody is here, I'll go to sleep and return some time later...just thought this should be recorded somewhere |
| 08:43 | <annevk> | Hixie, no |
| 10:35 | <annevk> | html4all mailing list is funny |
| 10:35 | <annevk> | especially this recent debate between RB and LHS about what Hixie might have meant with "defining error handling" |
| 11:36 | <annevk> | http://groups.google.com/group/alt.html/msg/9d28ed5dc4c9fa36 "HTML 5 is a bunch of crazy egotists breaking stuff to no benefit." |
| 11:38 | <Lachy> | hah |
| 11:43 | <annevk> | these people see right through us, it's scary |
| 11:43 | <annevk> | in other news, base2 from Dean Edwards will support element.classList |
| 12:34 | <Lachy> | The XSLT void element thread is getting annoying. |
| 12:36 | Philip` | doesn't see why |
| 12:46 | <jgraham> | Lachy: FWIW I think Julian has a reasonable point |
| 12:47 | <jgraham> | I don't see the harm in allowing <eventsource></eventsource> as long as the closing tag immediatley follows the opening tag |
| 12:47 | <jgraham> | I would basically expect the parser to drop the closing tag |
| 12:48 | <jgraham> | So <eventsource>foo</eventsource> would be parsed like <eventsource>foo |
| 12:49 | jgraham | has wasted enough time on the html-wg today |
| 12:51 | <jgraham> | It would be different to </br> but not too different from <script> which requires a closing tag even when it is effectively void |
| 12:52 | <webben_> | jgraham: I thought a point was made that IE treats void element starting tags as self-closing? |
| 12:53 | <jgraham> | webben_: Maybe I haven't been following too closely. But I don't quite understand what you mean |
| 12:54 | <webben_> | actually, reading it again, I'm not sure what Robert meant |
| 12:54 | <webben_> | http://lists.w3.org/Archives/Public/public-html/2008Aug/0935.html |
| 12:54 | <webben_> | "IE treats unknown elements as void elements (adding the next element |
| 12:54 | <webben_> | as a next sibling)" |
| 12:55 | <webben_> | i'm not sure what that means in terms of how IE treats tags |
| 13:02 | <robburns> | hi webben |
| 13:02 | <robburns> | an example |
| 13:02 | <robburns> | <header> |
| 13:02 | <robburns> | some contents |
| 13:02 | <robburns> | </header> |
| 13:02 | <robburns> | In DOM as: |
| 13:02 | <robburns> | html |
| 13:02 | <robburns> | ⋮ |
| 13:02 | <robburns> | header |
| 13:02 | <robburns> | #text: some contents |
| 13:02 | <robburns> | /header |
| 13:02 | <robburns> | Instead of |
| 13:02 | <robburns> | html |
| 13:03 | <robburns> | ⋮ |
| 13:03 | <robburns> | header |
| 13:03 | <robburns> | #text: some contents |
| 13:03 | <robburns> | that's how IE will process an unknown non-void (HTML5 in this case) element |
| 13:03 | <robburns> | webbeb_ |
| 13:06 | <robburns> | but on the other hand in Gecko |
| 13:07 | <robburns> | <p> |
| 13:07 | <robburns> | <eventsource> |
| 13:07 | <robburns> | some contents |
| 13:07 | <robburns> | </p> |
| 13:07 | <robburns> | html |
| 13:07 | <robburns> | ⋮ |
| 13:07 | <robburns> | p |
| 13:07 | <robburns> | eventsource |
| 13:07 | <robburns> | #text: contents |
| 13:07 | <robburns> | instead of html |
| 13:07 | <robburns> | ⋮ |
| 13:07 | <robburns> | p |
| 13:07 | <robburns> | eventsource |
| 13:07 | <robburns> | #text: contents |
| 13:09 | <Philip`> | (Actually it'd be called HEADER and /HEADER, not header and /header) |
| 13:09 | <Philip`> | (Wait, am I confused?) |
| 13:10 | <Philip`> | (At least I think IE does something funny with the case of unrecognised tags) |
| 13:10 | <robburns> | though in Firefox 3, the P element does not get implicitly closed (I think earlier versions would) |
| 13:10 | <robburns> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%0A%3Ceventsource%3E%0Acontent%0A%3C%2Fp%3E |
| 13:10 | <Philip`> | (Ah, right, it's if you do document.createElement('header') then the element is called "header" instead of "HEADER") |
| 13:12 | <robburns> | That's with the DOM, but with deserializing tex/thml 'header' will be 'HEADER', but it will be a void element followed by '/HEADER' (another void element) |
| 13:12 | <robburns> | in IE that is |
| 13:13 | <robburns> | s/ text/html / tex/thml |
| 13:14 | <Philip`> | It's not just for elements created by the DOM APIs: if you write <script>document.createElement('header')</script> then any subsequent <header>...</header> in the HTML markup will be treated as an element named 'header' with content, rather than as empty 'HEADER' + content + empty '/HEADER', because IE is insane |
| 13:14 | <Philip`> | but that's not particularly relevant to the point anyway |
| 13:35 | gsnedders | says hi to all the bureaucracy trolls |
| 13:47 | jgraham | wonders if that is supposed to include him |
| 13:49 | jgraham | doesn't see himself as trolling |
| 13:50 | <jgraham> | Since AFAICT the charter is designed to prevent exactly this |
| 13:50 | <Lachy> | jgraham, I disagree. We shouldn't let the limitations of tools like XSLT that clearly weren't designed to handle HTML well guide the development of HTML5. |
| 13:51 | <Lachy> | also, allowing </foo> for new void elements, but not for previously existing void elements makes things inconsistent. |
| 13:52 | <jgraham> | Lachy: I agree about the inconsistent part but that seems to have been a weak argument elsewhere (I think <a> enclosing blocks is a bad idea because it introduces inconsistencies) |
| 13:52 | <jgraham> | If the problem is XSLT-only it's not worth worrying about |
| 13:53 | <jgraham> | But if it is more general, it seems bad to couple the serializer to the version of the language being output |
| 13:54 | <jgraham> | because it makes migration hard |
| 13:54 | <jgraham> | anyway I don't care very much |
| 13:57 | <Lachy> | so far, the problem is XSLT only. No other tool has been mentioned with the problem |
| 13:58 | <Lachy> | and I just don't want XSLT to have any impact on the development of HTML5 |
| 13:59 | <webben_> | I think the key thing is to ensure that XML output by XSLT can be translated with FOSS tools to text/html HTML5. |
| 14:00 | <webben_> | what I'm not sure about is what a tool is supposed to do if it gets XML that can't be translated to text/html HTML5. |
| 14:01 | <webben_> | e.g. <p>foo<blockquote><p>bar</p></blockquote></p> |
| 14:07 | <gsnedders> | webben_: It should do a backflip? |
| 14:07 | <gsnedders> | webben_: I mean, we already require UAs to take a deep breath in a certain case when parsing HTML |
| 14:07 | <Lachy> | webben_, you just have to accept that not all possible XML trees can be losslessly converted to HTML |
| 14:08 | <Lachy> | webben_, especially in cases like that which are invalid in XHTML too |
| 14:10 | <Lachy> | webben, incase you missed my messages just then due to connection issues, http://krijnhoetmer.nl/irc-logs/whatwg/20080831#l-149 |
| 14:10 | <webben> | ta Lachy :) |
| 14:11 | <webben> | well, in this case, it's lossy because no feature has been provided to make it unlossy, not because of some sort of fundamental lack in text/html. |
| 14:12 | <webben> | but the worry is not just that it's lossy, but that such a tool would properly want to handle it somehow |
| 14:12 | <webben> | at which point you end up with differing implementations. |
| 14:12 | <webben> | that's not invalid in XML serialization of HTML5. |
| 14:13 | <Lachy> | it would have to make the blockquote a sibling of the p instead, and possibly create a new p after it |
| 14:13 | <webben> | it could do that. it wouldn't _have_ to. |
| 14:13 | <Lachy> | so <p>foo<blockquote>bar</blockquote>baz</p> would become <p>foo</p><blockquote>bar</blockquote><p>baz</p> |
| 14:13 | <webben> | another approach, for example, would be to go lossy in a different manner |
| 14:13 | <webben> | by genericising the p to a div. |
| 14:14 | <webben> | or processing agents could attach a class to the second p in an attempt to indicate what's happened. |
| 14:14 | <Lachy> | so it would become this instead? <div>foo<blockquote>bar</blockquote>baz</div> |
| 14:14 | <webben> | could do. |
| 14:15 | <Lachy> | perhaps the right solution is for the tool to check with the user what he wants to do |
| 14:15 | <webben> | that simply passes the problem on |
| 14:16 | <Lachy> | so do you want the spec to define how to serialise it? |
| 14:16 | <webben> | I'd prefer that, yes. |
| 14:16 | <webben> | i'd prefer the spec to define how XML HTML5 should be converted to text/html HTML5. |
| 14:16 | <gsnedders> | and the other way too |
| 14:16 | <webben> | yep |
| 14:17 | <Philip`> | webben: Like http://www.whatwg.org/specs/web-apps/current-work/multipage/serializing.html#serializing ? |
| 14:17 | <gsnedders> | Henri sent something about it a while back |
| 14:17 | <gsnedders> | Like, what he does in the validator |
| 14:17 | Philip` | doesn't know whether that algorithm is inappropriate for this |
| 14:19 | <webben> | that appears to do it. |
| 14:19 | <webben> | I don't like how it does it, but at least it does it. |
| 14:19 | <Lachy> | Philip`, that algorithm in the spec doesn't seem to have any special handling for the case being discussed. AFAICT, it would just output an invalid fragment |
| 14:21 | <webben> | the note says: "having a p element that contains a ul element (as the ul element's start tag would imply the end tag for the p" |
| 14:22 | <Lachy> | but that seems to be what Firefox does anyway |
| 14:22 | <webben> | does the algorithm not match the note? |
| 14:22 | <Lachy> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Avar%20div%20%3D%20document.createElement(%22div%22)%3B%0Avar%20p%20%3D%20document.createElement(%22p%22)%3B%0Avar%20bq%20%3D%20document.createElement(%22blockquote%22)%3B%0Adiv.appendChild(p)%3B%0Ap.appendChild(bq)%3B%0Aw(div.innerHTML)%3B%0A%3C%2Fscript%3E%0A |
| 15:39 | gsnedders | wonders what he's meant to know for physics test tomorrow |
| 16:33 | <Philip`> | gsnedders: Remember that gravity goes downwards |
| 16:33 | <Philip`> | That's probably enough for a few marks |
| 17:20 | <hsivonen> | Hixie: yes, I intend to follow up with more opinion and analysis regarding the validation results |
| 18:22 | <gsnedders> | Philip`: :) |
| 18:22 | <gsnedders> | Philip`: Actually, with what will be in the test, gravity may as well not exist |
| 18:37 | <hsivonen> | Lachy: no, I didn't mean a kernel panic. I meant the screen turning blue with an occasional large instance of the spinning petals at the location where they appear a moment before shutdown |
| 18:38 | <hsivonen> | Lachy: Macs draw a light blue screen when there's nothing drawing the desktop background |
| 18:42 | <hsivonen> | gsnedders: I don't have a mapping from non-conforming application/xhtml+xml onto text/html |
| 18:42 | <gsnedders> | hsivonen: I thought I saw an email from you about that a while ago |
| 18:42 | gsnedders | shrugs |
| 18:43 | <hsivonen> | gsnedders: I have mappings from text/html onto XML, text/html onto Jing compatible XML-violating SAX and conforming application/xhtml+xml onto text/html |
| 18:43 | <hsivonen> | gsnedders: are you sure my email wasn't about going in the other direction than what webben asked about? |
| 18:43 | <gsnedders> | hsivonen: Myself and webben were saying both directions |
| 18:43 | <hsivonen> | ah ok. |
| 18:43 | <gsnedders> | hsivonen: So you have part of that |
| 18:44 | <hsivonen> | I have text/html to XML (covered by spec) and *conforming* application/xhtml+xml to text/html (not covered by the spec) |
| 18:45 | <hsivonen> | I'd love to see a sane and uncontroversial mapping from non-conforming application/xhtml+xml onto text/html |
| 18:52 | <gsnedders> | hsivonen: Where is text/html to XML covered in the spec? |
| 19:03 | <hsivonen> | gsnedders: http://www.whatwg.org/specs/web-apps/current-work/#coercing |
| 19:04 | <gsnedders> | Hixie: typo: mutatiosn |
| 19:10 | <hsivonen> | so now Google is saying Android supports H.264 |
| 19:10 | <hsivonen> | what's the licensing story? |
| 19:51 | <Lachy> | hsivonen, where did you find that Android supports h.264? |
| 19:52 | <hsivonen> | Lachy: http://code.google.com/android/what-is-android.html |
| 19:53 | <Lachy> | Android uses the Apache2 licence |
| 19:53 | <hsivonen> | Lachy: it has patent language |
| 19:53 | <hsivonen> | how does that work with MPEG-LA? |
| 19:54 | <Lachy> | I don't know. What does the apache licence say about patents/ |
| 19:54 | <Lachy> | ? |
| 19:54 | <Dashiva> | It says "based on PacketVideo's OpenCORE" whatever that is |
| 19:55 | <hsivonen> | Lachy: hmm. actually, it only talks about patents that are licensable by a Contributor |
| 19:58 | <Lachy> | it's possible that Andriod could include closed source codecs for h264, and other patent encumbered stuff |
| 20:03 | <gsnedders> | Probably can be disabled in the build, and can be used only by those with licenses |
| 20:15 | <hsivonen> | hmm. the Microsoft EOT marketing partner Ascender made the Droid fonts |
| 20:22 | <hsivonen> | boohoo. Droid isn't Free as in Free Softwarle |
| 20:22 | <hsivonen> | Software even |
| 20:25 | gsnedders | is feeling that Sunday evening feeling: he ought to do homework for tomorrow. |
| 21:13 | <hsivonen> | http://twitter.com/stevefaulkner/statuses/902493395 |
| 21:22 | <othermaciej> | hsivonen: self-fulfilling prophecy! |
| 21:54 | <gsnedders> | Hixie: You have any thoughts on making the spec-gen able to split a spec? |
| 22:00 | gsnedders | blogs http://gsnedders.com/anolis |
| 22:10 | <Philip`> | gsnedders: Why should that be part of the spec-gen, rather than a separate tool? |
| 22:12 | <Philip`> | gsnedders: s/it's/its/ :-p |
| 22:14 | <Philip`> | gsnedders: The filenames ought to say what the file is, rather than just being "1.0RC1.tar.bz2", else I'll forget what ~/download/1.0RC1.tar.bz2 is and it will annoy me |
| 22:16 | <gsnedders> | Philip`: The alternative is just to call it the revision hash :P |
| 22:17 | <Philip`> | gsnedders: The alternative is to call it anolis-1.0RC1.tar.bz2, and if Mercurial makes that alternative hard then I don't care and it's your problem :-p |
| 22:17 | <gsnedders> | Philip`: :P |
| 22:17 | <Philip`> | You could set up a script that downloads the archive files from Mercurial and renames them and copies them to a proper web server or something |
| 22:18 | gsnedders | is too lazy :P |
| 22:20 | <Philip`> | gsnedders: But you're not too lazy to go to all the effort of having Release Candidates and documentation and everything? :-) |
| 22:21 | <gsnedders> | Philip`: RCs are no effort. `hg tag 1.0RC1` and wait for people to bitch about a bug |
| 22:21 | <gsnedders> | Philip`: It's more a spec of what it does than a doc, covering all minor details, so if you want to copy it you can do it without looking at the code :P |
| 22:22 | Philip` | wonders why anyone would want to do that |
| 22:22 | <gsnedders> | Philip`: Well I did it to the CSS3 Module Postprocessor, didn't I? |
| 22:23 | <Philip`> | gsnedders: As far as I'm aware, you copied it without looking at the code because you couldn't copy its code, which is not a problem anyone would have when wanting to copy your code |
| 22:23 | <gsnedders> | Philip`: I could look at some of the code. |
| 22:24 | <Philip`> | Did you? |
| 22:24 | <gsnedders> | Yes, then couldn't work out how it dealt with some edge cases how it did, so went back to reverse-engineering it |
| 22:24 | <gsnedders> | (the issue really being my knowledge of C) |
| 22:24 | <Philip`> | Oh, okay |
| 22:25 | <Philip`> | I suppose if you don't like reading the code then that'd be a reason to copy it without reading the code |
| 22:26 | <gsnedders> | I could've looked at the C spec, but I thought it'd be just as easy to create a test case :P |
| 22:30 | <Philip`> | I think a book on C would be somewhat more useful than the C spec |
| 22:31 | <Philip`> | (unless you were trying to implement a C compiler yourself) |
| 22:31 | <Philip`> | (which is not entirely recommended) |
| 22:32 | <Philip`> | (and if you were implementing a C compiler, you'd probably want to start with the "how to write a C compiler" book instead of the specification) |
| 22:43 | <jcranmer> | well, it is an ISO spec |
| 22:43 | <jcranmer> | but it's not unreadable |
| 22:44 | <jcranmer> | then again, I *am* the kind of person who finds reading the contractual agreement that comes with your bank account quite fun to read... |
| 22:45 | <hsivonen> | ISO drafting rules suck |
| 22:45 | <hsivonen> | is the C spec available online? |
| 22:45 | <hsivonen> | I'm interested in seeing an ISO spec that is not unreadable |
| 22:46 | hsivonen | googles |
| 22:46 | <jcranmer> | you have to pay for the specs, but any drafts you happen along are free :-) |
| 22:46 | jcranmer | points to the draft C++0x spec sitting on his hard drive |
| 22:47 | <Philip`> | I'd agree it's not unreadable - I've occasionally referred to it when attempting to prove a pedantic point to somebody, and it mostly made sense to me, but it's not so good for someone who doesn't already know C well |
| 22:48 | gsnedders | has a draft C99 |
| 22:48 | <Philip`> | and I don't think I'd be happy with it if I was looking for some higher-level information, since it's just focussed on the details |
| 22:49 | <jcranmer> | you have to know how everything lays out at a high level before you dive into a spe |
| 22:49 | <jcranmer> | spec |
| 22:50 | <hsivonen> | wow. the ISO C spec actually looks more readable than a run-of-the-mill ISO spec |
| 22:51 | <jcranmer> | ISO C++ is fairly approachable, if you use <Ctrl>-F |
| 22:54 | <gsnedders> | Find makes most docs readable |
| 22:54 | <jcranmer> | not the OOXML spec! |
| 22:54 | <Philip`> | Has anybody noticed that while IE's x-ua-compatible at least attempts to support non-IE browsers by allowing strings like "FF=4", its document.documentMode doesn't at all (since it just returns the IE version number)? |
| 22:57 | <hsivonen> | the points made about hyatt's mythicalness are a bit repetitive |
| 22:58 | <Hixie> | hsivonen: the harm language="" brings is that people typo it all the time and it'd be better to have people type type="" instead. |
| 22:58 | <Philip`> | But they seem true |
| 22:58 | <Hixie> | regarding <foo></foo> vs <foo>, because of the parser model the </foo> would not have any effect, but it would mislead people into thinking that <foo>x</foo> was a <foo> containing an x |
| 22:58 | <Hixie> | so it's bad |
| 22:58 | <jcranmer> | you'd be surprised at how bad people are at spelling |
| 22:59 | <hsivonen> | Hixie: the validator helps people spell it right :-) |
| 22:59 | <jcranmer> | I have a nice, phonetic last name and 85+% of people manage to both misspell and mispronounce it... |
| 22:59 | <Hixie> | hsivonen: apparently not enough people :-) |
| 23:00 | <jcranmer> | I figure if people misspell my last name with such frequency, any word greater than about 7 characters will be too long to spell correctly |
| 23:02 | <hsivonen> | Hixie: so if type=text/javascript, language=JavaScript and langauge=JavaScript are no-ops, why is allowing language=JavaScript a problem? |
| 23:03 | <Philip`> | Hixie: If many people were misled that way, wouldn't <embed>x</embed> be much more common than it is? |
| 23:03 | <Philip`> | jcranmer: I've never had such problems with my last name, but I often do with my first name :-( |
| 23:03 | <Hixie> | hsivonen: because people will think language="" isn't a no-op, and attempt to include on other pages, and will mistype it, leading to validation errors and wasted time. |
| 23:04 | <Hixie> | Philip`: </embed> is pretty damn common. i haven't checked to see how many </embed>s aren't immediately behind the <embed> they supposedly match. |
| 23:05 | <Philip`> | More than the number of people who already use language correctly, and would get validation errors when switching to HTML5, and would waste time? |
| 23:05 | <Philip`> | Hixie: I've only seen ones containing whitespace, , <br>, etc, and <noembed> |
| 23:05 | jcranmer | notes that hsivonen himself (herself?) misspelled 'language' |
| 23:06 | <hsivonen> | jcranmer: I misspelled it once on purpose above |
| 23:06 | <Hixie> | Philip`: i think we need a better transition story |
| 23:06 | <hsivonen> | jcranmer: did I misspell it also accidentally? |
| 23:06 | <jcranmer> | if you did it on purpose, then no |
| 23:06 | <hsivonen> | Hixie: why isn't type=text/javascript non-conforming? |
| 23:07 | <Hixie> | hsivonen: because we need to have a type="" to handle other types of scripts, and if we don't have a type for javascript, people will ask what the type is for javascript. |
| 23:08 | <Hixie> | brb |
| 23:19 | <Philip`> | Hmm, I think IE8b2 never renders pages in IE7-mode unless explicitly told to, regardless of doctype |
| 23:20 | <Philip`> | i.e. pages that used to be quirks mode are IE5-mode, and pages that used to be standards mode are IE8-mode |
| 23:20 | <gsnedders> | That's what IE8b1 did :P |
| 23:21 | <Philip`> | I thought it made recognised standards-mode doctypes trigger IE7 mode |
| 23:21 | <Philip`> | Wait, I'm probably confused |
| 23:21 | <Philip`> | That's what it was going to do before they changed it |
| 23:21 | <Philip`> | I think |
| 23:22 | <gsnedders> | They changed it before b1 |
| 23:24 | <Philip`> | Hmm... If I have a standards-mode page with an iframe with quirks-mode content, then document.querySelector === undefined from code within it; but iframe.contentWindow.document.querySelector == some function from the container document |
| 23:25 | <gsnedders> | heh |
| 23:30 | <roc> | yeah |
| 23:30 | <roc> | it's a very deep hole the IE team is digging |
| 23:31 | <gsnedders> | roc: What's the escape velocity? |
| 23:31 | <roc> | and the really bad news is that with every release it will get a lot worse |
| 23:32 | <roc> | there is no escape :-) |
| 23:32 | <gsnedders> | So above 3*10^8? |
| 23:32 | <gsnedders> | (ms^{-1}) |
| 23:32 | <roc> | there's always Hawking raditation |
| 23:32 | <roc> | but that's not a fun way to travel |
| 23:33 | <gsnedders> | Hawking radiation? |
| 23:33 | gsnedders | notes his physics has limits |
| 23:33 | <roc> | so does mine, so I refer you to the Internet |
| 23:34 | <gsnedders> | What's that? |
| 23:34 | <Philip`> | It's fun how IE8's script debugger shows that element collection objects have properties named "length" and "ie8_length" |
| 23:34 | <Philip`> | and some other type of object has properties "item", "namedItem", "ie8_item" and "ie8_namedItem" |
| 23:35 | <roc> | heh |
| 23:35 | <Philip`> | Hawking radiation = matter/antimatter pair randomly springs into existence near a black hole, antimatter particle falls in, matter particle falls out, black hole radiates and shrinks, if I remember correctly |
| 23:36 | <Philip`> | Please don't ask me why it's the antimatter particle and not the matter particle that falls into the black hole |
| 23:39 | <gsnedders> | why is it the antimatter particle and not the matter particle that falls into the black hole? |
| 23:40 | <Dashiva> | If only Philip` had used RDFa in his IRC text, we could make a machine reason out the answer for us |
| 23:40 | <Philip`> | Hmm, Wikipedia effectively says it's to conserve energy |
| 23:41 | <Philip`> | (i.e. if the antiparticle (apparently not actually antimatter) with negative energy escapes from the hole, then it violates conservation of energy, for some reason) |
| 23:44 | <annevk2> | gsnedders, I commented on your blog, not sure it had effect |
| 23:49 | jgraham | has notion that the particle/antiparticle thing is a ort of lie to children |
| 23:49 | <Philip`> | By "children" you mean "physics undergraduates"? ;-) |
| 23:49 | <BenMillard> | jgraham, I see the headers thread continued along the lines of Process instead of facts |
| 23:56 | <jgraham> | BenMillard: Yeah. It has become quite soul destroying. This may be partially my fault, I don't know. |
| 23:57 | <jgraham> | Philip`: Well I actually meant "people who read popular science books". Physics undergrads don't learn about hawking radiation |