2011-08-01 [18:52:00.0000] /me is annoyed at the new "ayg⊙an via gmail.com", although of course other mail clients would have been saying something like that forever [18:54:00.0000] Maybe I should just switch all my e-mail over to the ayg⊙an Google account from Simetrical⊙gc? Probably by setting up the former to read all the latter's contents via IMAP? [18:54:01.0000] /me wonders if that would be possible and how long it would take, or if there's a better way [19:23:00.0000] heycam: where you moving to? [19:26:00.0000] oh, Melbourne, I gues [19:51:00.0000] MikeSmith, yep [19:51:01.0000] cool [19:51:02.0000] I just got back yesterday from a visit to Perth [19:52:00.0000] surprised how expensive things are there [19:52:01.0000] oh yeah, all the increased wealth over there from the mining boom [20:54:00.0000] anybody from Mozilla? [20:54:01.0000] i have bug [20:55:00.0000] also miketaylr [20:55:01.0000] in last opera window.onerror is fake event [20:55:02.0000] bga_: orly [20:55:03.0000] never fires [20:56:00.0000] i thought we didn't support window.onerror [20:56:01.0000] but [20:56:02.0000] 'onerror' in window // true! [20:56:03.0000] plz remove [20:56:04.0000] oh, hmm [20:56:05.0000] if not support [20:56:06.0000] ok, i'll file a bug if that's the case [20:56:07.0000] thx :) [20:57:00.0000] np [21:07:00.0000] miketaylr and opera is one browser which correctly parse { if(foo) _a() else _b() } :) [21:07:01.0000] other wants ; [21:07:02.0000] not bug, feature! [21:09:00.0000] :) [21:22:00.0000] bga_: what's your Mozilla bug? [21:23:00.0000] roc window.addEventListener('error', #(e){ _log(e.message, e.fileName, e.lineNumber) }) [21:24:00.0000] or .filename .lineno as in webkit [21:24:01.0000] but in Gecko both - null [21:25:00.0000] file a bug I guess [21:25:01.0000] I don't know [21:25:02.0000] a can get lineNumber only if i attach event via window.onerror = #(message, fileName, lineNumber){} [21:26:00.0000] those are very different [21:31:00.0000] I see that for error events we pass the message, filename and line number as direct parameters to the handler [21:31:01.0000] instead of passing the event object [21:31:02.0000] I don't know why we do that [21:32:00.0000] addEventListener("error", function f(msg, filename, lineno) { ... }, false) should work [21:36:00.0000] typeof(msg) == 'object' because its event object [21:37:00.0000] both filename and lineno are undefined [21:37:01.0000] in 8a1 [21:37:02.0000] the spec says that window.onerror, as well as registering a listener for the error event, is also called for script errors -- and script errors invocations of window.oenrror get called with the three arguments [21:58:00.0000] weird [23:06:00.0000] hi [23:09:00.0000] zcorpan: hello [23:09:01.0000] hello MikeSmith [23:10:00.0000] what happened last month? [23:59:00.0000] someone filed a bug report as a Word document? [00:58:00.0000] Hixie: i don't mind dropping -fallback-to-. most authors use script to implement fallback instead of clever markup" - surely too early to tell? datalist so far has ben implemented in Opera for a while, Chrome recently. So a bit premature to declare the fallback mechanism dead? [06:27:00.0000] And Firefox for a while [06:27:01.0000] Don't forget the best implementation in the world ;) [06:27:02.0000] /me thinks the fallback is a good idea still. Was there some evidence it isn't [06:28:00.0000] The fallback mechanism was mostly designed for a time when browsers were not updated [06:28:01.0000] ? [06:28:02.0000] Well, IE was not updated [06:28:03.0000] That's not evidence it isn't [06:28:04.0000] That changed and scripts became more prevalent to handle fallback in better ways [06:28:05.0000] So these days introducing somewhat cleaner design is feasible [06:29:00.0000] That sounds a bit like "backwards compatibility is hard. Let's not bother" [06:29:01.0000] Or "graceful degradation" if you like [06:29:02.0000] It's more that backwards compatibility is solved in a different way that allows new features to be designed without clutter [06:33:00.0000] What is the clutter in this case? And who does it help if it is already implemented everywhere? [06:34:00.0000] new implementors, people trying to grasp the platform [06:34:01.0000] i value those more than legacy implementations [06:35:00.0000] Is there any evidence that this is actually hard to implement? [06:37:00.0000] it's pretty clear it's more complex [06:37:01.0000] It seems to me that "everything inside datalist is invisible, except the " is beautifully simple, annevk [06:38:00.0000] (even I understand it) [06:38:01.0000] brucel, except that doesn't tell you if you need to traverse children or descendants, whether scripts are executed, whether other descendants are submitted, etc. [06:39:00.0000] brucel: maybe, although i base my judgement on other features where i see most authors use script to implement the fallback behavior [06:40:00.0000] brucel: which makes sense since it's dead simple if somebody else writes the script, e.g. modernizr [06:41:00.0000] jgraham: i recall bratell whining about datalist having to consider all descendants and not just the children [06:42:00.0000] it complicates teh implementation [06:42:01.0000] zcorpan and that's legit - but how big is the amount of evidence at the moment? Basing it on the decisions of a small group of highly-motivated script-savvy early adopters isn't indicative of the majority of authors who, let's face it, won't be figuring this stuff out until IE10 [06:43:00.0000] brucel: the fallback is *for* early adopters. when it's mainstream, you don't bother with fallback at all [06:44:00.0000] if the early adopters don't use the declarative fallback mechanism, it isn't going to do anyone any good [06:47:00.0000] zcorpan I don't understand you, sorry. The fallback, surely, is so IE6,7,8,9 users get an input mechanism more helpful than a plain text input. [06:48:00.0000] i'm saying that pages that use datalist will use a scripted dropdown if datalist is not supported [06:48:01.0000] if (!input.list) { use jquery dropdown and be done with it } [06:51:00.0000] feels to me like losing a useful declarative fallback mechanism in order to make it easier for implementors, because in the short time that it's been supported by majority of browsers, not everyone is using it [06:54:00.0000] yeah [06:55:00.0000] i've been disappointed several times where new features have useful fallback mechanisms but people feature check for the feature instead and fallback to jquery or something with script [06:55:01.0000] brucel: is it really implemented in Chrome ? [06:57:00.0000] Rik Not sure - I meant to type Firefox (and made Ms2ger mad by getting it wrong) [06:57:01.0000] last time I checked, it was broken because the default CSS had "datalist{ display: none;}" [06:57:02.0000] ah, think they removed that [06:58:00.0000] without implementing the feature? [06:58:01.0000] and it's implemented in IE10 although the fallback mechanism is mangled; I reported it to them and was told they were de-mangling that [06:59:00.0000] brucel: I removed that ;) [06:59:01.0000] brucel: mangled how? [06:59:02.0000] zcorpan: yeah, they had flags for implementation but not in the CSS [06:59:03.0000] k [06:59:04.0000] zcorpan - just let me dig out my tests [07:05:00.0000] zcorpan [07:05:01.0000] [07:05:02.0000] [07:05:03.0000] [07:05:04.0000] [07:05:05.0000] .. works fine in IE10 pp1 [07:06:00.0000] .. but Jeremy's example with thing -- as far as i can tell, none of the implementations match the spec or are interoperable with each other, so we don't have enough data to know if the fallback can be used by authors or not [12:28:00.0000] Okay, so I changed the address in my W3C profile thing to ayg⊙an, but public-html thinks I'm not subscribed? [12:29:00.0000] Any further magic I need to do? [12:29:01.0000] /me inquires of MikeSmith [12:30:00.0000] Also, MikeSmith, can I get a Bugzilla component for my editing spec? Specifically, are there going to be any political problems based on the fact that the spec isn't hosted at the W3C that might lead people to agitate that it should be shut down after I've come to start relying on it? [12:30:01.0000] (DOM Range already has one, it's been pointed out) [12:31:00.0000] (did anyone get my public-html message yet? does it have to be approved by moderators or something in addition to me giving permission to post it?) [12:45:00.0000] /me wonders why mailing list archives are not conventionally updated in real time [12:58:00.0000] annevk: can we get an overload for appendChild() that takes a DOMString and creates a text node for you? [12:58:01.0000] That would be cool. [12:58:02.0000] Hixie, I suggest you try to convince implementors directly :) [12:59:00.0000] Although frankly, if we're going to add shortcuts to the DOM methods, we need to go a heck of a lot further than that. [12:59:01.0000] They're a massive headache to use. [13:00:00.0000] As it stands at least they're predictable, so adding a few random shortcuts doesn't seem like it would be a big win. [13:29:00.0000] Agreed with Aryeh on the "let's just sit down and make the entire DOM less sucky". ^_^ [13:30:00.0000] Do you have a concrete proposal? Maybe "clone the most commonly used parts of jQuery"? :) [13:30:01.0000] That would be a good start, certainly. [13:30:02.0000] SVG wants to make a less sucky SVG DOM, so we can coordinate and get everyone together. [13:31:00.0000] SVG has totally different needs. [13:31:01.0000] They need some kind of entirely non-DOM API that translates to DOM stuff. [13:32:00.0000] Likely, yes. [13:32:01.0000] But some things could be fixed, like automatically handling the namespacing hell. [13:32:02.0000] SVG is vector graphics shoehorned into XML, HTML is actually a natural fit for the DOM. [13:32:03.0000] Have you guys seen Adobe Edge? [13:33:00.0000] It finally became public today [13:33:01.0000] AryehGregor: Vector graphics are naturally layer-based, which seems like an acceptable fit for a tree-based language. [13:33:02.0000] huh, please, no jQuery [13:34:00.0000] Hopefully not the sucky magic bits of jQuery [13:34:01.0000] Depends on your defintion of "sucky magic". [13:34:02.0000] I was thinking of just looking at things that take five lines of DOM vs. one line of jQuery. [13:34:03.0000] Like "oh you entered a string that matched (some regexp) so you probably meant x" [13:34:04.0000] Not actually trying to copy it. [13:34:05.0000] In function parameters [13:34:06.0000] though, perhaps I'm against jQuery just because the implementation is ... less-than-perfect [13:34:07.0000] Heh, probably. [13:35:00.0000] much like the DOM [13:35:01.0000] ;) [13:35:02.0000] smaug____, Have you told the jQuery devs? [13:35:03.0000] smaug____: By that token is there any software you ar for ? :) [13:35:04.0000] Did anyone get my last post to public-html, in the thread about innerText? [13:35:05.0000] I haven't been able to figure out whether sending from ayg⊙an worked or not. [13:35:06.0000] to jresig yes [13:36:00.0000] What'd he say? [13:36:01.0000] not much [13:36:02.0000] I mean... Did you say "jQuery sucks" or did you pin point areas for improvement? [13:36:03.0000] I just CC'ed him to some bugs to show that jQuery causes mem usage to go high [13:36:04.0000] very high in some cases [13:36:05.0000] hmm [13:37:00.0000] Do other libs like prototype, mootools etc? [13:37:01.0000] and jQuery used to have code which slowed down unload of pages a lot, but I think they did fix that [13:37:02.0000] don't know about other libs [13:38:00.0000] because when profiling, if some slow down has been caused by a js lib, it has usually been jQuery [13:38:01.0000] perhaps because it is used so often [13:39:00.0000] I'd be curious to see the performance benchmarks for jQuery vs prototype etc [13:39:01.0000] Just because JS itself is a single threaded bottleneck [13:40:00.0000] *IIRC*, jQuery also uses some constructs which tend to be hard to optimize in JS JITs (at least in some forms of jits). [13:42:00.0000] jQuery is an abstraction layer, it aims more for ease of use than performance. [13:44:00.0000] /me says this as someone who just found that in his own code, he was repeatedly doing getDescendants(document) on a huge document, which recursed through all nodes in the document at a stack depth of like twenty, when he could have written it imperatively in a few more lines and iterated over like twenty nodes instead [13:44:01.0000] /me just rewrote that and noticed a significant speedup, but there don't seem to be good JS profiling tools last he checked . . . [13:49:00.0000] "JS itself is a single-threaded bottleneck" - not really [13:49:01.0000] Some concurrency is avaliable via workers [13:50:00.0000] and the idea of making the DOM threadsafe or letting random webdevs loose with threads in the browser is... not appealing [13:51:00.0000] Also, javascript is generally pretty fast these days. Surprisingly so, even [13:51:01.0000] yet in some cases still lacking in what seed like obvious optimisations to me [13:51:02.0000] seem [13:52:00.0000] i recently optimised a for loop by a factor of two by factoring out some common computation with variables that were not assigned to in the loop [13:52:01.0000] the loop had no side-effects, called no user methods [13:52:02.0000] it's hard to tell that in JS [13:53:00.0000] so are all the other optimisations [13:53:01.0000] i was surprised that this one hadn't been done yet [13:53:02.0000] AryehGregor: google chrome comes with good performance monitoring tools nowadays [13:54:00.0000] Moo--, its JS profiler tends to give me useless results. [13:54:01.0000] I've tried it pretty recently. [13:54:02.0000] IIRC, IE10 was the only browser that had usable profiling when I tested it out, although I think at the time Firebug wasn't working with my Firefox version. [13:55:00.0000] Hixie, were you calling into the DOM? [13:55:01.0000] no [13:55:02.0000] it was a loop on a CanvasPixelARra [13:55:03.0000] CanvasPixelArray even [13:55:04.0000] Same thing, really [13:55:05.0000] who is that the same thing? [13:55:06.0000] /me has a wide definition of "DOM" [13:56:00.0000] I should have said "native code" [13:56:01.0000] CanvasPixelArray shouldn't be any more native than String [13:57:00.0000] Not sure why it'd be any less native than Node per spec [13:57:01.0000] Node has to interact with complicated machinery [13:57:02.0000] CanvasPixelArray does not [13:58:00.0000] (e.g. what you do to a Node could involve HTTP, CSS, image decoding, memory allocation, mutation events, etc etc etc) [13:58:01.0000] And people still expect that to be fast :) [13:59:00.0000] that doesn't affect my point [13:59:01.0000] which is that in the case i was talking about, i don't see why it should be that hard to optimise [14:00:00.0000] compared to other optimisations that have already been done [14:01:00.0000] Yeah, in this case it should [14:06:00.0000] Hixie: On all browsers? It's not like everyone has the same optimisations [14:07:00.0000] i do not recall on what browsers i tested [14:08:00.0000] Firefox might be better there, because we implement it as an ArrayBuffer [14:21:00.0000] Hixie: Loop invariant code motion is actually not that easy to do with JS, because such a small amount can actually be proven to be loop-invariant [14:28:00.0000] what makes it hard to prove loop-invariancy? [14:30:00.0000] "But rather than actually calculating the dimensions of that hypothetical box, user agents are free to make a guess at its probable position." [14:30:01.0000] <3 CSS [14:34:00.0000] Hixie: Doing static analysis of entire lexical scopes is expensive (so any function call becomes expensive), and the fact that objects can change their value in random places. [14:38:00.0000] gsnedders: sure but in this case there were no such problems :-) [14:38:01.0000] gsnedders: it was just math [14:38:02.0000] anyway [14:42:00.0000] Rather than proving hard optimisations are perfectly safe and coping with obscure edge cases, browsers ought to run an aggressive optimiser that's safe 99% of the time, and also run a completely independent clone of the page in parallel with a slow but perfectly safe JS engine [14:43:00.0000] then if the first one happens to go wrong, the divergence will be detected soon when the second one catches up with it, and the browser can switch to displaying the output of the second one [14:43:01.0000] And then stay on the slow one forever? [14:43:02.0000] so you'll eventually end up with the correct result but in most cases you'll get the result displayed much sooner [14:44:00.0000] It's a foolproof plan [14:44:01.0000] there's one pretty fatal flaw with this plan [14:45:00.0000] no wait, two. [14:45:01.0000] though i guess the second one is the same as the first. [14:45:02.0000] so one. [14:45:03.0000] (namely, that script can have side-effects) [14:46:00.0000] (the second one is that the script's side-effects include "taking time" which can be detected from script, but i guess you cuold make new Date() in the second script always return whatever it returned on that occurrence in the first script.) [14:52:00.0000] Hixie: Firefox should do a lot if you're on a traced path. If you're in method JIT, not so much. [14:53:00.0000] Hi [14:53:01.0000] why iframe is allowed by default to navigate the parent window? [14:53:02.0000] isn't this potentialy dangerous? [14:53:03.0000] It's only allowed to do so when it's same-origin as the parent, right? [14:54:00.0000] TabAtkins: I'm afraid not [14:54:01.0000] no… wait, I have same origin policy disabled in browser [14:55:00.0000] let me check [14:55:01.0000] Navigating the parent is how things break out of frames, no? [14:55:02.0000] http://en.wikipedia.org/wiki/Framekiller [14:55:03.0000] Isn't that one of the things