00:00 | <kig> | the solution to all problems is to plaster over the crackrock that the world gives |
00:01 | <kig> | css differences between browsers? roll your own css with js and position:absolute |
00:01 | <Philip`> | Has anybody written a JS interpreter in pure JS? |
00:01 | <kig> | i wish |
00:02 | <kig> | would settle for a js-to-browser-js -compiler too |
00:02 | <webben_> | I thought someone had. |
00:02 | <Philip`> | There's Narcissus but I think that requires some SpiderMonkey extensions |
00:02 | <webben_> | But maybe that's a false memory. |
00:02 | <Philip`> | http://lxr.mozilla.org/mozilla/source/js/narcissus/jsparse.js etc |
00:02 | <Lachy> | it'd cool if someone wrote a JS interpeter in LOLCode, and then ran that in the LOLCode interpreter that's written in JS :-) |
00:03 | <Philip`> | __defineProperty__? What does that do? |
00:04 | <jgraham> | If you wrote a js interpreter in python you could compile it to js PyPy, the python interpreter written in python... |
00:04 | <Philip`> | http://www.nabble.com/__defineProperty__-by-default-in-SpiderMonkey-td2853378.html - oh, it's only there if you #define NARCISSUS, which is cheating |
00:11 | <Philip`> | There is (or used to be) a JS code-generating backend for Pugs (the Perl 6 compiler written in Haskell) |
00:11 | <Philip`> | but "hello world" was about 1MB of JS, and it didn't work in any browser :-( |
00:14 | Philip` | is reminded that he really needs to finish his JS HTML5 parser |
00:15 | <Philip`> | (Actually I need the Perl one more than JS, but the JS one is more fun) |
00:52 | <Philip`> | Is IDL "float" 32-bit or 64-bit? |
00:59 | <jwalden> | 32-bit |
00:59 | <jwalden> | can you guess why it's called 'double'? ;-) |
00:59 | <Philip`> | Ah, thanks |
01:00 | <Philip`> | I couldn't find anything in HTML5 using 'double', so it was possible that 'float' was just referring generically to a large floating point type :-) |
01:11 | Philip` | wonders if he should send comments to public-html in attempt to increase the SNR |
01:11 | <Philip`> | s/ / an / |
01:11 | <jwalden> | Philip`: well, in that matter, it might just be generic -- just note that JS numbers are traditional doubles |
01:20 | <Philip`> | jwalden: I guess it doesn't matter much for the case I was looking at, since it all gets converted to 16.16 fixed-point anyway |
01:20 | <jwalden> | heh, no :-) |
01:23 | Philip` | wonders who thought 64K coordinate space units would be enough for anyone |
01:46 | <Hixie> | jwalden: oops, fixed. i changed the text in instructions.inc and forgot to update the test. |
01:47 | <jwalden> | Hixie: incidentally, I don't hugely care any more for 31/32 now that you've made them reset and Firefox passes, but -- I can't help wondering how you're reading the HTML DOM spec to allow click() to work on type="text"; I just don't see it |
01:47 | <jwalden> | it seems clear-cut to me that it only works on the specific enumerated types |
01:48 | <Hixie> | the spec says "Simulate a mouse-click. For INPUT elements whose type attribute has one of the following values: "button", "checkbox", "radio", "reset", or "submit".". |
01:48 | <Hixie> | the first sentence is an imperative statement saying what the UA must do if the method is invoked |
01:48 | <Hixie> | the second sentence is an informative statement of intent. |
01:48 | <jwalden> | shudder |
01:48 | <jwalden> | but I guess I can see |
01:49 | <jwalden> | I'm sure if you'd written it this wouldn't be anywhere close to ambiguous :-) |
01:51 | Philip` | would still suggest reviewing the spec for ambiguity rather than assuming Hixie is perfect :-) |
01:51 | <Hixie> | yeah well |
01:51 | <Hixie> | that spec has issues |
01:51 | <Hixie> | Philip`: indeed! |
01:52 | <jwalden> | oh, certainly :-) |
01:52 | <Hixie> | good lord, this xhtml nonsense is getting out of hand |
01:52 | <jwalden> | I think I've referred to specs more in the last week than in the entire last month |
01:53 | <Hixie> | heh |
03:28 | <Hixie> | seems you can crash Safari by doing a shadowBlur that's more than about 10000px. |
03:54 | <jwalden> | fun |
08:54 | <Philip`> | Hixie: When implementing shadows for FF, I just clamped shadowBlur to 2000 (i.e. about 600 pixels radius) since that seemed a sensible way to avoid using gigabytes of memory for a large blur |
09:52 | <zcorpan> | http://www.ytqm.org/2008/01/16/whatyouseeiswhatthefuck/ |
09:55 | <hsivonen> | zcorpan: redirects me to an anti-spyware scam |
09:55 | <Lachy> | hsivonen, doesn't do that for me |
09:56 | <Lachy> | hsivonen, the page contains this comic strip http://www.userfriendly.org/cartoons/archives/07jul/uf010526.gif |
09:57 | <zcorpan> | and, translated text equivalent underneath the image... try this one http://translate.google.com/translate?u=http%3A%2F%2Fwww.ytqm.org%2F2008%2F01%2F16%2Fwhatyouseeiswhatthefuck%2F |
09:59 | <hsivonen> | that one shows a NSFW penis enlargement ad |
09:59 | <hsivonen> | clearly a quality site |
09:59 | <zcorpan> | lol |
10:04 | <virtuelv> | hehe |
10:05 | <zcorpan> | Hixie: hmm, in test 10 you test that Attr nodes have child nodes. that's something i'd like to change in the dom spec actually |
10:06 | <Hixie> | isn't it interoperably implemented already? |
10:06 | <zcorpan> | not in opera |
10:06 | <zcorpan> | or ie |
10:08 | <hsivonen> | what's the point of attribute nodes? |
10:08 | <annevk> | it's for entityreference nodes |
10:08 | <annevk> | which must die |
10:08 | <zcorpan> | hsivonen: more to the point, what's the point of attribute nodes having its value duplicated as a child text node? |
10:59 | <hsivonen> | mpt: Coming up with a correct positive wording for "Don't override." is hard |
11:00 | <hsivonen> | mpt: Since the positive wording would be along the lines of "Use encoding info from transfer protocol or the document." |
11:00 | <hsivonen> | which is long |
11:00 | <mpt> | "As set by the server/page"? |
11:01 | <hsivonen> | ok |
11:01 | <hsivonen> | thanks |
11:01 | <mpt> | yw |
12:22 | <zcorpan> | Hixie: in order to allow us to fix <link> ignoring content-type in a way that doesn't introduce more differences between quirks and non-quirks, could you perhaps change the test to use image/gif or something instead of text/html? |
14:37 | <hsivonen> | which one is worse: cloning a lot of DOM text nodes or concatenating as many JS strings? |
14:38 | <hsivonen> | say I have 1500 DOM strings that I want to copy into a text area |
14:38 | <hsivonen> | should I build a concatenation of the strings and put it into the text area |
14:38 | <hsivonen> | or insert each string without modification as a text node of its own into the textarea? |
14:42 | <gavin> | by "1500 DOM strings" do you mean "1500 DOM text nodes"? |
14:43 | <gavin> | my gut feeling is that the JS string concatenation approach would perform better than any kind of DOM manipulation |
14:45 | <gavin> | assuming you mean something like |for each (textnode in nodes) total += textnode.textContent; textarea.value = total;| vs. |for each (textnode in nodes) textarea.appendChild(textnode.cloneNode());| |
14:46 | <zcorpan> | hsivonen: iirc, string concatenation is horrobly slow in ie; it's at least an order of magnitude faster to append the strings to an array and then do .join('') |
14:46 | <zcorpan> | i don't know about cloning though |
14:47 | <zcorpan> | s/horrobly/horribly/ |
14:47 | <hsivonen> | gavin: yes, I mean 1500 DOM text node and total += textnode.textContent |
14:47 | <hsivonen> | zcorpan: ok. |
14:48 | <hsivonen> | thanks. I guess this means that I should collect the strings in an array and then join |
14:48 | <zcorpan> | i think you also need to set .value instead of inserting child nodes for compat with ... ie i think |
14:48 | <gavin> | yeah, there was a mozilla bug about improving that kind of JS string concatenation |
14:48 | <gavin> | iincluding workarounds just like zcorpan mentioned |
14:50 | <gavin> | https://bugzilla.mozilla.org/show_bug.cgi?id=56940#c14 |
14:50 | <hsivonen> | thanks |
14:51 | <hsivonen> | I hope textContent is smart about the single text child case |