| 00:10 | <Philip`> | "insert the clone into the stack of open elements immediately after (i.e. in a more deeply nested position than) the position of the furthest block in that stack." |
| 00:10 | <Philip`> | Hmm, I think I read that bit backwards |
| 00:11 | Philip` | really doesn't like the terminology for list/stack positions in here :-( |
| 00:11 | <Philip`> | (particularly since my implementation stores all the lists backwards) |
| 01:04 | <Lachy> | othermaciej, which particular comment were you referring to about preflighting a selector? |
| 01:04 | <othermaciej> | Lachy: I wasn't referring to a particular comment |
| 01:04 | <othermaciej> | or rather, I was referring to a comment that weinig (who worked on our selectors API stuff some) made privately to me |
| 01:04 | <Lachy> | oh, but you said "I think his particular comment..." |
| 01:05 | <Lachy> | ok |
| 01:07 | <Lachy> | othermaciej, I'm not quite sure I understand what the comment means though. Are you saying the exception are a good thing for web developers or not? |
| 01:08 | <othermaciej> | Lachy: his particular hypothetical comment that he would have made |
| 01:09 | <Lachy> | what? |
| 01:09 | Lachy | is confused |
| 01:10 | <Lachy> | probably because I'm tired |
| 01:13 | <Lachy> | oh, I think I understand now after reading the comments properly |
| 01:14 | <othermaciej> | sorry |
| 01:14 | <othermaciej> | to try to be totally clear: |
| 01:14 | <othermaciej> | 1) Someone I work with gave me some feedback privately |
| 01:14 | <othermaciej> | 2) I asked him to send it to the list, but he hasn't yet |
| 01:14 | <othermaciej> | 3) I gave you a general outline of the nature of his comment |
| 01:16 | <Lachy> | it was suggested to me earlier that I remove exceptions, and instead just return an empty list. |
| 01:16 | <Lachy> | but if exceptions are to be used as a way to switch back to a scripted implementation in the event that the browser doesn't support a selector natively, then that's a good reason to keep them |
| 01:18 | <Lachy> | but there will be some changes to the spec in the way non-DOMString return values are handled from NSResolvers. The value will just be stringified, instead of ignored (or whatever the spec says now) |
| 01:18 | <othermaciej> | right, what I was thinking was that a separate call to check if a given query syntax is supported might be a better way to do that |
| 01:18 | <othermaciej> | but not sure |
| 01:20 | <Lachy> | something like document.isSelectorSupported("some %hypothetcial>selector-syntax"); ? |
| 01:22 | <othermaciej> | yeah |
| 01:23 | <Lachy> | maybe that might be better. There are some people who really hate exceptions |
| 01:23 | <othermaciej> | then you could do if (document.isSelectorSupported(sel)) document.querySelector(sel) else { /* implementation in JS */ } |
| 01:23 | <Lachy> | have someone send mail to list about it |
| 01:24 | <Lachy> | we'd probably get people doing this: |
| 01:24 | <Hixie> | it's not really isSelectorSupported() you need |
| 01:25 | <Lachy> | document._querySelector = document.querySelector; document.querySelector = function() { /* custom function that does that check automatically */ } |
| 01:25 | <Hixie> | it's more isSelectorImplementedWithoutBugsAndWithAcceptablePerformance() |
| 01:25 | <Lachy> | :-) |
| 01:26 | <Hixie> | my point being, you can't rely on the client to implement the method usefully |
| 01:26 | <Hixie> | people will end up doing regexps on the argument anyway |
| 01:26 | <Hixie> | to catch the ones they need to support themselves |
| 01:27 | <Lachy> | with some sort of browser sniffing technique? |
| 01:27 | <Hixie> | i'd guess, yes |
| 01:28 | <Lachy> | where they know, for example, the need to always handle foo>bar with custom scripts in IE9, and but let it be handled natively in other browsers ;-) |
| 01:29 | <sayrer> | yeah, this is where the generality of the Selector API can be a problem in practice |
| 01:29 | <Lachy> | maybe authors would start incorporating CSS filters into querySelector calls |
| 01:29 | <sayrer> | getElementsByClassName is dumber, but much easier to check for |
| 01:30 | <othermaciej> | I have to try this benchmark to see how our native impl compares to the JS library versions |
| 01:32 | <othermaciej> | hmm, only an order of magnitude faster than the fastest JS version |
| 01:32 | othermaciej | is a little disappointed |
| 01:33 | <othermaciej> | I bet some common cases (id selectors at least) could be optimized further |
| 01:34 | <Lachy> | how does querySelector("#foo"); compare with getElementById("foo");? |
| 01:35 | <Lachy> | in regards to performance |
| 01:36 | <othermaciej> | it's probably slower |
| 01:36 | <othermaciej> | although it could probably be made practically as fast |
| 01:36 | <Hixie> | i'd be shocked if it was faster |
| 01:36 | <Hixie> | :-P |
| 01:36 | <othermaciej> | it doesn't really need to be slower, at least in the common case where the ID is unique |
| 01:36 | tantek_ | just saw the reference by Lachy to authors possibly using CSS filters in JS, and shuddered. |
| 01:38 | <Lachy> | tantek_, I'm not to happy about it either, but since so many filters are just hacks with selectors, it seems likely |
| 01:38 | <tantek_> | Lachy, filters can't be hacks with selectors. filters are based on including or not an entire stylesheet. |
| 01:40 | <tantek_> | so unless there's a way to use selectors with @import... |
| 01:40 | <Lachy> | tantek_, this list contains many filters that are just using selectors to filter out rules from specific UAs. http://centricle.com/ref/css/filters/ |
| 01:41 | <Lachy> | like: * html { ... } |
| 01:41 | <tantek_> | oh dear - those are not all filters, those are just css hacks, some subset of which are css filters |
| 01:41 | <Lachy> | I've never know the term CSS filters to be restricted to just those that import entire stylesheets or not |
| 01:44 | <tantek_> | Lachy, I introduced the term filter, in the context of CSS, with this page: http://tantek.com/CSS/Examples/highpass.html |
| 01:45 | <Lachy> | IMHO, a filter is just whatever mechanism is used to show or hide specific rules to specific browsers |
| 01:45 | <tantek_> | The whole point of CSS filters, rather than just hacks, is as written there: Using the High Pass Filter, both the actual HTML document and the actual CSS style sheet are kept clean and free of any hacks. The only hack in use, for that matter, is neatly contained in the "filter" style sheet. |
| 01:47 | <Lachy> | tantek_, this is the terminology I use http://lachy.id.au/log/2006/01/csshack - I break down a hack into 3 components: the limitation, the patch and the filter. |
| 01:49 | <tantek_> | yes, clearly the term CSS filter has drifted in the wild from how I first defined it. I'll collect a to-do item to write up a more thorough definition with distinctions. |
| 01:51 | <tantek_> | what you call "filter" in your blog post would be more correctly labeled perhaps the "conditional" |
| 01:51 | <othermaciej> | I'm glad I'm not a web developer |
| 01:52 | <tantek_> | then using that terminology, a CSS filter uses a conditional to pass an entire style sheet to only a subset of all browsers |
| 01:52 | <Lachy> | well, AFAICT, you only defined what "high pass filter" means. You didn't seem to place much restriction on what else could be a filter |
| 01:53 | <othermaciej> | unfortunately what most people need is a low pass filter |
| 01:53 | <othermaciej> | and the cutoff has to be above IE6 (possibly above IE7) |
| 01:53 | <tantek_> | Lachy see the directory of that URL I provided. |
| 01:53 | <tantek_> | e.g. http://tantek.com/CSS/Examples/midpass.html |
| 01:54 | <tantek_> | http://tantek.com/CSS/Examples/ie50winbandpass.html |
| 01:54 | <tantek_> | http://tantek.com/CSS/Examples/ie55winbandpass.html |
| 01:54 | <tantek_> | and finally: http://tantek.com/log/2004/07.html#ie5macbandpass |
| 01:55 | <tantek_> | othermaciej, I haven't designed a midpass filter that works for IE5-6 but given the above you probably could. |
| 01:56 | <Lachy> | <!--[if IE lte 6]--> works well |
| 01:56 | <othermaciej> | seeing hacks like this makes me wonder if maybe Microsoft's versioning thingie might be a good idea |
| 01:57 | <tantek_> | Lachy - conditional comments are proprietary and thus I avoid them. |
| 01:57 | <Lachy> | othermaciej, it's not a good idea, for many reasons |
| 01:57 | <tantek_> | one of the requirements of the CSS hacks I designed is that they are all non-proprietary. another requirement is that they are all valid CSS. |
| 01:57 | <Lachy> | tantek_, I somewhat agree, and I tend to use only a select few hacks that I know will be harmless in the future |
| 01:57 | <tantek_> | and a design preference was that they didn't pollute the markup. |
| 01:58 | <tantek_> | conditional comments violate all those requirements/preferences. |
| 01:58 | <Lachy> | but the advantage of conditional comments is that there slighly more reliable than depending on buggy behaviour in browsers |
| 01:58 | <tantek_> | othermaciej - the versioning thingie will only result in more fragile style sheets |
| 01:58 | <tantek_> | just as javascript that already do UA string versioning are notoriously fragile. |
| 01:59 | <Lachy> | personally, I mostly avoid conditional comments |
| 01:59 | <othermaciej> | I guess the bad thing is not that these css hacks exist at all but that so often you have to use them as a bread and butter part of web design, not just for a few crazy edge cases |
| 02:00 | <othermaciej> | I do really hate when people use CSS hacks that use correct behavior rather than wrong behavior as the trigger |
| 02:00 | <Lachy> | the big problem is that people resort to hacks far too often, instead of just looking for fully conforming alternatives |
| 02:00 | <othermaciej> | for example some sites have Opera-specific CSS (often wrong even for Opera) in @media rules |
| 02:00 | <tantek_> | btw, as written, the ugliness of hacks is a feature, it's meant to make you want to avoid using them, and to have the impulse to clean them up when looking at them in the future. |
| 02:00 | <othermaciej> | which in a few cases broke Safari 3 |
| 02:00 | <tantek_> | othermaciej, strongly agreed. |
| 02:01 | <Lachy> | the ugliness isn't really a deterrent |
| 02:01 | <tantek_> | it's not supposed to be a deterrent, it's just supposed to be a reminder that something isn't quite right |
| 02:01 | <othermaciej> | so I wish there was a general principle of "don't target a bug workaround with a trigger of correctness" |
| 02:01 | <Lachy> | most people aren't perfectionists and end up with messy code with or without hacks |
| 02:01 | <othermaciej> | although targetting a bug workaround with another bug as a trigger can also be bad |
| 02:01 | <othermaciej> | but at least it mostly sucks for the engine that had the bugs |
| 02:02 | <tantek_> | Lachy, it's not a 100% people solution for sure, but as long as at least *some* people see hacks as ugly last resorts and things to be cleaned up, hacks are better than formal methods for solving these sorts of problems. |
| 02:02 | <Lachy> | the only bugs that are really safe to depend on are bugs in obsolete versions of browsers that have been fixed in the latest version. So * html is safe for IE6, since IE7 fixed it |
| 02:02 | <tantek_> | othermaciej, precisely, the guilty are punished. |
| 02:03 | <Lachy> | tantek_, the guilty browser vendor may be punished, but they just pass their punishment onto the web developers (like MS is doing with X-UA-Compaible) |
| 02:04 | <tantek_> | Lachy, I'm not convinced that battle is over yet. |
| 02:04 | <Lachy> | do you think there's a chance to get MS to reverse their decision, or at least make it less harmful somehow? |
| 02:10 | <tantek_> | I'm hoping/fighting for fixing default behavior |
| 02:11 | <Lachy> | I've been fighting for that since I first heard about this decision 9 months ago |
| 02:38 | <othermaciej> | I doubt MS will back off |
| 02:38 | <othermaciej> | besides dominant (but shrinking) market share, compatibility with existing content (public or not) is their biggest competitive advantage |
| 02:39 | <Lachy> | it certainly seems unlikely. The best I think we can hopeful is that his will be the last version requiring an opt-in |
| 02:39 | <Lachy> | s/hopeful/hope for/ |
| 02:39 | <Lachy> | s/that his/that this/ |
| 02:40 | Lachy | is really tired. But have stuff to finish before going to bed |
| 02:40 | <othermaciej> | when other browser vendors complain about it, they probably feel the same way I do when Microsoft folks say "let's not compete on standards, let's just all agree which ones we will support and not do any more" or Mozilla folks say "let's not compete on performance by posting public benchmark results" |
| 02:41 | <Lachy> | benchmark results are useful. All browsers need to remain fast and not use too much memory |
| 02:41 | <Lachy> | Firefox is guilty of being slow and using too much memory |
| 02:43 | <othermaciej> | web compatibility (and even intranet compatibility) is also useful |
| 02:43 | <othermaciej> | but I think the playing field to compete in that space is less level |
| 02:44 | <othermaciej> | web standards and performance metrics are clearly and objectively documented, so even a fairly new entrant to the browser engine market can do pretty well pretty quickly |
| 02:44 | <Lachy> | web compatibility is more important than intranet compat though. But I think MS are trying to treat them equally |
| 03:01 | <gavins> | othermaciej: which mozilla folks have said that? |
| 03:02 | <othermaciej> | gavin_: these were generally private requests from various Mozilla folks to various Apple and non-Apple WebKit contributors, so perhaps it was unfair of me to call it out |
| 03:04 | <gavin_> | I think it's more unfair to call them out and then say that they were private requests when asked for evidence :) |
| 03:04 | <gavin_> | not that I think you're lying, but I think it may be a bit of a mischaracterization if you try to apply it generally to "Mozilla" |
| 03:06 | <gavin_> | it's certainly doesn't reflect the viewpoints I've seen in the mozilla community, anyhow. perhaps I'm being a bit oversensitive :) |
| 03:10 | <othermaciej> | gavin_: I feel conflicted because: |
| 03:10 | <othermaciej> | a) I would feel bad revealing the contents of private communications |
| 03:11 | <othermaciej> | b) I probably shouldn't say things like that and not back it up |
| 03:11 | <gavin_> | sure, I understand |
| 03:11 | <othermaciej> | c) I'm not sure it's fair to let people make requests like that and not even mention that they did so |
| 03:12 | <gavin_> | I think it's probably unfair to mention it without proper context |
| 03:12 | <othermaciej> | however some WebKit contributors have avoided posting cross-browser benchmark results publicly as a result of requests along these lines |
| 03:13 | <othermaciej> | I'm sure some Mozilla folks (like John Resig say) would not agree with this point of view |
| 03:13 | <gavin_> | I mean, it seems like that was your boiled-down takeaway from the message you got |
| 03:13 | <gavin_> | but perhaps that wasn't the intent of the message |
| 03:14 | <alp> | gavin_: as a non-apple webkit contributor i can confirm what othermaciej is saying. no judgement on whether it's a good policy to keep benchmarks quiet or not, but i've respected their wishes |
| 03:14 | <othermaciej> | since he does post benchmark results, sometimes even cross-browser ones |
| 03:15 | <gavin_> | I've never heard any mozilla folks say that they browser competition is bad, or that benchmark results should be hidden, so it surprised me, is all |
| 03:15 | <gavin_> | now, I've heard a lot say that you have to be careful with how you interpret benchmarks, and you need to know what you're measuring |
| 03:16 | <gavin_> | because there are so many bogus benchmarks out there that don't represent useful metrics |
| 03:16 | <gavin_> | but that's a different problem |
| 03:16 | <othermaciej> | I've certainly seen a lot of badly designed benchmarks |
| 03:18 | <othermaciej> | I think that in any case Apple Marketing will continue to post competitive benchmark results, though on the WebKit blog we've been noting version-to-version improvements more than cross-browser comparisons |
| 03:18 | <othermaciej> | I think competition is healthy and I like (reasonably well-deisgned) benchmarks and standards compliance challenges like the acid tests |
| 03:19 | <othermaciej> | I should probably blog about it |
| 03:31 | <roc> | that all sounds rather odd. if I knew who was responsible, I'd yell at them |
| 03:35 | <alp> | the guy who asked for benchmarks to be kept quiet is a mozilla hacker i respect quite much. hope there's no yelling, just constructive discussion |
| 03:37 | <othermaciej> | the (totally separate) requests I've personally gotten along these lines were also from people I very much respect |
| 09:41 | <Lachy> | Yay! Now new iPhone with version 1.1.3 can be unlocked! Now I can finally get myself one :-) |
| 09:46 | <jgraham_> | Lachy: You're in a channel full of Apple employees. If you go around saying things like that then one day soon you'll get an unexpected knock at the door. When you open it there'll be no one there, and you'll just have time to notice a car you've never seen with a single passenger wearing what appears to be a black polo neck before everything goes dark |
| 09:47 | <Lachy> | yeah, well, all the apple employees here can pass my feedback on to management that locking iPhones to specific networks sucks. |
| 09:48 | <Lachy> | I'd be willing to pay a higher price for legitimately unlocked phone, but since Apple won't play nice, that's their problem |
| 09:49 | <hsivonen> | I find it weird that parts of U.S. press are praising iPhone as loosening the network operator grip on product design when from a Finnish (or Norwegian point of view I suppose) the iPhone looks like the posterchild of American mobile lock-in |
| 09:49 | <hsivonen> | Finnish point of view that is |
| 09:50 | <jgraham_> | I'm not sure that it really is their problem if you're prepared to buy it anyway |
| 09:51 | <Lachy> | jgraham_, Apple loses out on the extra income from the AT&T deal |
| 09:52 | <annevk> | jgraham_, agreed |
| 09:53 | <jgraham_> | Yeah, but if you buy the phone anyway you're more likely to keep buying iPhones in the future to have access to exactly the same features (some of which, presumably, are patented) |
| 09:54 | <Lachy> | jgraham_, that's fine I support all of Apple's good decisions, but I stop short of consenting to bad deals |
| 09:57 | <jgraham_> | Well I guess you have to run the risk that at some point in the future your iPhone dies, you want to replace it, and there is no hackable version available. |
| 09:58 | <Lachy> | Weighing up the risk of losing the iPhone and not having it covered by warrenty, compared with not having an iPhone at all? That's an easy decision |
| 09:59 | <hsivonen> | the U.S. really needs stronger telco regulation |
| 09:59 | <hsivonen> | for making sure that carriers are reduced to agnostic bit pipes that don't interfere with content choice or product design |
| 09:59 | <jgraham_> | hsivonen: But don't you know that regulation hurts competition and is for evil communists!?!</slashdot> |
| 10:01 | <hsivonen> | jgraham_: it doesn't take much hanging around with Nokia engineers to figure out that phones would have nicer features if they didn't have to placate to foreign carriers |
| 10:03 | <jgraham_> | (as an aside the reason that I don't have an iPod is lack of support for the music formats I care about.) |
| 10:08 | <othermaciej> | jgraham: engineering is pretty well separated from black ops at Apple |
| 10:09 | <othermaciej> | Lachy: you can pay a higher price to get an unlocked phone from Orange in France, but I dunno if they will ship internationally |
| 10:09 | <othermaciej> | (however it is apparently a ludicrously higher price) |
| 10:10 | <jgraham_> | hsivonen: Oh and I should say that _I_ agree with you about the regulation, but I think lots of Americans would disagree :) |
| 10:12 | <Lachy> | othermaciej, If I got it there, would it work on non-French networks? |
| 10:13 | <Lachy> | and I also agree about the ludicrously high price |
| 10:13 | <othermaciej> | Lachy: it's unlocked - I assume it would work with any SIM card |
| 10:13 | <othermaciej> | (it would have to be a GSM network I guess) |
| 10:14 | <Lachy> | someone told me there are different types of unlocking. That while it may be unlocked from a specific network, it can still be locked to a country. But I don't know how reliable that information is |
| 10:15 | <Lachy> | I just need to find someone in the USA who'd be willing to buy it and ship it to me as a gift |
| 10:15 | <othermaciej> | oh, I wouldn't know |
| 10:15 | <Lachy> | that way, I avoid the ludicrous 24% norwegian import tax |
| 10:15 | <hsivonen> | othermaciej: IIRC, at least either of the "unlocked" German or French versions were locked to the country |
| 10:15 | <hsivonen> | reportedly |
| 10:15 | <othermaciej> | I did not know country locking was possible |
| 10:16 | <Lachy> | nor did I until I was told that. I was prepared to pay the higher price to get one there initially, till I heard about the country lock |
| 10:17 | <virtuelv> | Lachy: or you can wait until it arrives in france, where locking is illegal |
| 10:17 | <Lachy> | virtuelv, read previous comments about country locking |
| 10:18 | <virtuelv> | Lachy: yeah |
| 10:18 | <virtuelv> | or you could buy a phone that grants freedom 0 |
| 10:18 | <hsivonen> | (GSM encryption at least used to be illegal in France) |
| 10:18 | <virtuelv> | Lachy: for reference http://www.gnu.org/philosophy/free-sw.html |
| 10:19 | <hsivonen> | (I don't know if all French-market phones are still defective that way) |
| 10:20 | <othermaciej> | there seems to be some controversy over whether it is in fact country locked |
| 10:21 | <othermaciej> | according to some sources, French law would not even allow a country lock, but the 1.1.2 firmware was buggy |
| 10:23 | <othermaciej> | http://www.ilounge.com/index.php/news/comments/unlocked-iphones-sold-by-orange-not-country-locked/12068 |
| 10:24 | <othermaciej> | (though I think you need a French mailing address, and of course, redonkulous amounts of extra € |
| 10:28 | <Lachy> | the comments on that article suggest otherwise |
| 10:29 | <othermaciej> | yeah, there's other articles that claim it is country-locked with commenters asserting the contrary |
| 10:29 | <othermaciej> | I wouldn't bet either way |
| 10:30 | <Lachy> | I'll play it safe and get a fully locked phone from the US, and then unlock it |
| 11:04 | Philip` | thinks planet.html5.org should redirect to http://www.w3.org/html/planet/ |
| 11:07 | <annevk> | e-mail me, that should be doable :) |
| 13:46 | <Philip`> | #data |
| 13:46 | <Philip`> | <b>Test</i>Test |
| 13:46 | <Philip`> | #document |
| 13:46 | <Philip`> | | <html> |
| 13:46 | <Philip`> | | <head> |
| 13:46 | <Philip`> | | <body> |
| 13:46 | <Philip`> | | <b> |
| 13:46 | <Philip`> | | "TestTest" |
| 13:46 | <Philip`> | Hmm, I don't like that |
| 13:47 | <Philip`> | and I don't know what should happen with <b>Test<script id=s>s=document.getElementById('s');s.parentNode.removeChild(s)</script>Test |
| 13:48 | <Philip`> | (Opera and Safari create two text nodes in both cases; Firefox creates one in the first case, two in the second) |
| 13:49 | <Philip`> | and the spec seems too vague to justify that test case |
| 13:50 | <jgraham> | Presumably the non-script testcase is well defined in the spec? |
| 13:51 | <Philip`> | "When the steps below require the UA to append a character to a node, the UA must collect it and all subsequent consecutive characters that would be appended to that node, and insert one Text node whose data is the concatenation of all those characters." |
| 13:51 | <Philip`> | I don't think it's clear whether that means all character tokens that will ever be appended to that node at any point in the future, or whether it's only consecutive character toke |
| 13:52 | <Philip`> | ...ns |
| 13:52 | <Philip`> | Oh, it already says consecutive |
| 13:52 | <Philip`> | but it still seems unclear |
| 15:26 | Philip` | now passes enough tests that he really needs to add a counter to tell him how many tests he's passing |
| 16:33 | <gsnedders> | <http://developers.slashdot.org/comments.pl?sid=446030&cid=22349930>; |
| 16:42 | Philip` | encounters http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/message/%3C0822044E-EA7B-43C4-A3AF-4196B09B580C%40iki.fi%3E |
| 16:43 | <Philip`> | Now I can pass all of tests1.dat that doesn't match /<(script|style|table|!|textarea|noframes)|<title></i |
| 17:14 | <jgraham> | Sigh |
| 18:59 | kingryan | just noticed that html5 defines rel="contact" in a way that clashes with XFN |
| 19:11 | <Hixie> | kingryan: oops. can you send mail about that? |
| 19:11 | <kingryan> | already did |
| 19:11 | <Hixie> | cool, thanks |
| 19:13 | <Dashiva> | Philip`: Are you the philip that sent a message about text nodes? |
| 19:19 | <jgraham> | Dashiva: Philip` is the Philip who sent a message about text nodes. |
| 19:26 | <Philip`> | Dashiva: I agree with jgraham |
| 19:27 | jgraham | considers that a minor success for the day |
| 19:29 | Philip` | encounters the "Process the token as if the insertion mode was "in body", with the following exception: [...stuff that has a global effect on lots of actions throughout the algorithm and will require quite a few code changes...]" and cries |
| 19:30 | <Dashiva> | I figured I'd mention that all of those cases also trigger the node merging thing for text |
| 19:30 | <jgraham> | Philip`: Yeah, that bit is fun |
| 19:30 | <Dashiva> | I got burned earlier on " </body> </html> " creating three " " nodes inside <body> |
| 19:32 | <jgraham> | (iirc html5lib does some magic replacement of the insertElement method with a different table-specific version at that point. That's no help to you of course...) |
| 19:33 | Philip` | has about 1200 lines of code now, and no mutable state at all |
| 19:35 | jgraham | wonders if he would find functional programming as hard as it sounds |
| 19:36 | <Philip`> | It's not hard at all - it just takes a little while to get used to the different ways of writing things |
| 19:37 | <Philip`> | Oh, except for occasional times when you want to do a simple loop but have to end up with confusing fold_left things instead, and then it's kind of annoyingly hard |
| 19:37 | <jgraham> | :) |
| 19:37 | <jgraham> | (actually I did try some Erlang once but never more than the simplest of toy examples) |
| 19:38 | <Philip`> | OCaml is quite nice since you can still write imperative code and mutable variables when you really want to |
| 19:44 | <Dashiva> | I always worry about the implementation efficiency when I don't know what it's going to do |
| 19:48 | <Philip`> | OCaml isn't crazy like Haskell (with lazy evaluation and stuff), so it's easy to see what it's going to do :-) |
| 20:28 | jwalden | grumbles at random advocacy in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-February/013881.html |
| 20:29 | <jwalden> | and I even agree with the sentiments! |
| 20:31 | <Dashiva> | And to an Opera employee no less :) |
| 20:33 | jwalden | grumbles further about being "forced" to enable email delivery for the list to not miss stuff on it |
| 20:42 | <jwalden> | I have a feeling I'm going to have more hacking to do on postMessage in the very near future :-\ |
| 20:44 | jwalden | wonders how he's going to respond to a message he never received without destroying threading |
| 20:48 | <Hixie> | Philip`: the <table> disaster sentence isn't as bad as it sounds |
| 20:49 | <Hixie> | Philip`: iirc i implemented it in about 5 lines of code -- i just made the function that implements the appending of nodes be a function pointer and swapped in the new function at the right time, or something |
| 20:55 | <jwalden> | could someone forward <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-February/013886.html>; to me as an attachment, so I can (hopefully) not break threading when I add my thoughts to the thread? email is jwalden+whatwg⊙me |
| 20:56 | <Lachy> | jwalden, download the mbox file http://lists.whatwg.org/pipermail/whatwg-whatwg.org/ |
| 20:56 | <jwalden> | ooh |
| 20:56 | <jwalden> | Lachy++ |
| 20:56 | jwalden | learns something new every day! |
| 20:56 | <jwalden> | or rather, re-remembers |
| 21:01 | jgraham | wonders if it is obvious that the detail in his email about a simple sign error was as much to convince himself as anything else (though he may still have got it wrong regardless) |
| 21:21 | <hsivonen> | “The sadest thing about "HTML 5" is that it will be impossible to create |
| 21:21 | <hsivonen> | an April fool's joke about HTML this year - they've already done that.” – Jukka K. Korpela in ciwah |
| 21:22 | <Dashiva> | He's talking about XHTML2 using the XHTML1 namespace? ;) |
| 21:23 | <Philip`> | Hixie: I don't have function pointers :-p |
| 21:23 | <hsivonen> | http://groups.google.com/group/comp.infosystems.www.authoring.html/msg/58f3108d5a1b8208 |
| 21:23 | <Hixie> | Philip`: sucks to be you :-P |
| 21:24 | <hsivonen> | I expect ciwah to stay with HTML 4.01 for a long time even after HTML5 is a REC |
| 21:24 | Philip` | wonders if the foster parent element can change during execution of that step |
| 21:24 | <Hixie> | Philip`: the language i used has only function pointers, it doesn't have any other way of referring to functions :-) |
| 21:29 | <SadEagle> | Philip`: weren't you using o'caml? (a * b -> c) ref, no? |
| 21:31 | <SadEagle> | Dashiva: wha? XHTML2 uses the XHTML1 namespace? I guess it's good for my blood pressure that I didn't pay any attention to it.. |
| 21:31 | <gsnedders> | SadEagle: that's the agreement within the XHTML2 WG, though there's been no WD published yet reflecting it |
| 21:31 | <Philip`> | SadEagle: I'm using OCaml purely functionally, so no refs |
| 21:32 | <Philip`> | (because I want to be able to reuse partially-used parser, rather than having to create a new one for every document) |
| 21:32 | <Philip`> | s/parser/parsers/ |
| 21:33 | <Philip`> | The annoying bit is just trying to find all the places where elements might get inserted in a way that might be affected |
| 21:34 | <Philip`> | and that bit probably isn't hard anyway but I can't concentrate now so it's easier just to complain on IRC about it |
| 21:56 | jwalden | finally unmunges mailman's downloadable mboxes enough to get them to work in Thunderbird and when transferred to IMAP |
| 21:56 | <jwalden> | stupid spammers |
| 21:57 | <jwalden> | stupid mailman hackers who think a spammer couldn't trivially write the regexes I wrote |
| 21:59 | <Philip`> | jwalden: If you click the email link at the top of http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-February/013886.html then it looks like it'll set the In-Reply-To header correctly |
| 21:59 | <jwalden> | sigh |
| 21:59 | <gsnedders> | jwalden: spammers are lazy. |
| 22:00 | <jwalden> | mailman is common; I very much doubt none have done what I did |
| 22:00 | <jwalden> | there's big win to doing it |
| 22:00 | <jwalden> | it's a very common output format |
| 22:06 | <Philip`> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http%3A%2F%2Fphilip.html5.org%2Fmisc%2Fstyle-in-table.html |
| 22:06 | <Philip`> | Shouldn't the <style> be outside the <table>? |
| 22:07 | <Philip`> | (http://parsetree.validator.nu/?doc=http%3A%2F%2Fphilip.html5.org%2Fmisc%2Fstyle-in-table.html&submit=Print+Tree agrees with html5lib) |
| 22:49 | <aroben> | Hixie: do you have any data re: the proportion of web servers that only support HTTP/1.0? |
| 22:49 | <Hixie> | no |
| 22:49 | <aroben> | Hixie: ok, thanks |
| 22:49 | <Hixie> | netcraft might |
| 22:49 | aroben | looks |