| 01:48 | <karlcow> | http://masinter.blogspot.com/2011/06/irreconcilable-differences.html |
| 01:49 | <paul_irish> | homeboy forgot to close a <font> tag |
| 06:40 | <annevk> | heycam|away, you're away! |
| 06:41 | <annevk> | heycam|away, but I guess I figured it out, if dictionary members do not have defaults they will simply not form part of the dictionary and not overwrite existing defaults |
| 06:45 | <hsivonen> | looks like Larry revived his false dichotomies as a blog post http://masinter.blogspot.com/2011/06/irreconcilable-differences.html |
| 06:48 | <annevk> | oh lol |
| 06:48 | <annevk> | those are his slides from last TPAC no? |
| 06:53 | <hsivonen> | annevk: yes |
| 07:12 | <annevk> | I wonder why http://lists.w3.org/Archives/Public/www-dom/2011AprJun/0264.html is not in my inbox |
| 07:16 | <Dashiva> | I haven't even started scrolling and I want to comment |
| 07:16 | <Dashiva> | How is "There does need to be a transition plan (how to make changes in a way that doesn't break existing content or viewers)" done with pages that are no longer maintained? |
| 07:17 | <annevk> | Oh, that is in a different thread |
| 07:24 | <Dashiva> | I can't believe that post is actually from this year |
| 08:19 | <annevk> | oh great |
| 08:19 | <annevk> | var x = document.implementation.createHTMLDocument("xxx"); |
| 08:19 | <annevk> | x.documentURI vs x.URL vs x.body.baseURI |
| 08:19 | <annevk> | null, script URL, null |
| 08:21 | <hsivonen> | annevk: why script URL instead of the URL of the document that included the script? |
| 08:21 | <hsivonen> | annevk: the platform isn't supposed to keep track of script URLs, is it? |
| 08:22 | <annevk> | and even though the ele.baseURI is technically null <a href=/test> still resolves against document.URL |
| 08:22 | <annevk> | hsivonen, sorry, script URL was my shortcut for that |
| 08:23 | <annevk> | it is the document address of the script document |
| 08:23 | <annevk> | oh that is in Opera |
| 08:23 | <annevk> | in Firefox baseURI is about:blank! |
| 08:24 | <annevk> | and the link is simply /test unresolved |
| 08:24 | <annevk> | in Chrome both are the empty string... |
| 08:25 | <annevk> | Safari null and /test |
| 08:25 | <hsivonen> | speaking of about:blank, my about:blank project is not at a stage where trying to fix the remaining browser chrome failures starts regressing Web content tests that I already had succeeding |
| 08:25 | <hsivonen> | s/not/now/ |
| 08:31 | <MikeSmith> | hsivonen: that doesn't sound like fun |
| 08:32 | <hsivonen> | MikeSmith: it isn't |
| 08:32 | <MikeSmith> | oh |
| 08:32 | <MikeSmith> | ah, not fun |
| 08:32 | <hsivonen> | I guess this is a bit easier for browsers whose UI isn't vaguely based on Web-like concepts |
| 08:33 | <MikeSmith> | that's what make it's harder for the Firefox case? |
| 08:35 | <hsivonen> | MikeSmith: yeah. the browsing context in a newly-created tab shows up like a top-level browsing context to the Web content and as an iframe-like thingy to XUL and both have unit test expectations about the initial about:blank and its events |
| 08:35 | <MikeSmith> | ah wow |
| 08:37 | <hsivonen> | MikeSmith: basically for each failure, I need to figure out if I can satisfy both expectations or if expectations on one side should change |
| 08:37 | <MikeSmith> | yipes |
| 08:37 | <MikeSmith> | well, I'm sure the glamor and prestige of doing browser development make it all worthwhile |
| 08:45 | <annevk> | So in Gecko document.documentURI is simply about:blank |
| 08:45 | <annevk> | And document.URL too |
| 08:45 | <annevk> | I kind of like their consistent behavior and not having null... |
| 08:57 | <annevk> | oh sweet |
| 08:57 | <annevk> | both Gecko and Opera for setting document.documentURI |
| 09:45 | <MikeSmith> | fwiw, I fiddled with some stuff in the author view of the spec such that the references for the DOM attributes in IDLs now link to the "domintro" stuff instead of going back to the full spec |
| 09:45 | <MikeSmith> | per http://www.w3.org/Bugs/Public/show_bug.cgi?id=13038 |
| 10:10 | <matjas> | zcorpan: does http://mathiasbynens.be/notes/etago#comment-4 look alright now? |
| 11:12 | <zcorpan> | matjas: seems you dropped a link on the floor |
| 11:14 | <matjas> | whoops, this one: http://lists.w3.org/Archives/Public/public-html/2009Oct/0146.html |
| 11:14 | <zcorpan> | yep |
| 11:16 | <matjas> | added (“compatible”) |
| 11:35 | <zcorpan> | thanks |
| 12:09 | <annevk> | smaug____, yay for mutation events progress |
| 12:11 | <smaug____> | annevk: all the comments welcome |
| 12:11 | <smaug____> | I assume some people may not like as low level API what the proposed API currently is |
| 12:17 | <annevk> | it would be great if you could elaborate on list about the execution model |
| 12:17 | <annevk> | removeNode(...); someothercode(); |
| 12:18 | <annevk> | someothercode() executes after the listeners as I understand it? |
| 12:18 | <annevk> | but somehow that does not cause the same problems as mutation events did |
| 12:18 | <annevk> | is that because the removed node is not exposed? |
| 12:19 | <annevk> | I guess I should comment on list |
| 12:22 | <Philip`> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=13079 - "When we set the doctype to html 5 (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5 Transitional//EN" "http://www.w3.org/TR/html5/loose.dtd">)"; - where did they get that from? |
| 12:23 | <Ms2ger> | s/4/5/g? |
| 12:31 | <annevk> | If someone is bothered by @WHATWG retweeting my account on some spec related matters please tell me and I'll find some other way of doing the same thing... |
| 12:32 | <annevk> | Also, if you have any tweets that could be retweeted by the @WHATWG account let me know |
| 13:01 | <smaug____> | AryehGregor: you're writing the range spec, right? |
| 13:01 | <smaug____> | what is the state of it? |
| 13:01 | <smaug____> | and do you have a link to it? |
| 13:01 | <Ms2ger> | html5.org/specs/dom-range.html |
| 13:02 | <smaug____> | what is html5.org? |
| 13:04 | <MikeSmith> | Ms2ger: what's the dvcs repo for that? |
| 13:05 | <Ms2ger> | There's a link in the spec |
| 13:05 | <MikeSmith> | ok |
| 13:06 | <annevk> | smaug____, bitbucket.org does not have a nice way of viewing HTML files so I created a place there |
| 13:15 | <MikeSmith> | bitbucket really should provide something similar to the github gh-pages thing |
| 13:17 | <smaug____> | Ms2ger: ping |
| 13:17 | <smaug____> | Ms2ger: so the new range spec has the same insertNode behavior as what the old one, right? |
| 13:17 | smaug____ | hopes so |
| 13:18 | <smaug____> | seems like it has the same behavior |
| 13:18 | <smaug____> | so Acid3 allows invalid behavior |
| 13:19 | Ms2ger | knows nothing |
| 13:19 | <Ms2ger> | Ask Aryeh :) |
| 13:20 | <smaug____> | Ms2ger: "DOM Range, Editor Ms2ger" |
| 13:20 | <smaug____> | Ms2ger: apparently I misinterpret what "Editor" means ;) |
| 13:20 | <MikeSmith> | that's an alternative spelling for "Aryeh" |
| 13:21 | <Ms2ger> | That means I wrote the header ;) |
| 13:27 | <zcorpan> | Ms2ger: btw, i wanna use anolis with xspec xref for the differences spec |
| 13:27 | zcorpan | is typing with an ice cream |
| 13:28 | Ms2ger | just had ice cream |
| 13:28 | gsnedders | finished his ice-cream a while ago :( |
| 13:29 | annevk | hasn't had ice cream for a while |
| 13:29 | annevk | tries to sort out compareDocumentPosition() |
| 13:31 | <Ms2ger> | zcorpan, yay! |
| 13:34 | <annevk> | Ms2ger, I would like to use it for a number of specifications too |
| 13:34 | <annevk> | Ms2ger, Progress Events, XMLHttpRequest, CORS, CSSOM, ... |
| 13:34 | <annevk> | Ms2ger, but I guess I should really have a local copy of some sorts running before doing that |
| 13:34 | <annevk> | or jgraham needs to finally make the web service :) |
| 13:35 | <Ms2ger> | Yeah, one of those |
| 13:35 | <AryehGregor> | smaug____, I put my rationale in comments, often in considerable detail. |
| 13:36 | <AryehGregor> | Which aspect are you looking at again? |
| 13:37 | <smaug____> | AryehGregor: I was just looking how insertNode is spec'ed when range is collapsed |
| 13:37 | <smaug____> | seems like range isn't modified in that case |
| 13:37 | <AryehGregor> | I have a comment at the end about that. |
| 13:37 | <smaug____> | like it is not modified per DOM 2 Range |
| 13:37 | <AryehGregor> | WebKit tries to modify it to contain the inserted node in all cases. |
| 13:38 | <AryehGregor> | But it was the only browser that does, and you can't do it in all cases anyway. |
| 13:38 | <AryehGregor> | E.g., if the range originally was inside a comment, you can't make it include the newly-inserted node. |
| 13:38 | <AryehGregor> | So I figured it was better to go with the other browsers. |
| 13:39 | <AryehGregor> | If Acid3 allows WebKit's behavior here, it shouldn't. |
| 13:39 | <smaug____> | AryehGregor: Opera modifies, or at least some version of Opera, modifies Range |
| 13:39 | <smaug____> | AryehGregor: originally Acid3 accepted only webkit's behavior |
| 13:39 | <AryehGregor> | Well, let me check my tests: http://aryeh.name/spec/dom-range/test/Range-insertNode.html |
| 13:39 | <smaug____> | and, IIRC, Opera changed the behavior so that they passed Acid3 |
| 13:40 | <smaug____> | although the change made them incompatible with DOM range spec |
| 13:40 | hsivonen | wonders what needs to happen for Wikipedia editors to stop using Acid3 as an indicator of standards support |
| 13:41 | <AryehGregor> | This tests it: http://aryeh.name/spec/dom-range/test/Range-insertNode.html?23,3 |
| 13:41 | <AryehGregor> | hsivonen, edit war! |
| 13:41 | Ms2ger | reverts four times |
| 13:41 | <Ms2ger> | Nooooooooooooooooooo |
| 13:42 | <AryehGregor> | smaug____, indeed, Opera and WebKit both fail that test. |
| 13:42 | <AryehGregor> | Gecko passes. |
| 13:42 | <AryehGregor> | Ms2ger, no problem as long as you make sure there's 24 hours and one minute in between the first and fourth. |
| 13:42 | <smaug____> | ACID3 allows both behaviors |
| 13:43 | <smaug____> | since it was modified afterwards to allow also the specified behavior |
| 13:43 | <Ms2ger> | AryehGregor, WP:WL |
| 13:44 | <AryehGregor> | Oh, hmm. |
| 13:44 | <AryehGregor> | It looks like IE9 matches WebKit and Opera here. |
| 13:44 | <AryehGregor> | So maybe the spec should change too. |
| 13:45 | <AryehGregor> | Three out of four engines is usually enough that the spec should match unless there's a strong reason against. |
| 13:45 | <smaug____> | grr |
| 13:45 | <smaug____> | I would hate that |
| 13:45 | <smaug____> | just because webkit happened to be buggy |
| 13:45 | <smaug____> | and that bug ended up in to acid3 |
| 13:46 | <AryehGregor> | Yeah, but let's be honest, like half of all the details in web specs are because some browser happened to be buggy. :) |
| 13:46 | <hsivonen> | hmm. looks like someone at Wikipedia decided that from Firefox 5 onwards, Firefox versions don't get Wikipedia pages anymore |
| 13:47 | gsnedders | still likes that the fact the only HTML parsing quirk exists because of Acid 2 |
| 13:47 | <gsnedders> | s/that the fact/the fact that/ |
| 13:47 | <AryehGregor> | I don't mind sticking with the current spec, but only if we get implementers' agreement to change. Even then, it would be *much* easier at this point to converge on the non-Gecko behavior, because Gecko now has very fast release cycles and IE/Safari/Opera do not. |
| 13:48 | <Ms2ger> | hsivonen, can't say I disagree with that decision |
| 13:48 | <smaug____> | AryehGregor: the problem is that specifying insertNode differently makes the API inconsistent when handling mutations to DOM |
| 13:48 | <AryehGregor> | smaug____, so I'm going to change the spec and tests now unless you have strong practical reasons to the contrary. In particular, which behavior is more useful, the standardized or non-standardized behavior? |
| 13:48 | <AryehGregor> | What do you mean? |
| 13:48 | <smaug____> | AryehGregor: right now all the mutations are handled the same way |
| 13:48 | <AryehGregor> | Just add an extra step saying that if the range is collapsed, increment the end offset. |
| 13:49 | <AryehGregor> | There are already other methods that modify the range beyond just following range mutation rules, like deleteContents() and friends. |
| 13:49 | <smaug____> | AryehGregor: IIRC, some implementations have some special hacks for insertNode |
| 13:49 | <AryehGregor> | What sort of special hack? |
| 13:49 | <gsnedders> | AryehGregor: We have a particuarly slow release cycle? 10 September 2009, 10.10 November 2009, 11 10.50 last March, 10.60 last July, 11 in April, 11.50 today… That's a single gap of more than six months. |
| 13:49 | <smaug____> | that if you call insertNode, then end offset is incremented |
| 13:50 | <smaug____> | but if you just do other dom mutation, end offset isn't incremented |
| 13:50 | <hsivonen> | Ms2ger: I don't either, but it's strange that the main Firefox page still links to 5, 6 and 7 the way it used to |
| 13:50 | <smaug____> | but this is IIRC |
| 13:50 | <smaug____> | needs testins |
| 13:50 | <AryehGregor> | gsnedders, compared to Firefox and Chrome, with six weeks between major releases and support for the old version dropping as soon as the new version is released. |
| 13:50 | <Ms2ger> | Er |
| 13:50 | <smaug____> | testing |
| 13:50 | <AryehGregor> | smaug____, I've got the tests already. I apparently didn't notice that everyone but Firefox failed this particular test in the same exact way. |
| 13:50 | <AryehGregor> | I.e.: http://aryeh.name/spec/dom-range/test/Range-insertNode.html?23,3 |
| 13:51 | <AryehGregor> | assert_equals: Unexpected endOffset after insertNode() expected 0 but got 1 |
| 13:51 | <gsnedders> | AryehGregor: meh, four months on average, and dropping support straight away, pretty much. |
| 13:51 | <gsnedders> | AryehGregor: I wouldn't call that slow. |
| 13:51 | <AryehGregor> | Fast enough, yeah. |
| 13:51 | <AryehGregor> | Especially since Opera's market share is so low anyway. |
| 13:52 | <smaug____> | it is a bit hard to read that test |
| 13:52 | <hsivonen> | someone shoud re-do http://bethesignal.org/blog/2011/02/19/modern-browsers-ship/ in a few month with new Firefox data an with cluefully obtained Opera data |
| 13:52 | <AryehGregor> | smaug____, I believe that currently, every single Range method that modifies the DOM also modifies the range's endpoints beyond the range mutation rules, *except* insertNode. |
| 13:52 | <AryehGregor> | Oh, you mean read the source code? Yeah, it's kind of complicated. |
| 13:53 | <AryehGregor> | Try removing the query parameter and you'll see, it's one test out of thousands (note that this might freeze Firefox for a solid minute or two). |
| 13:53 | <smaug____> | I'm talking about the non-Range methods which modify the DOM |
| 13:53 | <smaug____> | and how they affect to the range |
| 13:53 | <AryehGregor> | Well, those aren't handled totally consistently either. |
| 13:53 | <smaug____> | really? |
| 13:53 | <AryehGregor> | http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation |
| 13:53 | <smaug____> | they are in Gecko |
| 13:53 | <AryehGregor> | I mean, at least as far as the spec goes, there's special text for splitText(), insertData(), and deleteData(). |
| 13:54 | <smaug____> | ah, text data |
| 13:54 | <AryehGregor> | IIRC, Gecko doesn't special-case splitText(), but does special-case the other two. |
| 13:54 | <annevk> | http://people.gnome.org/~jdub/2011/modern-browsers-ship/ is pretty cool |
| 13:54 | <AryehGregor> | DOM 2 Range pretended this was consistent by not actually defining behavior exactly. |
| 13:55 | <smaug____> | range object in gecko doesn't know anything about splittext/insertData/deleteData |
| 13:55 | <AryehGregor> | Yeah, I've been told. |
| 13:56 | <AryehGregor> | Anyway, I don't know why this is relevant, because insertNode() is a Range method, and all the other Range methods that mutate the DOM also change the Range's endpoints in some special fashion. |
| 13:56 | <hsivonen> | annevk: the HTML-XML TF call is now. DST for the lose again |
| 13:56 | <AryehGregor> | Namely deleteContents(), extractContents(), and surroundContents(). |
| 13:56 | <AryehGregor> | DOM 2 Range pretends that delete/extractContents() aren't special, but it's a lie. |
| 13:57 | <AryehGregor> | In that if you put some other range at the same location as the one you run delete/extractContents() on, they'll wind up different in all browsers, IIRC. |
| 13:57 | <AryehGregor> | (I should test that.) |
| 13:58 | <AryehGregor> | Well, just for example, if you have a range like <p>foo{</p></p>}bar</p> and run deleteContents(), it will become <p>foo</p>{}<p>bar</p>, but nothing was actually deleted, so other ranges won't be affected. |
| 13:58 | <AryehGregor> | (because after you call extract/deleteContents() on a range, it's always collapsed) |
| 14:02 | <smaug____> | AryehGregor: btw, what will happen to your range spec? Will to propose it to web apps wg, or to whatwg or what? |
| 14:02 | <AryehGregor> | smaug____, I dunno, really Ms2ger is the one who owns it. I just happen to have added lots of stuff. |
| 14:02 | <AryehGregor> | I think there's some idea it will get proposed to the Web Apps WG. |
| 14:03 | <AryehGregor> | But the W3C is such a pain to work with, with all their bureaucracy. Licensing, versioning, blah blah blah. |
| 14:03 | <AryehGregor> | If people don't like it being put on html5.org, which is a random domain owned by annevk, we could probably get it put up on whatwg.org, which is a random domain owned by Hixie. :) |
| 14:04 | <Ms2ger> | Yeah, WebApps, some day, I guess |
| 14:05 | AryehGregor | is in favor of WHATWG instead, if it's going to be moved anywhere |
| 14:05 | <annevk> | smaug____, so if mutation listeners fire right near the end they cannot be used to implement normal mutation events in their entirety |
| 14:05 | <smaug____> | The only problem is that MS isn't active in WhatWG |
| 14:06 | <smaug____> | annevk: DOMNodeRemoved cannot be implemented |
| 14:06 | <AryehGregor> | If the WHATWG spec is the only one that matches reality, then they can choose to either follow it and all the other browsers, or not follow other browsers. |
| 14:06 | <AryehGregor> | They don't have to be active in the WHATWG to read their specs. |
| 14:09 | <gsnedders> | AryehGregor: No patent policy, though. |
| 14:09 | <AryehGregor> | Yeah, well. |
| 14:10 | <AryehGregor> | The W3C's patent policy is pretty weak anyway. |
| 14:10 | <AryehGregor> | It doesn't matter to me in the end. |
| 14:10 | <smaug____> | AryehGregor: so, FYI, webkit handles insertNode in a different way than range.startContainer.appendChild() |
| 14:10 | <smaug____> | and that is strange |
| 14:10 | <smaug____> | IMHO |
| 14:10 | <AryehGregor> | smaug____, different in what way? |
| 14:11 | <smaug____> | AryehGregor: appendChild doesn't affect to the endOffset |
| 14:11 | <smaug____> | the range stays collapsed |
| 14:11 | <AryehGregor> | Well, of course it doesn't. insertNode() only has a special effect on the range you're calling it on, just like deleteContents(). |
| 14:11 | <annevk> | Ms2ger, same node, not in the same document, same parent, same root, descendant, ancestor; any other cases for compareDocumentPosition you can think of? |
| 14:11 | <AryehGregor> | All other ranges follow normal mutation rules. |
| 14:12 | <smaug____> | AryehGregor: what you mean "of course it doesn't"? |
| 14:12 | <annevk> | same parent / same root are the same it seems |
| 14:12 | <smaug____> | DOM mutations should modify range objects the same way |
| 14:12 | <AryehGregor> | They do. However, Range methods can affect the Range they're called on as well as doing DOM mutations. |
| 14:13 | <AryehGregor> | deleteContents() and surroundContents(), for instance, mutate the DOM and then also change the boundary points of the Range. |
| 14:13 | <Ms2ger> | annevk, no, but that might be because my brain melted in this heat |
| 14:13 | <AryehGregor> | Likewise, insertNode() has no special effect on any Range other than the one it's called on. |
| 14:14 | <smaug____> | AryehGregor: per spec, insertNode doesn't have any special effect |
| 14:14 | <AryehGregor> | The advantage of the currently nonstandard behavior is that authors can be pretty sure the node they just added will now be contained in the range, barring weird cases like if it was in a comment. |
| 14:14 | <AryehGregor> | smaug____, per non-Gecko browsers, it does. Specs try to match browsers around here, not the other way around. :) |
| 14:15 | <smaug____> | AryehGregor: did you just change the spec? |
| 14:15 | <AryehGregor> | No, but I'm probably going to shortly. |
| 14:15 | <annevk> | Ms2ger, you must be near :) |
| 14:15 | <AryehGregor> | Our options are 1) change the spec and get Gecko to change, 2) leave the spec alone and get IE plus WebKit plus Opera to change. |
| 14:15 | <AryehGregor> | Which one is going to get us interop faster? |
| 14:15 | <AryehGregor> | (2) will take a very long time before we have interop in practice, years. |
| 14:15 | <AryehGregor> | IE9 will be around for a long time. |
| 14:15 | <AryehGregor> | Firefox 5 and 6 will not be around for long at all. |
| 14:15 | <smaug____> | I doubt IE9 will be around for a long time |
| 14:16 | <AryehGregor> | And changing one engine is more feasible than changing three. |
| 14:16 | <Ms2ger> | annevk, I guess that limits it to western Europe and India? :) |
| 14:16 | <smaug____> | Safari 6 (or whatever it will be called) might be |
| 14:16 | <AryehGregor> | It'll be around for a few years at least. The current situation is you don't have interop, and that's just a pain for authors. |
| 14:16 | <smaug____> | AryehGregor: I just hate when we're making web platform internally more inconsistent |
| 14:17 | <AryehGregor> | Interoperability is more important than consistency. If things behave the same across browsers, authors can paper over any weirdness. The real pain is when different browsers behave differently. |
| 14:17 | <AryehGregor> | That's when things are really inconsistent, in practice. |
| 14:18 | <AryehGregor> | I also don't agree that it's more inconsistent, as I've explained. Range methods can mutate the DOM and then also change the range's endpoints; that's natural and reasonable and already happens in other methods. |
| 14:19 | <annevk> | I don't think interoperability should be the only goal. Having a five year goal for how a feature should turn out and specifying it that way and going after browsers to get it that way is fine. |
| 14:20 | <AryehGregor> | Yes, but only if the goal is important enough to outweigh the interop costs. |
| 14:20 | <AryehGregor> | In this case I really don't think it is. |
| 14:21 | <AryehGregor> | smaug____, you probably know how things work around here. If you get IE or WebKit to agree to change, I'll leave the spec alone. |
| 14:21 | <AryehGregor> | Otherwise, I'll change it to match the majority of browsers. |
| 14:21 | smaug____ | files a bug on webkit |
| 14:21 | <smaug____> | and sends email to his MS contacts |
| 14:22 | <AryehGregor> | Make sure you tell them that everyone but Gecko agrees. |
| 14:22 | <AryehGregor> | But if you're doing that, I won't change the spec, I'll just add an XXX for now. |
| 14:22 | <AryehGregor> | Let me know what response you get. |
| 14:23 | <AryehGregor> | (it will actually be a pain for me to change the spec, because I'll have to update the tests and also the edit commands spec which relies on the current specced behavior) |
| 14:24 | <gsnedders> | smaug____: File a bug on Opera too |
| 14:24 | <smaug____> | Filing bugs on Opera tends to be hard |
| 14:24 | <smaug____> | usually the form has just failed |
| 14:24 | <smaug____> | but I'll try |
| 14:25 | <annevk> | on https://bugs.opera.com/wizard/ ? |
| 14:25 | <annevk> | I never heard it failing, but that sucks |
| 14:27 | <gsnedders> | smaug____: If it fails drop me an email, probably giving your IP and rough time. |
| 14:34 | <Ms2ger> | MikeSmith, http://www.w3.org/2011/08/browser-testing-charter.html < s/Wed Driver/Web Driver/ |
| 14:37 | <zcorpan> | http://html5doctor.com/blockquote-q-cite/ - footer in blockquote for citation isn't endorsed in the spec right |
| 14:38 | <Ms2ger> | No, but it is by the doctors |
| 14:40 | <AryehGregor> | 0 08:48:16 ~/webroot/spec/dom-range$ hg pull |
| 14:40 | <AryehGregor> | abort: HTTP Error 500: INTERNAL SERVER ERROR |
| 14:40 | <AryehGregor> | Hmm, I guess that's bitbucket's fault? |
| 14:40 | <AryehGregor> | Well, this is what DVCSes are for, right? |
| 14:41 | <Ms2ger> | "Someone kicked over the bucket, sadface" |
| 14:42 | <AryehGregor> | Cute logo. |
| 14:43 | <AryehGregor> | With the mercury spilling out of the bucket and all. |
| 14:43 | <AryehGregor> | Now of course krijnhoetmer.nl is taking forever to respond too. |
| 14:43 | AryehGregor | twiddles thumbs, xkcd.com/303/-style |
| 14:44 | AryehGregor | notices the new Google Instant thing for the first time -- it really loaded instantly there |
| 14:44 | <AryehGregor> | (or Chrome preload, or Instant Pages, or whatever it's called) |
| 14:47 | <AryehGregor> | smaug____, added an XXX: http://html5.org/specs/dom-range.html#dom-range-insertnode |
| 14:51 | <MikeSmith> | Ms2ger: thanks |
| 14:52 | <Ms2ger> | Np |
| 15:04 | <AryehGregor> | You know what? Functional programming is really cool. |
| 15:05 | <AryehGregor> | Upon discovering there's no unique() method for arrays in JS, I immediately wrote .filter(function(el, i, arr) { return arr.slice(0, i).indexOf(el) != -1 }). |
| 15:05 | <AryehGregor> | Which is so much nicer than any procedural way of saying the same thing. |
| 15:05 | <AryehGregor> | <3 |
| 15:06 | <bga_> | AryehGregor but O(n*n/2) |
| 15:06 | <bga_> | not O(n) |
| 15:06 | <AryehGregor> | Premature optimization is the root of all evil. |
| 15:07 | <Ms2ger> | sqrt(n)? |
| 15:07 | <AryehGregor> | This is like 200-element arrays here. |
| 15:07 | <gsnedders> | bga_: You can only do it in JS in O(n) if it is a sorted array |
| 15:07 | <bga_> | O() optimization is good |
| 15:07 | <AryehGregor> | Anyway, surely you can't do better than O(N log N). |
| 15:07 | <AryehGregor> | No optimization is good if you don't need it. |
| 15:07 | <bga_> | gsnedders yeah |
| 15:07 | <Ms2ger> | With a hashset? |
| 15:07 | <gsnedders> | AryehGregor: You can do O(n) if it is sorted. |
| 15:07 | <bga_> | O(n) + O(n*log(n)) |
| 15:08 | <gsnedders> | AryehGregor: Becaues you just look at the previous item and compare. |
| 15:08 | <AryehGregor> | gsnedders, you can do it in O(1) if all elements are unique to start with. |
| 15:08 | <gsnedders> | AryehGregor: Hw? |
| 15:08 | <AryehGregor> | Actually, O(0). |
| 15:08 | <gsnedders> | *how |
| 15:08 | <AryehGregor> | gsnedders, no-op. |
| 15:08 | <bga_> | but radix sort is O(n) |
| 15:08 | <AryehGregor> | But we're talking about the general case here. |
| 15:08 | <bga_> | if elements is ints |
| 15:08 | <bga_> | *are |
| 15:08 | <gsnedders> | AryehGregor: How do you know it is a no-op? |
| 15:08 | <AryehGregor> | bga_, only if they're sufficiently small ints. |
| 15:09 | <AryehGregor> | gsnedders, because I said all the elements are unique to start with. |
| 15:09 | <Philip`> | var found = {}; arr.filter(function(el) { var r = found[el]; found[el] = 1; return !r; }); ? |
| 15:09 | <gsnedders> | AryehGregor: So you have an algorithm that takes an array of unique items and returns one? |
| 15:09 | <gsnedders> | Philip`: Only works if el is guaranteed to be a string |
| 15:10 | <gsnedders> | Philip`: Also breaks with arr = ["toString"] |
| 15:10 | <Philip`> | JSONify it if not |
| 15:10 | <AryehGregor> | gsnedders, no, I have an algorithm that accepts an array of unique items and returns the same array but with all duplicate items removed. It goes like this: function(arr) { return arr; } |
| 15:10 | <gsnedders> | AryehGregor: That's not exactly an interesting case… the sorted list one at least is. |
| 15:10 | <AryehGregor> | gsnedders, my point is that we were talking about the general case, and it's clearly easier in special cases. |
| 15:11 | <annevk> | Ms2ger, https://bitbucket.org/ms2ger/dom-core/changeset/67d16b47908c and https://bitbucket.org/ms2ger/dom-core/changeset/9f35be8e6f89 |
| 15:11 | <AryehGregor> | Wait, setting foo[s] to something will behave magically if s happens to be "toString"? That seems very scary. |
| 15:11 | <annevk> | Ms2ger, should define compareDocumentPosition() |
| 15:11 | <gsnedders> | Philip`: You can't JSONify everything |
| 15:11 | <Ms2ger> | Yay! |
| 15:11 | <gsnedders> | AryehGregor: No, it doesn't do anything magic. |
| 15:11 | <bga_> | Philip` its still O(n) - O(n*log(n)) depends from hash fn |
| 15:11 | <AryehGregor> | Good. |
| 15:12 | <bga_> | and need too many mamory |
| 15:12 | <gsnedders> | AryehGregor: Just {}.toString is defined, so !r is always false. |
| 15:12 | <bga_> | *memory |
| 15:12 | <gsnedders> | AryehGregor: Because everything goes up the prototype chain, and Object.prototype.toString exists |
| 15:12 | <Philip`> | gsnedders: You can't sort everything or compare everything for equality, either |
| 15:12 | <AryehGregor> | Oh, I see. |
| 15:12 | <AryehGregor> | That is sort of magic, though. |
| 15:13 | <bga_> | gsnedders right, var found = Object.create(null) |
| 15:13 | <gsnedders> | Philip`: You can compare everything for equality, no? Some things are non-trivial (±0, etc.) |
| 15:13 | <bga_> | but new issue is __proto__ |
| 15:13 | <gsnedders> | bga_: Or just use hasOwnProperty. |
| 15:13 | <bga_> | hasOwnPorperty is double lookup |
| 15:13 | <bga_> | :( |
| 15:13 | <gsnedders> | bga_: How so? |
| 15:14 | <gsnedders> | bga_: Oh, you mean the fact you have to look up hasOwnProperty? That's cached. |
| 15:14 | <gsnedders> | Except it won't be becaues the class of found will continuously change >_> |
| 15:14 | <gsnedders> | *because |
| 15:16 | <bga_> | gsnedders i have remember for(var i in obj){ if(obj.hasOwnProperty(i)){ var v = obj[i] }}, sorry |
| 15:16 | <bga_> | obj.hasOwnProperty(i) // 1st lookup var v = obj[i] // 2nd lookup |
| 15:17 | <gsnedders> | bga_: IonMonkey should make that a single lookup, at least. |
| 15:17 | <bga_> | gsnedders btw i know optimization |
| 15:18 | <bga_> | its works for all engines except IE |
| 15:18 | <gsnedders> | bga_: For that pattern? |
| 15:18 | <Ms2ger> | gsnedders, keeping a close eye on us, are you? :) |
| 15:18 | <bga_> | for(var i in obj){ if(!obj.hasOwnProperty(i)) break; var v = obj[i] } |
| 15:18 | <gsnedders> | Ms2ger: I know what goes on in JS-land. :) |
| 15:19 | <gsnedders> | bga_: Not continue? Otherwise the two are different… |
| 15:19 | <bga_> | because modern engines traverse keys from top to bottom |
| 15:20 | <Philip`> | Someone should make a SpiderMonkey Island adventure game where you have to solve the seemingly-impossible puzzle of working out exactly what all various ...Monkey names refer to |
| 15:20 | <bga_> | except IE which traverse from 2nd proto to bottom and then top |
| 15:20 | gsnedders | still doesn't see why it should be quicker than the first |
| 15:21 | <bga_> | gsnedders {a: 1, __proto__: {b: 1, __proto__: .... {end: 1}}} |
| 15:22 | <Ms2ger> | Philip`, there was a blog post explaining just that recently |
| 15:22 | <bga_> | not ie - a, b, ... end |
| 15:22 | <bga_> | ie - b,... end, a |
| 15:22 | <gsnedders> | bga_: Yeah, sure. But both do hasOwnProperty at the same point, it's just whether it's negated and what's in the if block that differs. |
| 15:22 | <gsnedders> | bga_: I'm well aware of how stuff is represented in JS engines, FWIW. |
| 15:23 | <Ms2ger> | "gsnedders, PhD" |
| 15:23 | Ms2ger | imagines |
| 15:24 | <bga_> | gsnedders i have Object.prototype._each = IS_GOOD_TRAVERSE_ORDER && "break" case || general case |
| 15:24 | <gsnedders> | Ms2ger: meh, uni |
| 15:24 | <bga_> | feature detection |
| 15:24 | <gsnedders> | Ms2ger: It's more fun just working on ES engines :) |
| 15:24 | <Ms2ger> | gsnedders++ |
| 15:24 | <Ms2ger> | s/ES/DOM/ |
| 15:24 | <Ms2ger> | IMO |
| 15:25 | <gsnedders> | Ms2ger: I've got bored of DOM. Compilers are more interesting. :) |
| 15:25 | <gsnedders> | bga_: break still makes the two have different behaviour, though. |
| 15:25 | <gsnedders> | Oh, wait, duh |
| 15:25 | gsnedders | facepalms |
| 15:25 | <gsnedders> | Because it's the order of enumeration you were referring to. |
| 15:25 | <gsnedders> | Right. |
| 15:25 | <bga_> | :) |
| 15:27 | <bga_> | gsnedders btw how IonMonkey optimize double lookup? |
| 15:27 | <bga_> | just compare ast with pattern? |
| 15:27 | <bga_> | or more smarter? |
| 15:28 | <gsnedders> | bga_: Well, it's not written yet, but by using a lower-level IR, I presume [[GetOwnProperty]] will be an instruction within it, and then once you apply CSE you'll only have one call to it |
| 15:28 | <gsnedders> | (assuming they inline hasOwnProperty, that is) |
| 15:32 | <gsnedders> | Ms2ger: FWIW, I probably will get at least a bachelors, though in what subject I dunno. |
| 15:32 | <Ms2ger> | Heh |
| 15:33 | <gsnedders> | (equally whether it'll be a BA or a BSc) |
| 15:33 | <gsnedders> | (actually, it won't be a BA, because the ancient universities in Scotland don't award them, only awarding MAs) |
| 15:34 | <gsnedders> | (Though for all practical purposes they're a BA) |
| 15:34 | <Ms2ger> | Still enjoying the A? |
| 15:35 | <gsnedders> | Yeah. Probably more so than either maths or CS. |
| 15:36 | <Ms2ger> | The maths is too theoretical and you won't ever need anything from CS? :) |
| 15:37 | <Philip`> | Maths can never be too theoretical |
| 15:37 | <zcorpan> | it can be in theory |
| 15:38 | <Ms2ger> | Prove it! |
| 15:38 | <gsnedders> | Ms2ger: The maths is too basic so far, and, well, I know a lot of the CS stuff. There is stuff next year that I don't know (algebraic descriptions of algorithms for proofs, mianly). |
| 15:38 | <gsnedders> | *mainly |
| 15:39 | <Ms2ger> | I guess that's what you get for having too much experience ;) |
| 15:40 | <gsnedders> | Indeed. I had people trying to convince me to do some random undergrad, then do a CS masters. |
| 15:43 | <Philip`> | Can you attend arbitrary lectures for other years or other courses? |
| 15:43 | <Philip`> | (Maybe there's optional topics you won't have time for later but could learn about now) |
| 15:53 | <gsnedders> | Philip`: Technically no, practically yes. |
| 16:42 | <AryehGregor> | Ms2ger, what text editor do you use? |
| 16:42 | <AryehGregor> | Like, say, for spec editing. |
| 16:42 | <Ms2ger> | gedit, why |
| 16:42 | <Ms2ger> | ? |
| 16:42 | <AryehGregor> | I just discovered how awesome vim folding is. |
| 16:42 | <AryehGregor> | But I guess gedit doesn't support that. :) |
| 16:43 | <Ms2ger> | How well does it support HTML? |
| 16:43 | <AryehGregor> | How well does what support HTML? |
| 16:43 | <Ms2ger> | vim |
| 16:44 | <AryehGregor> | Well, the syntax highlighting seems to be essentially perfect. The autoindent script is annoying, though, and infuriating for embedded JS. |
| 16:44 | <AryehGregor> | (syntax highlighting works essentially perfectly for embedded JS and CSS too) |
| 16:44 | <AryehGregor> | Dunno what else you mean by "support". |
| 16:47 | <AryehGregor> | I guess the syntax highlighting could be better, like highlighting mismatched end tags. |
| 16:47 | <AryehGregor> | Certainly not better than a dedicated HTML IDE would be, but probably better than gedit. :) |
| 16:47 | <Ms2ger> | Oh, if only annevk had an editor that highlighted mismatched end tags :) |
| 16:48 | <AryehGregor> | Okay, so if I say that the boundary point of any range in a selection must be a Text or Element node and must descend from a Document, what happens if the author calls setStart() or something on a range that's in a selection? |
| 16:48 | <AryehGregor> | Should I change it so that getRangeAt() doesn't return a live range? |
| 16:48 | <AryehGregor> | That's how WebKit and Opera work . . . |
| 16:49 | AryehGregor | wants to make this change because it would simplify an awful lot in the edit command spec, and will make a lot of author code more correct as well |
| 17:21 | <AryehGregor> | What's up with the weird formatting here? https://bitbucket.org/ms2ger/dom-range/changeset/b9ca1640aeee |
| 17:21 | <AryehGregor> | Does hg or bitbucket expect some special format? |
| 17:21 | AryehGregor | is doing it more or less git-style, which he thought hg was okay with too, but maybe not |
| 17:27 | <charlvn> | AryehGregor: there seems to be two things: indentation and line endings |
| 17:28 | <AryehGregor> | There was no indentation in the raw commit message. |
| 17:28 | <AryehGregor> | There were forced line endings, yeah. I do that basically because git requires it if you don't want to wreck up formatting. |
| 17:28 | <charlvn> | no i'm referring the actual changeset, not the commit message |
| 17:28 | <AryehGregor> | Well, really just because my default setting in vim is to wrap at 79 columns and I didn't make an exception for hg commits. |
| 17:29 | <charlvn> | yeah i have this problem a lot myself |
| 17:29 | <AryehGregor> | Huh? Then I'm confused. What about the changeset? |
| 17:29 | <charlvn> | i meant there are changes in indentation and line endings in the changeset |
| 17:30 | <charlvn> | AryehGregor> There was no indentation in the raw commit message. |
| 17:30 | AryehGregor | is now completely confused. |
| 17:30 | <charlvn> | the commit message is just the thing right at the top |
| 17:30 | <charlvn> | "Restrict possible selection boundary points"... |
| 17:30 | <AryehGregor> | I know what a commit message is. |
| 17:30 | <AryehGregor> | I'm confused about what you're saying. |
| 17:31 | <AryehGregor> | I see extra line breaks in the commit message and I'm wondering why. |
| 17:31 | <charlvn> | you said "There was no indentation in the raw commit message." |
| 17:31 | <charlvn> | oh i see, sorry i misunderstood |
| 17:31 | <AryehGregor> | It seems where I put a single line break, it added a second one. |
| 17:31 | <charlvn> | i thought you were talking about the changeset itself |
| 17:31 | <AryehGregor> | No, the commit message. |
| 17:31 | <charlvn> | you mean the double line endings in the commit message |
| 17:31 | <charlvn> | resulting in empty lines |
| 17:32 | <AryehGregor> | It seems to treat two consecutive line breaks as a <p>, and then a single line break as <br>, but white-space is set to pre-wrap, so it adds two line breaks instead. |
| 17:32 | <AryehGregor> | Looks like a simple bug. |
| 17:32 | <charlvn> | ah yeah that sucks |
| 18:05 | <zewt-> | is there anything in the spec that explicitly says that objects must not hold a strong reference to another object unless explicitly specified to? eg. an HTMLDocument can't hold a reference to elements that are no longer underneith them, else it'd leak references |
| 18:07 | <AryehGregor> | zewt, what's the author-visible impact? |
| 18:07 | <AryehGregor> | I mean, why is that not an implementation detail? |
| 18:08 | <zewt> | if an HTMLDocument kept a reference to every HTMLImageElement that was previously inserted into it, it'd leak memory forever; developers need to know when references are held, so they know when that situation happens |
| 18:09 | <AryehGregor> | That's an implementation detail. |
| 18:09 | <zewt> | definitely not |
| 18:09 | <zewt> | "using infinite amounts of memory" is not an implementation detail. heh |
| 18:09 | <AryehGregor> | Sure it is, it's a QoI problem. I.e., an obvious bug. |
| 18:09 | <AryehGregor> | You don't need a standard to tell you it's stupid. |
| 18:10 | <Hixie> | gsnedders: if patent policy is a concern, i'm happy to work with people to address it so long as someone else is willing to take point on the effort |
| 18:10 | <AryehGregor> | zewt, we could also specify that browsers aren't allowed to have remote code execution vulnerabilities. |
| 18:10 | <zewt> | it's the job of a spec to be explicit about things, not to say "that's obvious" |
| 18:10 | <AryehGregor> | The spec only covers behavior that's either programmatically visible to authors, or visibly visible to users. This is neither. If there are memory leaks, you won't notice unless they happen to be really big. |
| 18:10 | <AryehGregor> | We can't say those violate the spec. |
| 18:11 | <AryehGregor> | Since you can't even detect them reliably. |
| 18:11 | <AryehGregor> | What would the conformance test be, running the browser in valgrind? |
| 18:11 | <zewt> | uh, I've crashed WebKit by scrolling around GMaps for a while in a 512MB VM, because it has exactly the bug I just described |
| 18:11 | <zewt> | that's pretty user-visible. |
| 18:11 | <AryehGregor> | Yes, and that's a WebKit bug. |
| 18:11 | <AryehGregor> | But not a standards-compliance bug, just a bug bug. |
| 18:11 | <AryehGregor> | Standards aren't necessary to tell implementers things that they'll all agree to anyway. |
| 18:11 | <AryehGregor> | Like "let's not have giant memory leaks". |
| 18:11 | <zewt> | except they don't agree. |
| 18:12 | <AryehGregor> | orly? |
| 18:12 | <zewt> | webgl person is saying that it's OK for a webgl context to hold a reference to texture objects |
| 18:12 | <zewt> | (analogous to document/image) |
| 18:13 | <AryehGregor> | It's "okay" in that it doesn't violate the standard, and shouldn't violate the standard, any more than erasing your hard drive when you install the browser would violate the standard. |
| 18:13 | <zewt> | sorry, that's just silly. |
| 18:13 | <AryehGregor> | It doesn't affect interop any more than any performance or crash bug. |
| 18:13 | <AryehGregor> | Do you think the standard also has to say that browsers aren't allowed to contain arbitrary code execution vulnerabilities? |
| 18:14 | <gsnedders> | AryehGregor: What do we do when we have 64MB of RAM? You start hitting OOM often, even without memory leaks. |
| 18:14 | <zewt> | that's irrelevant; it has no parallel to "holding a strong ref to an object". |
| 18:14 | <gsnedders> | AryehGregor: And that matters on mobile. |
| 18:14 | <AryehGregor> | Still QoI. |
| 18:16 | <zewt> | it's pretty hard to claim that an object holding another object alive unexpectedly isn't an interop problem. |
| 18:17 | <gsnedders> | zewt: GC shouldn't be black-box visible, so what's there for the spec to say? |
| 18:17 | <AryehGregor> | It's no more an interop problem than "browser crashes when you call a particular method under these conditions". |
| 18:17 | <gsnedders> | "Make sure you GC often enough to not crash, if you don't handle OOM gracefully."? |
| 18:17 | <AryehGregor> | Crashes, hangs, excessive memory usage, etc. are all irrelevant to standards. |
| 18:18 | <AryehGregor> | Because everyone wants to minimize them anyway. You don't need *coordination*. |
| 18:18 | <AryehGregor> | Standards are where implementers might not agree on what to implement, so they coordinate. They all agree they don't want memory leaks, so it doesn't need to be written down. |
| 18:18 | <zewt> | gsnedders: it's visible if you run a loop that, for example, creates an image, drops it in a document, then removes it and repeats; eventually--depending on what's being kept alive and the amount of memory available--it'll misbehave. not a good approach for a test suite, but certainly visible |
| 18:19 | <zewt> | gsnedders: not talking about when you GC, but what holds implicit references to objects |
| 18:19 | <gsnedders> | zewt: It's GC-related behaviour whether you protect stuff. It's not really black-box observable unless it's wrong. |
| 18:20 | <zewt> | AryehGregor: well again, that's evidently not the case with WebGL implementations |
| 18:20 | <Philip`> | Finite RAM is just a hardware limitation, so the spec lets implementations do whatever they fancy |
| 18:21 | <zewt> | gsnedders: google maps crashes the browser on android phones pretty quickly, too :| but they do acknowledge that one as a bug |
| 18:21 | <zewt> | (probably less so on newer, beefier phones that can mask the bug longer) |
| 18:21 | <Philip`> | and GC is just a hack to let browsers survive a little longer before hitting that limitation in practice |
| 18:22 | <zewt> | well, no, GC serves many more purposes than that :) |
| 18:22 | <gsnedders> | zewt: Yay for browsers shipping on devices with no swap without OOM handling! |
| 18:22 | <zewt> | i suppose if you view an ideal world as one with infinite RAM |
| 18:25 | <AryehGregor> | zewt, no real-world WebGL implementer thinks memory leaks are okay. |
| 18:26 | <AryehGregor> | If they did, a spec wouldn't change their mind. |
| 18:33 | gsnedders | wonders if informative notes about when things have to be protected/unprotected would be useful |
| 18:44 | <AryehGregor> | So this says IE implements queryCommandIndeterm() by returning true if (inter alia) OLECMDF_LATCHED is clear but OLECMDF_NINCHED is set. |
| 18:44 | <AryehGregor> | This being: http://www.geoffchappell.com/viewer.htm?doc=studies/windows/ie/mshtml/methods/basemso/querycommandindeterm.htm |
| 18:45 | <AryehGregor> | Now this says what OLECMDF_LATCHED does: http://msdn.microsoft.com/en-us/library/ms695237(v=vs.85).aspx |
| 18:45 | <TabAtkins> | NINCHED? |
| 18:45 | <AryehGregor> | But I can't find documentation for OLECMDF_NINCHED anywhere. |
| 18:45 | <TabAtkins> | That's not even a word. |
| 18:45 | <AryehGregor> | Anyone have any ideas? |
| 18:45 | <AryehGregor> | Gecko and WebKit seem to maybe agree on what "indeterminate" means, but IE doesn't. |
| 18:45 | <AryehGregor> | And I'm not sure what IE does mean. |
| 18:45 | <AryehGregor> | (I'm pretty sure the method is useless, and Opera doesn't even implement it, but if it's simple to spec I want to do so.) |
| 18:46 | <AryehGregor> | Maybe someone here has better Google-fu or better knowledge of MS technologies? |
| 18:46 | <AryehGregor> | The MS docs here are just garbage . . . what I'd give for every browser to have docs as good as Mozilla does. |
| 18:47 | <TabAtkins> | http://www.dotnetmonster.com/Uwe/Forum.aspx/vs-net-ide/2687/vsCommandStatusTextWanted-when-does-it-change |
| 18:47 | <TabAtkins> | ? |
| 18:47 | <TabAtkins> | Specifically, Carlos J Quintero's response. |
| 18:47 | <AryehGregor> | Nice, thanks. |
| 18:48 | <TabAtkins> | (Btw, I just searched for "ninched" and that was the first response.) |
| 18:48 | <AryehGregor> | Okay, I guess what it means is what I thought it meant, namely that it should return true if the style is applied to some things in the range and not others, and false if it's all applied or all not. |
| 18:48 | <Philip`> | "no input no change" - not an entirely intuitive acronym |
| 18:48 | <AryehGregor> | Yeah, I guessed that after you posted the link. I was searching for OLECMDF_LATCHED, which told me nothing except that it's equal to 8. |
| 18:50 | <AryehGregor> | This has a good explanation: http://blogs.msdn.com/b/murrays/archive/2011/05/07/ninch-and-emu.aspx |
| 18:50 | <AryehGregor> | The only thing is, IE9 doesn't seem to do it that way. It seems to always return false. |
| 18:51 | <AryehGregor> | Anyway, I know enough to spec it now. |
| 18:51 | <AryehGregor> | Thanks all! |
| 18:53 | <AryehGregor> | It's not useless, either. It lets editing toolbars display the button in a semi-depressed state. |
| 20:46 | <AryehGregor> | Opinions wanted: is this taking functional programming overboard, or is it a nice way to do it? http://pastebin.com/pn0kzAHT |
| 20:49 | <zewt> | never been a fan of that sort of thing, just seems unintuitive |
| 20:56 | <AryehGregor> | I guess the declarative version would be like this: http://pastebin.com/sdfDadTL |
| 20:56 | <AryehGregor> | Seems more awkward, although in some ways more straightforward. |
| 20:57 | <AryehGregor> | Lower-level, certainly. |
| 20:57 | <AryehGregor> | Oh well. I guess if someone else takes over maintaining this code from me, they'll have fun cursing my name if they don't like my programming style. |
| 20:58 | <Ms2ger> | Oh, hi |
| 20:58 | <AryehGregor> | This is edit commands stuff, you probably won't take it over. :) |
| 20:58 | <Ms2ger> | Oh, good |
| 20:58 | <gsnedders> | Oh, right |
| 20:58 | <AryehGregor> | You have plenty of my DOM Range tests already, though. But my JS programming style is changing over time. |
| 20:58 | <Ms2ger> | But I actually kind of like it |
| 20:58 | <AryehGregor> | It's much more functional now than it was a few months ago. |
| 21:00 | <Philip`> | It'd be a nice style if JS's function syntax wasn't so ugly |
| 21:00 | <gsnedders> | w00t Harmony! |
| 21:01 | <AryehGregor> | What does Harmony define here? |
| 21:02 | <Philip`> | Also I suppose I'm more used to pipelines being written in the other direction, in ML and Perl etc |
| 21:03 | <gsnedders> | It doesn't, yet. It'll have some sort of lambda syntax. |
| 21:03 | <zewt> | gross |
| 21:03 | <zewt> | one of the nice things about javascript is that it doesn't have any lambda syntax, just a simple, consistent function syntax |
| 21:03 | <Ms2ger> | In SM, you could use http://pastebin.com/apJDqv2h |
| 21:04 | <zewt> | python's lambda syntax has always irked me; a poor workaround for its syntax design flaws |
| 21:05 | <AryehGregor> | Yeah, Python's lambdas are lame. |
| 21:05 | <zewt> | lack of inline functions is one of Python's more glaring mistakes |
| 21:05 | <zewt> | (to be fair, it does enough right that the things it does wrong stand out more) |
| 21:06 | <Philip`> | I thought the usual argument was that you ought to be naming your functions instead of using anonymous lambdas, so it doesn't matter that Python doesn't support the latter |
| 21:06 | <Philip`> | so it's a problem with the philosophy and not just the syntax |
| 21:06 | <zewt> | never seen that argument; it sounds more like a weak attempt to justify the mistake after the fact |
| 21:06 | <AryehGregor> | <font size=1> and <span style=font-size:xx-small> don't have the same effect in Gecko. :( |
| 21:07 | <AryehGregor> | zewt, I'm pretty sure that's what the BDFL thinks. |
| 21:07 | <zewt> | it's pretty painfully wrong. |
| 21:07 | <AryehGregor> | Agreed. |
| 21:07 | <zewt> | (not expecting to have to convince JS people of that :) |
| 21:08 | <AryehGregor> | One of the key advantages of high-level languages is the ability to avoid explicit temporary variables. |
| 21:08 | <AryehGregor> | Those are one of the things that makes C so much more verbose than everything else. |
| 21:09 | <AryehGregor> | That's one of the big advantages of garbage collection (aside from making bugs less likely). |
| 21:09 | <zewt> | it also makes implementing templating systems, like PHP and Rails's, in Python very hard, which is a really bad problem |
| 21:09 | <zewt> | well, I guess that's more a problem with the significant-whitespace thing than inline functions; I've had to work around it and it's not fun |
| 21:10 | <AryehGregor> | Significant whitespace is actually a big problem with having real lambdas in Python. |
| 21:10 | <AryehGregor> | That's why they're one line only. |
| 21:10 | <AryehGregor> | I'm not sure what the syntax would have to look like, without adding braces or equivalent. |
| 21:10 | <zewt> | significant whitespace seems like the actual reason lambdas exist in python: the syntax has no real way of writing inline functions |
| 21:11 | <zewt> | not without some particularly nasty syntax hacks, anyway |
| 21:12 | <AryehGregor> | Guido doesn't like functional programming much anyway, IIRC. |
| 21:12 | <zewt> | i don't, either, but inline functions have a lot more use than that |
| 21:13 | <AryehGregor> | They're mostly useful for stuff like map and filter, no? You can use them for other things, but that's the most common use I've seen by far. |
| 21:13 | <zewt> | map and filter usually turn into comprehensions in Python |
| 21:13 | <AryehGregor> | True. |
| 21:15 | <zewt> | in JS you have the common patterns of passing eg. completion/error functions, for example |
| 21:15 | <AryehGregor> | But the same principle applies. |
| 21:15 | <AryehGregor> | Yes, that's very true. |
| 21:15 | <zewt> | in those cases, you often want to avoid writing them as separate functions, because that puts the code logically out of order |
| 21:16 | <AryehGregor> | Ugh, why does Gecko randomly throw exceptions in so many corner-cases for execCommand() and queryCommand*()? |
| 21:16 | <AryehGregor> | Well, you can have nested functions in Python, so it doesn't have to be very far out of order. |
| 21:16 | <zewt> | also, naming a function is less clear: when you read the code, you can't tell at a glance that the function is used in exactly one place; you have to scan the entire scope to be sure, which simply goes away with anonymous/inline functions |
| 21:16 | <AryehGregor> | True, although naming conventions can help that a lot. |
| 21:17 | <Ms2ger> | Probably because we depend on some internal state that's not too hard to mess up |
| 21:19 | <AryehGregor> | What's the policy going to be for pushing out Firefox updates now, by the way? Silent update on restart like Chrome, or users get prompted every six weeks? |
| 21:20 | <AryehGregor> | Firefox extensions are much more likely to break on update than Chrome extensions . . . |
| 21:20 | <AryehGregor> | (I think whoever wrote this code in Gecko favored the "throw exceptions whenever anything goes wrong" approach.) |
| 21:21 | <zewt> | AryehGregor: and it seems like with FF's design, it'd be hard or impossible to even have any kind of transition plan for extensions, since extensions can pretty much access anything |
| 21:21 | <AryehGregor> | Yes. |
| 21:21 | <AryehGregor> | But they can also be very powerful. |
| 21:22 | <AryehGregor> | It's a tradeoff. |
| 21:22 | <zewt> | and it's not very reasonable to expect plugin authors to constantly monitor testing releases, when releases are just too quick |
| 21:23 | <smaug____> | addon |
| 21:24 | <AryehGregor> | Yeah, extension. |
| 21:24 | <AryehGregor> | Not plugin. |
| 21:24 | <smaug____> | and you don't need to constantly monitor the changes |
| 21:24 | <smaug____> | it takes ~3 months to from Nightly to release |
| 21:25 | <zewt> | which means developers have to test and update at least once every three months--they're forced into the same release cycle as the browser |
| 21:25 | <smaug____> | so addon developer can probably handle a release in Aurora and Beta in the same time |
| 21:25 | <jamesr> | the chromium extension APIs were designed with auto-updating in mind |
| 21:26 | <zewt> | some people will have the time for that, some won't |
| 21:27 | <zewt> | i was surprised at not having any major hiccups when updating to 5 |
| 21:28 | <smaug____> | IIRC, most of the addons were automatically marked to be compatible with Fx5 |
| 21:28 | <smaug____> | since the changes from Fx4 weren't that huge |
| 21:29 | <smaug____> | well, API changes weren't that huge |
| 21:29 | <gsnedders> | AryehGregor: There's a reason why they're pushing whatever their new JS based extension system is. |
| 21:29 | <AryehGregor> | Jetpacks? |
| 21:29 | <AryehGregor> | Like Chrome, yeah. |
| 21:29 | <gsnedders> | And Opera, too. |
| 21:29 | <smaug____> | yeah, Jetpack is closer to Chrome's not so powerful extensions |
| 21:32 | <smaug____> | anyone from webkit interested in mutation events? or getting rid of them? There is a thread in webapps mailing list about that. |
| 21:32 | <TabAtkins> | Yes, most definitely. That thread pre-empted one of our Chrome people by, like, a day. |
| 21:32 | <TabAtkins> | We've got a proposal that is similar in some details to Jonas. |
| 21:33 | <smaug____> | TabAtkins: my proposal is a bit simpler than what Jonas proposed |
| 21:33 | <smaug____> | but still pretty similar |
| 21:45 | <jamesr> | implement _all_ the proposals! |
| 21:45 | <TabAtkins> | </meme> |
| 21:45 | <jamesr> | smaug____: we're definitely interested in doing something about mutation events over in webkit land |
| 21:46 | <smaug____> | jamesr: yes! and implement event all the mutation events in the same time! |
| 21:46 | <smaug____> | s/event/even/ |
| 21:46 | <smaug____> | I guess no browser supports all the mutation events atm |
| 21:47 | <smaug____> | jamesr: just curious, is the chrome proposal somewhere online? |
| 21:47 | <jamesr> | that's the thing tab was alluding too - i think he's polishing something up to send out |
| 21:48 | <TabAtkins> | Yus. |
| 21:48 | <TabAtkins> | Should be online this week. |
| 21:48 | <TabAtkins> | Though not from me, specifically. |
| 22:06 | <Hixie> | zewt: note that an image does hold a reference to its Document, via ownerDocument |
| 22:07 | <Hixie> | zewt: (the HTML spec says all attributes that return objects imply a strong reference from the attribute's object to the returned object) |
| 22:11 | <heedly> | When I bind loadedmetadata, video.duration on is as long as much data as has been loaded. |
| 22:12 | <heedly> | Is there anyway to get the actual duration? |
| 22:12 | <TabAtkins> | Wait for it to fully load (when it fires canplaythrough)? |
| 22:13 | <jamesr> | fyi canplaythrough isn't reliable in webkit currently |
| 22:16 | <zewt> | Hixie: but not vice versa |
| 22:22 | <jamesr> | how out of date is w3.org/TR/html5, typically? |
| 22:23 | <ttepasse> | AryehGregor, I couldn't resist not to put my weird mixture of functional and imperative programming |
| 22:23 | <ttepasse> | Argh |
| 22:23 | <AryehGregor> | jamesr, months. |
| 22:24 | <ttepasse> | ... on your problem: https://gist.github.com/1052411 |
| 22:24 | <ttepasse> | Revisions |
| 22:24 | <ttepasse> | e62fe4 ttepasse just now |
| 22:24 | <ttepasse> | 69d906 ttepasse just now |
| 22:24 | <ttepasse> | gist: 1052411 |
| 22:24 | <ttepasse> | Description: |
| 22:24 | <ttepasse> | edit |
| 22:24 | <ttepasse> | Public Clone URL: git://gist.github.com/1052411.git |
| 22:24 | <ttepasse> | Private Clone URL: |
| 22:24 | <ttepasse> | git⊙ggc:1052411.git |
| 22:24 | <ttepasse> | Embed All Files: show embed |
| 22:24 | <ttepasse> | JavaScript # embed raw |
| 22:24 | <ttepasse> | 1 |
| 22:24 | <ttepasse> | 2 |
| 22:24 | <jamesr> | holy flood batman |
| 22:24 | <paul_irish> | RAWR!!!!! |
| 22:29 | <gsnedders> | paul_irish: Scary. |
| 22:29 | <ttepasse> | (Sorry for the flooding. Copy'n'Paste is a ... bad person) |
| 22:30 | <Hixie> | holy cow, ttepasse is the first person to be kicked in #whatwg in about 6 years |
| 22:30 | <paul_irish> | :) , btw if anyone else wants op or whatever lemme know |
| 22:30 | <paul_irish> | sorry ttepasse. <3 |
| 22:30 | <ttepasse> | Hey, I understand. My first flooding in ... ten years or so. ;) |
| 22:31 | <gsnedders> | ttepasse: So, were you the last person kicked here for some other reason? |
| 22:31 | <AryehGregor> | hsivonen, othermaciej thinks we should use "EDITOR'S RESPONSE" and not "EDITORIAL ASSISTANT'S RESPONSE", since we're acting on the editor's behalf. |
| 22:31 | <othermaciej> | it doesn't matter much but that's my suggestion and it is less verbose |
| 22:32 | <ttepasse> | Hey, the public logs seem to be down. My future isn't in danger. |
| 22:33 | <AryehGregor> | We should probably be consistent, whatever we do. |
| 22:33 | <AryehGregor> | It would be confusing if some of us say "editor" and some say "editorial assistant". |
| 22:34 | <jamesr> | EDITOR'S MINION'S RESPONSE |
| 22:35 | <Hixie> | now we're talking |
| 23:24 | <heycam> | if Flash does support some API to associate accessibility objects with areas of a canvas on which immediate mode drawing is done, then it would be good to see a comparison of its approach with the one being proposed |
| 23:27 | <jamesr> | heycam: all those canvas ax threads seem to end up being very long, emotional, and circular |
| 23:28 | <heycam> | jamesr, yeah, I tried to steer some of the discussion towards the actual proposal and how it may or may not work |
| 23:55 | <Dashiva> | Are the logs down? |