| 00:00 | <Yuhong> | I think I mentioned before when discussing DOM3 Events. |
| 00:04 | <Yuhong> | What would be involved in adding mutation events back into WHATWG DOM, BTW? |
| 00:05 | <zewt> | ww3 |
| 00:05 | <Yuhong> | ww3? |
| 01:02 | <zewt> | isn't rik at adobe? sort of surprised he doesn't understand half-pixel coordinate systems (or at least it seems from the rect email) |
| 05:27 | <gallant> | I have 6 paragraphs in a section, they have click event assigned, when I rotate by X axis the section for 360 deg I can't click and select the text from the 2 paragraphs that are on the bottom of the seciton others I can, they should change color on click, butwhen section is rotated 0 deg by X axis I can select text and click all paragrahs why? |
| 05:43 | <annevk> | heycam: so today we came up with this thing that'll help with with() and event handlers |
| 05:43 | <annevk> | heycam: @@unscopeable |
| 05:43 | <heycam> | annevk, what is the thing that needs helping |
| 05:43 | <heycam> | ? |
| 05:43 | <annevk> | heycam: it's a per-object array of property strings that are not visible when looking on the prototype chain of the object in those contexts |
| 05:44 | <annevk> | heycam: so e.g. we could have Node.prototype[@@unscopeable]] = ["find", "findAll"] |
| 05:44 | <annevk> | -] |
| 05:45 | <heycam> | oh is this to help where the event target is in the scope chain? |
| 05:45 | <heycam> | when does that happen again. and where's that specced? |
| 05:45 | heycam | might be missing some context |
| 05:45 | <annevk> | heycam: yeah, it'll help with that, it was mostly added for Array.prototype.values which got fucked by ext.js because of with() |
| 05:46 | <heycam> | I see |
| 05:46 | <annevk> | heycam: it happens for <div onclick=find()></div> which currently will want to invoke a user-defined function, but when Element.find is there would invoke that, which'll break |
| 05:46 | <heycam> | so what's the plan, to have all new things on Array.prototype be unscopable? |
| 05:46 | <heycam> | ah gotcha |
| 05:47 | <annevk> | heycam: I guess for now we'd decide on a case-by-case basis, but it's been proposed for that to be the policy |
| 05:48 | <heycam> | I guess @@unscopable would be handled in the ES spec then |
| 05:48 | <heycam> | since it needs to change how property lookups work |
| 05:48 | <heycam> | an alternative would be to stick a different object in the scope chain, one that forward a limited, fixed set of property lookups to the actual event target |
| 05:48 | <heycam> | I think there's no way of inspecting what the actual object on the scope chain is |
| 05:49 | <heycam> | so it's probably equivalent |
| 05:49 | <annevk> | heycam: yeah, it'll be in JavaScript, but we'll need to be able to define it on a per-object basis |
| 05:49 | <annevk> | heycam: that is, we need to define the array Node.prototype[@@unscopeable] returns |
| 05:49 | <heycam> | ok |
| 05:50 | <heycam> | I think it'd be preferable to have a fixed set of names there, and then to never add any more |
| 05:50 | <heycam> | seems better than waiting for new APIs to break things :) |
| 05:50 | <annevk> | heycam: also, do you think we can change what HTMLElement.prototype instanceof Node returns? |
| 05:50 | <heycam> | oh and actually I mean the inverse of @@unscopeable |
| 05:50 | <annevk> | heycam: according to Allan what we do now is not ES6-style |
| 05:50 | <heycam> | so a fixed set of names that do go through to the event target |
| 05:51 | <heycam> | annevk, yes that is not my list of things to do |
| 05:51 | <heycam> | I think Gecko already switched to doing it too |
| 05:51 | <heycam> | (i.e. make that return true, is that right?) |
| 05:51 | <heycam> | oh |
| 05:51 | <heycam> | am I thinking of the right thing? |
| 05:51 | <annevk> | heycam: it returns true right now, but it's not clear whether that's good |
| 05:52 | <annevk> | heycam: although bz made a claim about web compat... |
| 05:52 | <heycam> | yeah I remember seeing that thread about it needing to |
| 05:52 | <annevk> | heycam: it's not good at least for appendChild(), as that fails |
| 05:52 | <heycam> | and most things, really |
| 05:52 | <annevk> | heycam: re whitelist, whitelist does not work if you assume user extensions to prototype |
| 05:52 | <heycam> | annevk, ah, yes |
| 05:53 | <heycam> | annevk, whitelist of things that came from the IDL? dunno |
| 05:53 | <annevk> | heycam: say I add HTMLCanvasElement.prototype.clear = function() { ... } and then <canvas onmouseout=clear> |
| 05:54 | <heycam> | mmm |
| 05:55 | <heycam> | I wonder if you could have an object on the scope chain that forwarded to window first, then to the event target |
| 05:56 | <heycam> | .name probably ruins that idea tho |
| 05:57 | <heycam> | annevk, so maybe @@unscopeable is the simplest thing to do. esp if the ES spec will add it. can you file a bug to have an [Unscopeable] or something we can stick on interface members? |
| 05:58 | <annevk> | heycam: yeah will do once I need it |
| 05:58 | <heycam> | annevk, thanks |
| 05:58 | <annevk> | heycam: we should prolly start thinking about making our syntax a bit closer to ES syntax |
| 05:59 | <annevk> | heycam: I guess it kinda depends on whether JSIDL happens, but I've the feeling nobody really has time for that |
| 05:59 | <heycam> | annevk, yeah, I want to think about that, but probably not until I get through this backlog of open issues |
| 05:59 | <annevk> | fair enough |
| 06:04 | <annevk> | Yuhong: I guess you read the logs... Adding mutation events would be a world of hurt, but it basically comes down to the same things we go through for each ancient feature. Figure out what browsers do and define it. Ideally the least problematic variant. I'm still hopeful we don't have to. A couple of IE versions doesn't seem like a big deal. |
| 11:59 | <gsnedder1> | So can a template element have a child in the normal DOM tree? |
| 12:22 | <MikeSmith> | gsnedders: as far as I understand it, No, it can't |
| 12:25 | <gsnedders> | Thus why the tests in html5lib merely put subtree as its children. Okay. |
| 12:26 | <gsnedders> | This makes me wonder if the infoset coercion should just move them to being children. |
| 12:30 | <SimonSapin> | gsnedders: is namespaceHTMLElements documented? I learned about it by reading the source |
| 12:32 | <gsnedders> | SimonSapin: Probably not. The documentation is diabolical. |
| 13:39 | <Domenic_> | does anyone understand what's being referred to at https://twitter.com/annevk/status/359916359980822528? Event handlers picking up property names from nodes? I'm confused. |
| 13:43 | <SimonSapin> | Domenic_: I don’t know, but http://krijnhoetmer.nl/irc-logs/whatwg/20130724#l-212 seems related |
| 13:43 | <Domenic_> | SimonSapin: oh woah yeah I think that explains it. Didn't know about behavior; how bizarre. |
| 14:26 | <zewt> | wow, the google apps admin page is now pretty much unusable |
| 14:26 | <zewt> | mysterious lines of meaningless icons |
| 15:11 | <annevk> | Hixie: just posted to es-discuss about letting the host decide what this is bound to in the global environment |
| 15:12 | <annevk> | Hixie: is there anything besides that and document.all for which we've conflicts with ES? |
| 15:45 | <annevk> | Hixie: http://esdiscuss.org/topic/let-this-object-of-global-environment-be-specified-by-host |
| 16:01 | <ondras> | Hixie: ? |
| 17:30 | <Hixie> | heycam|away: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22346 |
| 17:47 | <Hixie> | any idea what bugs 22778 to 22781 are about? https://www.w3.org/Bugs/Public/show_bug.cgi?id=22781 |
| 17:48 | <ondras> | Hixie: may I have one more events-related question? |
| 17:48 | <Hixie> | you can have any questions you like |
| 17:48 | <Hixie> | answers, i can't promise |
| 17:48 | <ondras> | cool :) |
| 17:48 | <ondras> | Hixie: well, it is the case of removing an event listener during (another) listener |
| 17:48 | <ondras> | both on same object/element |
| 17:48 | <ondras> | and the same phase |
| 17:49 | <ondras> | the spec says that a list of listeners is copied prior to execution |
| 17:49 | <ondras> | so I conclude that the removed listener shall be executed as well? |
| 17:50 | <Hixie> | seems reasonable to conclude that based on what you've described |
| 17:50 | <ondras> | well, major impls think otherwise |
| 17:50 | <ondras> | let me put together a testing fiddle |
| 17:50 | <ondras> | IE9 being an exception that follows my interpretation |
| 17:54 | <ondras> | Hixie: http://jsfiddle.net/ondras/fD9qq/ |
| 17:54 | <ondras> | Hixie: do you think this is a correct demonstration? |
| 17:54 | <ondras> | annevk: ^ can you please confirm as well? |
| 17:55 | <Hixie> | seems right to me |
| 17:56 | <ondras> | Hixie: I am asking prior to submitting ff/chrome bugs, to evade looking like an idiot afterwards :) |
| 17:57 | <annevk> | ondras: looks correct to me |
| 17:57 | <ondras> | annevk: so the behavior of ff does not match the spec? |
| 17:58 | <annevk> | yeah, I seem to remember testing this and the spec matching Firefox |
| 17:59 | <ondras> | *matching* ? |
| 17:59 | <annevk> | yes |
| 17:59 | <annevk> | your test surprises me |
| 18:00 | <ondras> | chrome (blink) + opera (non-blink) does the same |
| 18:00 | <ondras> | ie9 alerts |
| 18:00 | <ondras> | ie10 no idea, not available for me atm |
| 18:01 | <annevk> | http://www.w3.org/TR/DOM-Level-3-Events/#event-flow says the same. "Once determined, the candidate event listeners must not be changed; adding or removing listeners does not affect the current target's candidate event listeners." |
| 18:11 | <ondras> | annevk: fine, will submit ff bug tomorrow |
| 18:22 | <annevk> | ondras: thanks, please cc me and ":smaug" |
| 18:24 | <Ms2ger> | And me |
| 18:32 | <ondras> | okay |
| 19:38 | <Domenic_> | haha everyone likes the onerror change https://twitter.com/pmuellr/status/360117846212231168 |
| 19:40 | <GPHemsley> | Hey guys! Someone wants to book our band(s) on a tour! |
| 20:09 | <Hixie> | Domenic_: everyone except the implementors, so far :-P |
| 20:11 | <Domenic_> | Hixie: bah, who needs 'em |
| 20:11 | <Hixie> | yeah, i sometimes think that's the attitude of people who think the spec is magical and will somehow force the browsers to follow... |
| 20:12 | <Domenic_> | if only that were the case... |
| 20:16 | <Krinkle> | (and RL auto-minified it when loaded, but the page stays cool) |
| 20:17 | <Krinkle> | (wrong chan) |
| 20:49 | <jgraham> | The mailing list threads involving James Greene really upset me. |
| 20:49 | <jgraham> | I keep thinking "I didn't say that" |
| 20:49 | <jgraham> | Only to realise that it is in fact a totally different person |
| 20:49 | <jgraham> | Who doesn't even have the same name as me |
| 20:49 | <annevk> | jgraham: pointer? |
| 20:50 | <jgraham> | annevk: The onerror thread. But the upset is only because James Gr.* seems to match my internal filters for my own name |
| 20:51 | <jgraham> | At least when scanning |
| 21:00 | <Domenic_> | where is the thread, i couldn't find it |
| 22:05 | <annevk> | AirPlay competition, finally: http://googleblog.blogspot.com/2013/07/from-tvs-to-tablets-everything-you-love.html |
| 22:05 | <annevk> | Now some standards... |
| 22:06 | <annevk> | Domenic_: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0313.html and similar |
| 22:11 | <Domenic_> | annevk: thanks, i swear i tried that archive -__ |
| 22:11 | <Domenic_> | -_- |
| 22:12 | <annevk> | Domenic_: I think there might have been a hickup, I didn't see everything I expected earlier either |